Re: My views on release management
Wichert Akkerman wrote:
> Previously Richard Braakman wrote:
> > * Be loud. Keep the developer community aware of what is suppposed
> > to happen when, what the release goals are, and if we're waiting why
> > we're waiting. This probably means weekly mails during the
> > development period, and announcements whenever necessary during the
> > freeze.
>
> No weekly announces during the freeze?
I assumed that "whenever necessary" will be more frequently than once
a week :)
> Incidentally I feel the release manager should manage the
> release-critical buglist as well, but you already know how that
> works :).
I had hoped that you would continue to maintain that list. It's
something that can be split off from other release management tasks
with relative ease.
> Also, I thought we had decided to no longer have release goals, but
> project goals. Do you mean to reinstate release goals, since you
> mention them here?
Oh, I don't remember us deciding that :) Ian Jackson spoke against
them, but his main point seemed to be that delaying a release because
of unmet goals was a bad idea, and that releasing a hybrid system is
better. I agree with that. I also think release goals are good, they
motivate people and they give such warm happy feelings when they are
accomplished. And they're an incentive to clean up those last few
loose ends.
Our development model requires support for hybrid systems in any case,
since "unstable" is always updated gradually and most developers run
unstable. Witness the libc5 to libc6 conversion. I have libc5
support on my system even today.
> > * Authorize NMUs to fix specific bugs when necessary. (I think the
> > release manager should have this power.)
>
> Within limits; this probably needs some further discussion.
What kind of limits did you have in mind?
> > * Have a pre-freeze of one or two weeks, during which new packages
> > can be held until after the freeze so that they can be installed in
> > the next "unstable". Conveniently, "new packages" tends to include
> > incompatible library versions and major reorganizations as well.
>
> Maybe a 2-week library and base-system freeze and immediately create
> unstable?
With "create unstable", do you mean freezing? Then it wouldn't be a
pre-freeze :) The big difference between freezing and not freezing is
that uploads won't go into the upcoming release by default during the
freeze. And I don't think we can change that; we get more than 100
uploads per day, and confirming them all manually would drive me sane.
I discussed this pre-freeze idea in more detail in two other mails.
I'll wait for you to catch up to those :-)
Richard Braakman
Reply to: