[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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:

First, some important links:
David Engel with the beginnings of a problem:
And some clarifications:

Anthony has an archive of some non-list mailings on the topic:
Resulting in a few proposals:

Bdale Garbee's reorganization of ftp site proposal:
And then comments on some types of people using debian:

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)

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 +
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)

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
 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

Wow, you're still reading,

+---                                                                     ---+
| 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: