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

Re: Release management

On Sat, Jul 03, 1999 at 08:48:46PM +0200, Richard Braakman wrote:
> What I would like to see is two releases per year, with a freeze time
> of about one month each.

This sounds like a very reasonable idea, though I wonder if the suggestion
by Hamish Moffatt for three releases a year isn't even better.  Whatever
happens, the release schedule -must- be sped up. 

I agree with Richard; by the slink came out of freeze, the software in it
was already outdated.  This is Bad.

On Sun, 4 Jul 1999, Joseph Carter wrote:
> I would suggest refrigeration for the moment.
[Refrigeration means new software is not automatically accepted for potato.]

I don't see a problem with this at all.  Don't move potato to frozen, yet. 
Just let the archive masters have a break for a bit from adding new
packages, while potato is `in refrigeration'.  That way existing software
can be freely updated, and nothing new will come in.  Then, after a while,
we'll be very ready to freeze it.  Once potato is frozen, the new software
in the backlog can be added to the new unstable.  I don't see that having
to wait during the `refrigeration' time period for new software to appear
is a hardship, even if it has nowhere to go but Incoming. 

And the freeze, which will be shorter thanks to refrigeration, won't make
all the software out of date by the time we release!  (We can hope.)

On Sat, Jul 03, 1999 at 08:48:46PM +0200, Richard Braakman wrote:
> The first is to contact each maintainer of such a package, and ask
> what's up, and collect these reactions in the weekly report.

I'm going to add a "me too!" here: I agree.

> The second is to go ahead and mark a number of packages as "will be
> removed" if their bugs are not fixed before the freeze

Certainly after the first step is done, and no response is given by the
maintainer, we can mark a package as "will be removed".  This is
especially true, IMHO, when a maintainer is either absent or unwilling to
incorporate NMUs' changes and accept other `external' help.  Of course the
package is very welcome to stay, but not at the cost of added time to the
release cycle!

Three or four releases before the new millenium sounds like a fantastic
idea.  So does getting potato out Real Soon Now, and definitely before 2000.

William Ono <wmono@debian.org>                             PGP key: 0x93BA6AFD
 fingerprint = E3 64 C5 43 3E B3 2D A6  C6 D7 E3 45 90 24 78 DE = fingerprint
PGP-encrypted mail welcome!           "640k ought to be enough for everybody."

Reply to: