[rfc] focus on Ubuntu updates rather than PPA packaging

[Martin Pool]

Now we have a stable cycle working reasonable well: we're about to do
the second major iteration of it, and we're getting bugfixes off the
stable branches into karmic-updates.  Let's reconsider the way we ship
Ubuntu packages of bzr: I think we should focus on getting updates
into Ubuntu, and only do nightlies from the actual PPA.

Launchpad PPAs are a good way to get updated packages out to people,
but also a fair bit of work to maintain, partly because we have (at
least conceptually) the cross product of:

  distrorelease: dapper, edgy, feisty, gutsy, hardy, intrepid, jaunty,
karmic, lucid
  bzr series: 2.0, 2.1, trunk
  package: bzr, bzrtools, bzr-gtk, qbzr, bzr-explorer, ....
  stability of package: nightly, staging, release

This is in principle scriptable but not yet completely scripted in
every regard, and it would not be trivial to add and maintain the
scripting.

The problems at the moment seem to be:

 * we don't cover every case that would be useful
 * the PPA sometimes breaks dependencies between bzr and plugins and
these are not always caught proactively
 * it generally seems a bit painful for people to maintain
 * there seems to be a single writer lock, so when something goes
wrong we tend to say "I'll ping john_f" not "I'll fix it"

One could answer these with "just work harder" or "just work harder on
scripting it" but I wonder if we can be a bit smarter by reconsidering
the problem.

The user segments seem to be:

1- want a slightly bugfixed version of the bzr in their distrorelease
(eg 2.0.0 in karmic to 2.0.4)
2- want a major update from the release in their distro (eg 1.14 in
hardy -> 2.0.4)
3- want to use beta releases
4- want to use nightlies to be closely involved in testing

Our results so far show that beta releases are pretty stable and
suitable for everyday use; they are only unstable in the sense that
there are a larger volume of changes from month to month, and that
they change APIs and may clash with plugins.  Therefore I think it's
reasonable for quite a fair number of advanced users to run betas as
long as they can tolerate amount of API-related breakage: we want them
to report it but they shouldn't be shocked that it happens.

#1 is very similar to what should happen through the
StableReleaseUpdates process that puts safe updates into -proposed and
then -updates.  In some ways it is wasteful to run a separate
packaging process that produces basically the same results, and we
would be better off helping with SRUs.

The SRU process is intentionally quite careful and conservative so
there is a fair lag between our fix being released and it getting into
-updates, though it may be available earlier on in -proposed.  This
could be a problem if it means that we get test feedback after the
release, and if users have to wait longer than they want to get the
update.  The latter could be addressed by pointing them to the version
in -proposed, though that is somewhat more complex than adding a PPA.

#2 is also similar to what Ubuntu Backports are meant to do, and again
I question if we should duplicate that versus helping with it.  It is
a bit slow but perhaps it can be sped up.  One reason the process is
slo.w is that it tries to guard against breaking dependent packages,
and probably these users do want that care.

The current Ubuntu development release should normally include bzr
betas.  (Lucid doesn't at the moment; Jelmer will put 2.1rc1 into
Debian and we'll go from there.)  Perhaps this is the best place for
testing those betas.

I think we could bear to collapse cases #3 and #4: the nightlies are
no more buggy than beta releases and the api or ui churn is not much
more: in other words, we don't do any special work that makes beta3
any better than the trunk was the day before.

So overall I propose the actual bzr team should focus on: getting
releases into the appropriate distro channels, and then offering trunk
nightlies ourselves on top, with these specific actions:

 * when we do a new release from a stable series, proposing an SRU of
it into the Ubuntu and Debian that shipped that series
 * when a new bzr goes into the latest Ubuntu release (either through
SRU or the usual means), propose that it be backported into earlier
releases
 * keep on building nightlies from trunk into a PPA
 * concentrate on helping with the teams doing packaging in Ubuntu and
Debian rather than packaging ourselves into PPAs
 * if somebody wants to do extra packaging to fit a particular need that's fine

Then the download page advice for Ubuntu will be: "install it from the
main archive in the usual way - or if you want to test our nightlies,
do blah blah"

-- 
Martin <http://launchpad.net/~mbp/>