Re: My views on release management

[Richard Braakman <dark@xs4all.nl>]

Torsten Landschoff wrote:
> On Thu, Mar 04, 1999 at 10:09:33AM +0100, Richard Braakman wrote:
> >   * Have a pre-freeze of one or two weeks, during which new packages
> > can be held until after the freeze so that they can be installed in
> > the next "unstable".  Conveniently, "new packages" tends to include
> > incompatible library versions and major reorganizations as well.
> 
> So we have pre-freeze, freeze and deep-freeze? 8-)

Debian has a long tradition of stepwise refrigeration :-)

I'm beginning to reconsider this pre-freeze idea, though.  It gives
the release manager too much power over unstable, and it applies to
a fairly arbitrary set of packages (namely the ones dinstall can't
handle automatically).  At the time, perl 5.005 was installed
automatically.

I thought of it because, if I recall correctly, with the slink freeze
we had a new ncurses, a new slang, the X reorganization, and perl
5.005 all in the two weeks before the freeze.  We can forget about a
short freeze if something like that happens again.  However, it may
have been a fluke.  I don't remember it happening to that extent
before the hamm freeze, and we'll probably be extra careful next time.

A pre-freeze is not going to work unless the developers believe in it,
and in that case I think a more low-key approach will work equally
well:

  * Two weeks before the freeze, make an announcement and say "We're
going to freeze unstable in a week or two; please don't break it
too badly before then."

  * Hope that the "Be loud" and "Find sponsors" parts of the release
plan have changed the way people view the freeze time.  I think that
if developers know that their plans can mess up the release, they
are far more likely to either wait a week or start a month earlier.

  * Rely on the archive maintainers not to install obviously broken
things.  I know that my idea of "obviously broken" has broadened
somewhat since the slink freeze :-)  In particular, I now think that
incompatible library changes must come with a compatibility package or
an upgrade plan if they affect a significant number of packages.

  * The freeze plan will have some time reserved for cleaning up
before real testing begins.  If something does break just before the
freeze (and something always will), then have a team ready to fix it
fast, in frozen, after the freeze.  "Fix it fast" may mean reverting
a change, or compiling a number of packages with different libraries.
Development can then continue in unstable.

  * If something happens that makes it impossible to plan a short
freeze, then postpone the freeze.  It's better to have an extra month
of development than an extra month of frozen.  If this happens more
than once then obviously we'll need to think of something else.

> > 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.)
> 
> I also like the idea of a "generated" stable tree. So what are the problems
> you stumbled across when you tried to implement that?

I'll talk about this in my reply to Brandon :)

Richard Braakman