Re: Staged Freezes
> > 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 :)
Yup. Sometimes it's difficult to see "at the current moment", though.
> > 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.
They don't have to hold off new code, though. There is always a new
unstable ready to accept those things. The problem is, as you say,
balancing the length of the freeze. You want it long enough to fix
the important bugs but short enough for things not to get out-of-date.
> 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.
It would be great if big changes like that always happened at the start
of a freeze, but applied _only_ to the new unstable. That would give the
maximum time for it to stabalize before the next freeze. As RM, you get
a lot of complaints from people who want their package installed, so you
need a pretty thick skin.
> 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.
That's reasonable. In fact, I don't think anything else is really possible.
Even without that as an official policy, it's still what happens in practice.
> 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").
Right. You can't update a library for the sake of a derivative package.
That's just asking for trouble. (And Murphy is usually listening.)
Brian
( bcwhite@pobox.com )
-------------------------------------------------------------------------------
Tired of spam? See what you can do to fight it at: http://www.cauce.org/
Reply to: