[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ubuntu-devel
Subject:    Release management strategy for Alpha releases ("Tribes")
From:       hobbsee () kubuntu ! org (Sarah Hobbs)
Date:       2007-09-27 14:41:15
Message-ID: 46FBC10B.3000900 () kubuntu ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While I have a lot more to add to this, I'll say this bit at the moment:

For our tribes, we need to make sure we have them 2 weeks after each
launchpad release - ie, so that the launchpad roll outs and the ubuntu
tribes never conflict.  Launchpad does sometimes break (thinking
recently of the 1.1.9 roll out), and it really would be good if the
ubuntu tribe was not (somewhat) delayed because of that.

Hobbsee

Martin Pitt wrote:
> 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
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+8EL7/o1b30rzoURAhbNAKCVCjC7llcj+teWpW2PWxbC41kI1QCgtc4o
IqOWXy3RF7iA2Wr1/xSyG7E=
=QbUS
-----END PGP SIGNATURE-----


[prev in list] [next in list] [prev in thread] [next in thread]