Re: My views on release management
On Thu, 4 Mar 1999, Richard Braakman wrote:
> I saw some discussion about release management here, so I decided to
> present my views on it. They are not entirely theoretical, since I
> actually volunteered for the job :-)
I also promised a summary of ideas in one of those threads, so here goes.
> I think it is possible and desirable to have a relatively long
> development time (several months) followed by a _short_ freeze time
> (two or three weeks). I think this can be achieved with the
> current release system. The rest of this mail is a combination
> of "This is how I will do it" and "This is how I think it should
> be done"; I wasn't quite able to separate those.
[ Richard's solution shortened/modified for brevity ]
> * Be loud.
> * Start early.
> * Correspond with individual maintainers about bugs.
> * Authorize NMUs to fix specific bugs when necessary.
> * Have a pre-freeze of one or two weeks
> * Find a "sponsor" for each release goal
> * Be present and active during important events like the freeze
> * Some things have to be done at specific times
And for debian's sake, I hope it works. I have my doubts, mainly because
I think you have identified some problems and some effects, but I fear you
haven't found all the true problems and therefore may be trying to fix an
effect. I do believe you will fill the release managers roll nicely, but
another fear is that your solutions may not work for a successor. With
that said, I will support you and the remainder of this message is to
summarize previous threads and other ideas on the topic (mainly because I
promised it, not because I'm trying to stir up a debate).
> I do not advocate any radical changes to the release process. I like
> some of the three-level schemes that have been presented, but I do
> not think they are ready for use. (I tried to implement one of them,
> so I have some idea of what's involved.)
The other solutions look at radical changes. I'd be interested to hear
what problems you have had implementing other solutions. What I've pieced
together is with the help of Anthony Towns, especially his posting at:
http://www.debian.org/Lists-Archives/debian-devel-9812/msg01894.html
First, some important links:
David Engel with the beginnings of a problem:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01511.html
And some clarifications:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01608.html
Anthony has an archive of some non-list mailings on the topic:
http://www.debian.org/~ajt/debian-ftp/
Resulting in a few proposals:
http://www.debian.org/Lists-Archives/debian-devel-9807/msg02821.html
http://www.debian.org/Lists-Archives/debian-devel-9808/msg00002.html
Bdale Garbee's reorganization of ftp site proposal:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01632.html
And then comments on some types of people using debian:
http://www.debian.org/Lists-Archives/debian-devel-9805/msg01721.html
The symptoms/effects:
1) long freezes
2) lots of package updates near beginning of freeze
3) previous versions of good packages are removed in unstable by updates
with the potential to introduce bugs
Some problems:
1) too many developers working on new packages in comparison with those
working on the next release
2) items like boot disks and cd images are made after the freeze starts
3) too little communication from the important people
4) too many packages to test at one time
5) we need the ability to handle fundamental changes (e.g. libc6)
Concerns/thoughts:
1) we need to be easy to mirror
2) we should use resources that work well, like the bug tracking system
and enthusiastic users if possible
3) package bloat means we will probably need to break up the archive one
day into multiple sites
4) we may want a core set of packages that get more attention, this would
be a simplification of the current priority system (core = essential +
standard)
5) declaring several thousand packages stable is more difficult that
declaring individual packages stable
6) if we restructure the ftp site, maybe we could consider using priority
instead of section for directories (keywords takes care of sections)
Solutions:
There are some detailed solutions in the above threads, especially
Anthony's proposals. My personal one would look like a 4 level solution:
a) unstable = packages never make it to stable from here, no code name
needed.
b) holding = packages that desire to go into the next release sit here
for testing for maybe a week, if no release critical
bugs, it makes it to...
c) prerelease = this is the next release, therefore, it has a code name.
Unlike frozen, it always exists and should be convertible
to a release in a week or two.
d) release = this is a tested prerelease, maybe a week of restricted
uploads before prerelease becomes release
If there is a major change, there can be two prereleases so the major
change can be worked on while several releases occur using the old stuff.
For non-major changes, prerelease can start off as a symlink tree that is
flattened at the beginning of a freeze. For major changes, the second
prerelease can start as an empty tree. Because it takes a week to get
through holding, there can't be a last minute panic / package uploading as
long a freezes are announced with less than a week and even if there is a
panic (e.g. releases become very predictable), a bug in you new package
prevents to from making it in the prerelease. This layout encourages all
users to help with testing by pointing apt to holding. Those users that
want a semi-stable up-to-date system follow prerelease. This improves the
testing of our releases reducing the need for more developers to help with
a release. A buggy package in holding won't overwrite a good package in
prerelease unless the bugs aren't caught in time. A package that is known
to be unstable doesn't go into holding which allows developers to work on
the package without the fear that the package makes it into stable before
it should. I'd also suggest flattening the symlinks at the beginning of
the freeze for the mirrors to catch up earlier rather than later. Also,
ignoring unstable is easy since the name is set (i.e. not a code name).
Other solutions involve a package pool with multiple versions of each
package and a symlink tree pointing to the appropriate versions of each
package. There's also the idea of an unstable-hold which never progresses
to stable, thus keeping our current system with some of the benefits of my
proposal (essentially, you would rename experimental and lose the
holding area in my proposal). There are lots of others that I can't think
of or are just slight modifications of other proposals.
These thoughts are simply so they go in the archive for the next time we
need to talk about this. Richard, if you would like, I'm willing to make
a formal proposal. I think you would prefer to try your way and I'm more
than happy to respect that. If it doesn't work as planned, we can talk
about this after the next release. My biases are toward the testing, boot
floppies, and cd images teams because I tend to follow these groups more
and more lately. I personally have no idea of the complexity behind these
changes in terms of code modification, but if assistance is needed, I'm
willing to sign up as a developer to help with the task (school is almost
done with which is why I haven't signed up earlier, most of my
experience is in c, c++, perl, and shell scripting).
Well, I've said what I wanted to, hopefully no one takes offence / starts
a flame war / suggests revamping the system without giving Richard a
chance.
Wow, you're still reading,
Brandon
+--- ---+
| Brandon Mitchell bmitch@atdot.org http://bmitch.dhis.org/ ICQ 30631197 |
| Throughout history, UNIX systems have regulary been broken into, beaten, |
| brutalized, corrupted, commandeered, compromised, and illegally fscked. |
| -- UNIX System Administration Handbook |
Reply to: