On Sat, Nov 13, 1999 at 06:21:44PM -0500, Adam Di Carlo wrote:
>
> Let me just preface by saying that my reading of Chris' proposal
> required maintainer themselves to upload things in certain rather
> small (2 week) windows. Honestly, due to upstream release times etc
> we just can't count on this kind of control and discipline from
> maintainers.
>
Ughh..totally untrue. You have missed the point.
There would be _no difference_ from the current methods of developers. All
the stage handling would be done by the install process - the same way that
freezes work now.
And I have also stated that the time between freezes would not be the only
time for upload (nor need it only be two weeks - thats up to the release
manager).
If stage1 freezes at the 6week mark, thats 5 weeks for any new base packages
(and major updates to existing packages) to be included in this release cycle.
If stage2 (libs) freezes at the 8 week mark, thats 8 weeks for any work to
be done here. The only trick is that the first 6 weeks the maintainers will
have to work with the possibility of the base changing (which can happen
anytime anyway under the existing and the pool system).
Stage 3 (libs depending on libs) freezes at 10 week mark, thats 10 weeks for
those.
etc. (I hope you get the idea now).
The length of time before a section freezes would be up to the release
manager, and he could consider certain things (like whether there needs to be
major changes in a particular area or not) before he sets the freeze points at
the start of the release cycle.
And if an upstream release comes after the freeze date for that section, then
it will have to wait till the next cycle (or go into a new "unstable" if it is
decided that we need one). But that delay is not likely to be long.
Think about it. The stuff that would freeze earlier is major base packages -
which don't get upstream releases very often. So waiting 9 weeks (14 week
cycle - 5 weeks) would not be a huge ask. Conversely, packages in the final
catagory (like user software and some daemons) would be more likely to be
updated often - but they would only be frozen for 2 weeks before the next
cycle begins.
Chris
--
----------------------------------------------------------------------
Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
Attachment:
pgpotLOGGlW_4.pgp
Description: PGP signature