My views on release management

[Richard Braakman <dark@xs4all.nl>]

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

  Release Management:

  * Be loud.  Keep the developer community aware of what is suppposed
to happen when, what the release goals are, and if we're waiting why
we're waiting.  This probably means weekly mails during the
development period, and announcements whenever necessary during the
freeze.

  * Start early.  Have all the ingredients ready _before_ freezing.
Have bootdisks ready for the architectures that are to be released,
and keep track of release-critical bugs during the development period.
(There seems to be general agreement on this, and agreement among the
bootdisk makers.)

  * Correspond with individual maintainers about the status of
release-critical bugs.  If a bug is not going to be fixed in time,
decide in advance what to do about it.

  * Authorize NMUs to fix specific bugs when necessary.  (I think the
release manager should have this power.)

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

  Before the previous freeze, I would have held ncurses4 and the
Great X Reorganization this way.  (Branden would not have liked this,
but if the slink freeze had been short and sweet we would be releasing
potato around now.  Also, I wouldn't have let it happen this way
anyway; see next point.)

  * Don't try to keep track of everything.  Find a "sponsor" for each
release goal, who keeps track of progress, makes sure it happens, and
gives advance warning of any problems.  That way the release manager
only has to stay in touch with the sponsor.

  To give concrete examples, I would ask Joel Klecker to sponsor the
move to libc6.1, and Ben Collins to sponsor PAM, and I would look for
one person for each architecture's bootdisks.  For the previous
release, I would have asked Branden Robinson to sponsor the Great X
Reorganization.  As you can see, this mainly acknowledges existing
activity.  But I would go so far as to turn it around, and not
acknowledge a release goal unless it has a sponsor.  One hundred
people who say "It would be a good idea" are not much use unless one
of them is willing to take the lead.  It's like maintaining a
package -- I don't want orphaned release goals :)

  * Be present and active during important events like the freeze or
the release.  When the release time is measured in hours, I expect the
release manager to take whatever drugs are necessary to stay awake :-)
(I tend to use chocolate for this.  Of course, the release manager
gets to pick the release time so it should not be too difficult.)

  * Some things have to be done at specific times or in a specific
sequence.  Make appointments with the people who are supposed to do
them, so that they can be scheduled at convenient times.  Warn if an
appointment is missed, and if necessary make a new one and announce a
delay.

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

Richard Braakman