Re: FREEZE RESCHEDULED
On Sun, Nov 07, 1999 at 03:03:56PM +0000, Mike Goldman wrote:
> Kevin Dalley wrote:
>
> > 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.
*Oergs* No thanks - We should keep the freeze time as SHORT AS POSSIBLE
otherwise we are releasing an out of date distribution like Slink. So i
would like to force developers to stabilize the current unstable/frozen
to be release ready instead of "Same-procedure-as-everyday" and uploading
to unstable.
> 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.
Freeze has some predepends - Working boot-floppies which do not exist
and a base stability. Then - Freeze - Force people to work on frozen
and release within 4-6 Weeks.
> 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
I dont think this is the MAIN problem. The main problem is that
most Debian developers dont care on the "stable" distribution which
is in my eyes a primary goal. Everybody is working on unstable for
years and dosnt want to stay with something called "frozen".
> 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.
Most of the maintainers would even dare to think about frozen snapshot.
> 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
Work on the boot-floppies at least - When ready - There will be a freeze.
Flo (Happy stable user and supporter)
--
Florian Lohoff flo@rfc822.org +49-5241-470566
... The failure can be random; however, when it does occur, it is
catastrophic and is repeatable ... Cisco Field Notice
Reply to: