Re: Debian release strategy (Was: Re: XFree86 3.2 is out, should we , delay the release of Debian 1.2)

[Nikhil Nair <nn201@cus.cam.ac.uk>]

On Fri, 1 Nov 1996, Dale Scheetz wrote:

> On Thu, 31 Oct 1996, Bruce Perens wrote:
> 
> > I thought 3 months was about right, if we can stick to it.
> > 
> This might be easier to hit, if we aimed at a code freeze for 2 months
> after a release.
> We seem to not start discussing a release until the target date has
> passed. Starting the discussion a month early at least provides a hope of
> meeting the deadline.

I think you've hit the nail on the head here.  This is what I had in mind
when I mentioned `formalising' the procedure.  I'll outline how my
thoughts are panning out (having read other people's comments) - there's a
lot of refinement still needed here, though.

The basic idea is to make releases happen as implicitly as possible, so
that they are natural and not something we have to fit other things
around.  We should have a fixed release date, probably the 1st of a
particular month (simply because that's nice and memorable), and also a
set code freeze date which is about two-thirds the way through the cycle;
e.g. for a three-month cycle, the 1st of the previous month, or for a
two-month cycle, the 10th of the previous month [I include both lengths
because there seem to be people in favour of both].  It should be possible
for one person (Bruce) or maybe another couple (just in case) to intervene
manually and put these dates back; but this should be done *very rarely*
and only for *extremely good reasons*.

OK, so we now have two dates, the code freeze date and the release date.
So what happens on each?

On the code freeze date: the stable tree is renamed to stable-<version>
and a new stable tree, containing symlinks to the former, is created
[would this hit mirrors?].  From then on, uploads to stable would go into
the new stable tree for the next release, not the current one.  There
would be a special procedure for getting things into the current tree, but
developers should have to write a short justification for this, and it
would have to be convincing (we don't want this being exploited for
reasons other than bugfixing).  Then an automated message should be sent
to debian-private or other appropriate place informing everyone of the
code freeze and how to upload emergency bugfixes (probably something in
the .changes file). 

On the release date, then, all we need is a snapshot of stable-<version>.

This model relies on the stable tree always being stable.  I assume this
is the idea of it, but I'm not absolutely sure.  I've deliberately left
out the unstable tree - some packages which are unstable won't suddenly
become stable in a month's time just because it's been sitting around.  It
would be up to the maintainer to upload it specifically to the stable
tree.  In the case of big changes (like ELF), maybe the thing to do is to
have everything in the unstable tree until nothing is broken, then move
everything on mass to stable [sorry if this is what happened anyway ...].

The point of all this is to stop releases being a big thing as far as we
are concerned.  I think the quality of Debian is sufficient that we don't
need to make a huge effort to `raise our game' when a release comes round
- and if we stop worrying about releases ... well ... a cron job could do
a lot of the work for us. 

Nikhil.

--
Nikhil Nair
Trinity College, Cambridge, England
Tel.: +44 1223 368353
Email: nn201@cus.cam.ac.uk
       nnair@debian.org



--
Please respect the confidentiality of material on the debian-private list.
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-private-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com