Release management strategy for Alpha releases ("Tribes")

[Martin Pitt]

Hello Ubuntu developers,

With the rather messy Tribe 4 release behind us, I would like to
discuss about the purpose of Tribe releases and possible adjustments
to the release policy.

First, let's sum up the status quo:

(1) Tribe release freeze is announced the Friday before, and put into
    action at Tuesday.

(2) There is very little work on milestoned bugs before FF, so that
    the vast majority get moved over to the next Tribe. A lot of those
    bugs have been dragged that way since Tribe 1 and 2 already.

(3) Freeze announcement leads to a rush of new features being uploaded
    to gutsy which had never been tested on a daily CD and which were
    quite immature yet. ("OMG, we must get it to that Tribe").

(4) We announce the CDs prominently as having shiny new features that
    we present to the community and which are suitable for wide-scale
    testing. We also encourage experienced users to try them (not only
    developers), since we get valuable feedback from them.

There are a range of problems:

- The reason for (2) is twofold AFAICS: one is (3) (concentrating
  effort to squeeze new features on a Tribe), one is simply lack of
  manpower (too many projects, dapper point release, lots of
  administrative churn, etc.)

- (2) and (3) together lead to CDs which are, in some ways, actually
  worse than the daily images a week before, so early CD testing
  (which I tried this time) does not help very much.

- We do (4) with the fact in mind that the CDs are problematic for
  less experienced users (like confusing them with crash reports right
  at session start, or releasing them with unresolved blocker bugs).

- Due to (4) we not only get a lot of bug reports, but we also make
  both upstream and us look quite bad, since the new features barely
  work, or even need manual adjustments.

- Since we focus on (4) our daily images get very little testing.

- Working on critical bugs (2) is dragged for a long time due to the
  structure of the release cycle (which encourages to first break
  everything, leave it broken for three months, and then play catch-up
  after UVF and FF).

I think that the most basic question that we have to answer ourselves
is: "What do we expect from a Tribe release?" 

Small approach: We can regard it as a mere snapshot in development,
with barely enough effort to make it installable. But in this case we
should not advertise them so heavily (4) and e. g. only write about
new features on the Beta release notes and web pages. The main focus
would be to exercise the installer and test the kernel on a broad
selection of hardware.

Big approach: We regard them as a mini-release which we want both
developers and advanced users to test, where new features actually
work properly and which we can be proud of. We would focus on
presenting them well instead of presenting them as fast as possible.
Then we must concentrate on bug fixing and radically reject new
features which have not matured enough so at least work for ourselves.

After settling that question, we need to do some adjustments to our
release strategy. Here is an iniital braindump of mine for mitigating
those problems with those approach:

With snapshots, we should IMHO drop the strict schedule and instead
release tribes "when they are ready".  We do a relatively liberal
freeze, and when a daily image is relatively consistent, we send it
out. This would both remove pressure on the developer team and release
management and would also calm down the pre-freeze rush to break the
distro on several places at once.

With mini-releases we need to extend the freeze by several days (7
IMHO) so that the pre-release feature rush happens earlier, we have
a realistic chance of unbreaking them and giving them some polish, and
can postpone new features to the next Tribe. This obviously means a
lot of developer and RM time overhead, and thus we need to lower the
frequency of Tribes. In this model, three weeks are ambitious and two
weeks are insane, so we need to drop the idea of the 14-day interval 
before UVF and FF.

If we aim for the latter approach, we should also modify our current
approach of one huge "break it first, fix it later" development curve
to a series of smaller ones which can be controlled more easily, and
therefore move the feature freeze to a much later point of the release
cycle.

Thanks in advance for any feedback,

Martin

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070813/ddc61ae2/attachment.pgp