On Sun, Nov 14, 1999 at 02:46:25AM -0500, Brandon Mitchell wrote:
<snip>
> I was going to see how detailed my previous one was, but it seems the
> search engine is offline (glimpse can't load library 'libc.so.5', oops).
> I'll wait until I can find it, but if you know of something more recent (I
> know someone was talking about it), then feel free to pose the url.
> [ hours tick by ]
> Ok, found it quickly, took a while to catch-up:
> http://www.debian.org/Lists-Archives/debian-project-9910/msg00052.html
kewl...thanks for that.
>
> It might be worth reproposing it after seeing all the debate and different
> ideas. But it's late now and I'm tired. I kind of think the discussion
> would have been better suited for this list, but to each his own.
>
> Take a read over it and see if you want to keep the staging discussion
> going. My current problem with the stages is the human interaction
> required. I believe a freeze now requires individual attention to each
> package that tries go get through. I tend to favor automation where
> possible and decreasing the time of the freeze when possible for
> scalability reasons. However, if one is proposing to automate the
> actions that occur during a freeze then none of what I just said is valid.
Well... _I_ want to keep the staging discussion going :)
I think we all know that I'm not really impressed with the idea of a perpetual
unstable "pool", for the reasons stated in my previous mails.
As for your problem with the staging suggestion - I really can't see why it
would require much human interaction at all (especially in comparison to the
extra human interaction for the "pool" proposal).
All that really needs to happen in the staging process, is for the dinstall
scripts to recognise which packages are currently "frozen" and not move those
into the current development tree unless tagged as updates for frozen (the
developers would need to consciously decide that they need to upload after the
freeze - making sure they obey the freeze rules). Any other updates not
tagged as such would be held until the next release cycle (or moved into a new
"unstable" tree).
The actual processing is fully automated - the only manual input is when a
developer wants to specify that they are actually updating "frozen" with a bug
fix. Ok, this puts the onus on the developer not to break the freeze rules -
but thats not such a problem really (and it is reversible if they don't).
Actually...there should also be the opportunity for the release manager to
put a hold on updates to frozen too, so that they can be checked in manually.
This may be useful in the final stage when everything is frozen.
So, the requirements would be:
1) Maintainers have some awareness of freeze dates (obviously this would be
more important for packages that freeze earlier - less for those that
freeze later). This is trivial.
2) Maintainers need to be able to tag their upload as an update to "frozen".
This requires them to know to do this. Note that this is _nothing new_, it
is the same as we have now.
3) Maintainers need to be conscious of the rules for updates to frozen. Since
the updates would be automated there is the potential to break this rule,
but most developers would not (they have to consciously upload to frozen) -
and the bug system can be used to report when this has occurred.
4) A bit of organisation before the start of each cycle, where the release
manager looks at any new base version, new major inclusions (say gnome),
any changes in policy, and then sets the freeze points. There would be
a fairly typical guideline for these dates anyhow - and it wouldn't be
likely to change often.
This compared to the "pool" proposal, which would require:
1) Maintainers to keep track of all the versions of their software in the
pool.
2) Maintainers to recognise when a package should be promoted to "working".
3) A release team (with a bit of divine intervention) to be able to recognise
a good time to freeze working.
4) Big modifications to the entire development process and the tools we use
to handle it.
5) Extra load on the dinstall managers.
So please, if you are worried about levels of human-interaction then consider
the stages model :)
Chris
--
----------------------------------------------------------------------
Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
Attachment:
pgpNzFddvMA1L.pgp
Description: PGP signature