Re: Freeze

[Onno <ebbin200@tech.nhl.nl>]

> This is a valid point, but there is still no reason not to include the current
> incoming directory.  Even if something cant be fixed before we want to
> release, then we can always backdate the package - its been done before (IIRC
> slink had to backdate X during its freeze to the last working version before
> release).

IMHO youre right. If a maintainer cannot rely on his updated
package in incomming before the freeze, where can he rely on???
You don't know how long an uploaded package will remain
in incomming...

Maybe they should introduce a freeze for incomming!

Regards,

Onno

At 10:20 AM 11/6/99 +1100, Chris Leishman wrote:
> On Fri, Nov 05, 1999 at 05:54:13PM +0100, Onno wrote:
> > IF I could vote, Camm would have my vote...
>
> Me too.
>
>
> >
> > But here is thought that crossed my mind:
> >
> > If, for some reason, something critical as the boot-floppies
> > (just an example...) would delay the release a significant
> > amount of time because they want to put in too much new
> > features, I would suggest that they just update the boot-floppies
> > and leave the new features for the next release.
> >
> > This way there would not be one component that would hold back
> > an entire release and it would keeps things much more stable.
> >
> > Also take some release critical bugs/features in perspective, if
> > a small step back would enable a long awaited release and that step
> > is only a small part of the release I would be in favor for the small
> > step back. Again the boot-floppies come into my mind (again, just an
> > example), you only use them to setup the system than you put them aside
> > and never use them again...
> >
> > Just my thoughts,
> >
> > Onno
> >
>
> This is a valid point, but there is still no reason not to include the current
> incoming directory.  Even if something cant be fixed before we want to
> release, then we can always backdate the package - its been done before (IIRC
> slink had to backdate X during its freeze to the last working version before
> release).
>
>
> Chris
>
> --
> ----------------------------------------------------------------------
>             Linux, because I'd like to *get there* today
> ----------------------------------------------------------------------
> Reply with subject 'request key' for GPG public key.  KeyID 0xB4E24219