On Tue, Nov 09, 1999 at 10:55:18PM -0500, Brian White wrote:
> I'll just add a few comments about what I learned as Release Manager...
>
> - everybody wants a freeze
> - a few people always want to freeze "right now"
> - a few people have very good reasons not to freeze "right now"
> - there are always some not-ready packages
I think we've all notice this :)
>
> Some past example:
> - new X release 2 weeks before release
> - boot disks not even started until a week before release
> - new kernel (2.2) release just before a freeze
> - dozens of "must have" packages uploaded in the week after the freeze
> (even though the freeze had been announced 2 months earlier)
>
> To me, this means that you can't wait for a good time to freeze. You have
> to force it. Decide what it absolutely necessary and bite the bullet for
> the rest of it. In truth, the best thing about being frozen is the power
> it gives the release manager. Every package achieves it's "most stable"
> point at a different time. Once the distribution is officially frozen,
> most maintainers will automatically target their packages for the next
> distribution if it's stability is lower than a previous release. It's
> up to the release manager, however, to catch and force this upon those
> maintainers that just don't quite get this concept (which I think applies
> to all of us at one point or another -- I know I've made poor judgements
> on my packages once or twice in the past).
>
Ok. Well, this is the thing I would like to look at. The big problem I see
is that when you "bite the bullet" and freeze everything you don't know how
long it will be for. This is the thing that worries some people, because even
if they are willing to hold off new code, they don't want to do if
indefinately.
The other thing is that on average those packages that take a long time to
stabilise generally don't change very often (eg. libc doesn't get updated very
often - but when it does its a big). So maintainers of those are more likely
to want to update quickly and would be happy holding off for longer.
Conversely, smaller trival packages would be updated more often, but are less
likely to unstabilise the distribution, and their maintainers really want to
get their work out there.
So the aim of my proposal is to allow the release manager the power to bite
off bit of the distribution at a time, forcing a freeze onto those sections.
Pick a time, and declare a freeze on the base - normal freeze rules apply,
regardless of any pending new versions. Then a bit later, when base has
stabilised a bit, freeze something else (say all the libs). This allows you
to force the concept of "no new code" onto the maintainers in an incremental
fashion - modelling more closely the way the developers themselves would
(should?) think about releasing major updates.
Of course there is the problem of having an updated trivial package depend on
an updated core component - but in this situation the freeze on the core is
absolute and would thus deny the chance to add the new version of the trivial
package ("The core wont change, thus your package wont work. Sorry but it
will have to wait until the next distribution").
So basically, the proposal is about giving the release manager more power to
force a freeze - with less concern that they will have picked the wrong time
for a minority of the maintainers.
Chris
--
----------------------------------------------------------------------
Linux, because I'd like to *get there* today
----------------------------------------------------------------------
Reply with subject 'request key' for GPG public key. KeyID 0xB4E24219
Attachment:
pgpyb7bWUDO4F.pgp
Description: PGP signature