Re: FREEZE RESCHEDULED
Kevin Dalley wrote:
> Richard Braakman <dark@xs4all.nl> writes:
>
> > I was too hasty when declaring this freeze. Adam di Carlo assured me that
> > the boot-floppies are just not ready yet, and won't be for a number of
> > weeks even if they get help. Also, the count of release-critical bugs
> > is going back up as fast as it came down. (I think that many of them
> > are not really release-critical, but there are so many that just
> > evaluating them takes a significant amount of time.)
>
> One of the best ways of getting the release-critical bugs under
> control is to freeze potato. As long as we can upload packages, we
> will upload bugs. If we freeze now, we can reduce the number of bugs
> to a reasonable level over the next few weeks. By the time
> boot-floppies are ready the bug count will be at a manageable level,
> and potato will be ready for release.
I agree, with the reservation that I believe that there should be both a frozen
and unstable distribution until we're ready to go to release. I do not prefer
having an extended freeze during which no new packages or feature updates to
existing packages can be uploaded, nor does it make sense to defer freezing
until stability exists -- the purpose of freezing is to stabilize for release.
I realize that the primary difficulty of this approach has been and remains the
lack of space on Debian mirrors, and an inability to rsync only a portion of the
distribution -- i.e., stable and frozen but not unstable and experimental.
I recognize that some effort has already been undertaken to improve this
situation, in furtherance of Lalo Martin's package pool proposal, but that more
work may still be needed to enable this. In any case, I think that maintaining
a simultaneous frozen and unstable is considerably easier in the short run than
a full implementation of package pools or other more comprehensive proposals.
But I think it is important that we do this, as things have remained unstable
for far too long. It is a real hardship already to upgrade new Debian systems
from stable, especially over dial-up if necessary, and with the resulting system
containing many bugs (which, of course, is why it is called unstable). But the
alternative of running software which is more than a year out of date is often
unacceptable. If we could freeze a snapshot, and stabilize that snapshot,
without disrupting work on the unstable branch, it would be far less difficult
to freeze in general, thus we could do it sooner and more frequently.
If we cannot freeze at this moment, fine. But it is absolutely essential that
we set a firm date for freeze in the near future, one which will not be
abandoned when it is reached. We've done this several times now, and absent
some change there is no reason to believe that it will not happen again.
Moreover, even if we do manage to finally push potato out the door, the problem
will re-emerge with potato+1, etc. Indeed, we had similar problems with slink,
and with hamm, and reforms in the freeze process were promised, yet potato has
been even more delayed than these.
I believe that this is the single most serious issue which Debian has to resolve
at this time. In light of this, I am willing to contribute code or whatever
else is needed to do so. I invite those who are more familiar with the problems
to solicit my assistance in any way they feel would best help to achieve this.
If there are fundamental objections to the idea itself, as opposed to
implementation, I would be very glad to hear them, but I can think of none
whatsoever.
Reply to: