Re: FREEZE RESCHEDULED

[Mike Goldman <whig@by.net>]

Kevin Dalley wrote:

> When frozen is created, we always have frozen and unstable in
> parallel.  In fact, we must always have them in parallel, if we allow
> new uploads.  Having two branches allows people to either fix bugs or
> release new unstable releases, according to their preferences.  A
> person with no bugs shouldn't be prohibited from uploading new
> releases.

I do not believe that this was the case with hamm and slink.  I believe it
*should* be the case, but IIRC there were no unstable uploads allowed
during the freeze, only release critical bug fixes to packages in frozen
were permitted until the release.

It is my opinion that this stricture is what makes it so darn hard to
freeze, nobody wants to do it until it can be certain to be as short as
possible, because if the freeze takes a long time (as it did with slink),
package maintainers are unable to incorporate new upstream versions, etc.,
and everyone is annoyed.  So Florian's point is taken, given the status
quo, we have to stabilize unstable sufficiently to freeze "quickly."

I disagree with Florian that a parallel unstable distribution, to which
package maintainers without release critical bugs may continue uploading,
is in any way an obstruction to getting the frozen distribution stable.  I
disagree that we should have to stabilize unstable in order to freeze.

I am not saying that we should freeze *now* -- if the decision has been
made that there needs to be a milestone reached with boot-floppies before a
freeze can happen, that is fine, but as soon as that milestone is reached,
the freeze should be announced and it should not be again delayed.  This
does not mean boot-floppies should have to be *stable* -- once again, the
purpose of freeze is to stabilize, the purpose of unstable is to add
features and new packages.  If boot-floppies is already "feature-complete"
then I do, in fact, advocate freezing as near to immediately as possible.