This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: calling all release branch managers
On Thu, 29 Oct 2009, Roland McGrath wrote:
> > A prerequisite for good bugzilla procedures for branches is such
> > procedures for mainline development.
>
> I disagree. Certainly we would like to come to coherent procedures all
> around. But IMHO the place where the need for formality starts is with
> the formal release branches. Those are what users who are not themselves
> libc hackers need to deal with, where there is concrete stable maintenance
> going on that needs coordination, etc.
I propose the following bugzilla procedure:
Set a milestone on a bug if you think the fix for that bug is ready for a
given release branch and should go in it, or that the bug needs fixing for
that branch, and reopen if the bug was closed as fixed on trunk but the
fix should go in a previous branch. Anyone can do this once for a bug but
should not restore a milestone if reset by the branch manager or reopen
if the branch manager decides against fixing on the branch.
Branch manager reviews bugs with the milestone set before branching and
decides which fixes should go in before the branchpoint (and determines as
necessary whether to delay branching or let the branch go without
everything wanted). If there are persistent problems with getting things
fixed or reviewed in particular areas and so branches need to be made
without all the desired fixes, invite more people to become trunk
maintainers to fix and review patches in those areas. By recording which
fixes were postponed past a branch we can get an idea of what areas need
more maintainers, and look at past contributors in those areas to find
suitable maintainer candidates.
Branch manager reviews bugs with the milestone set before subsequent point
releases from the branch (with the additional requirement there that they
are fixed on trunk first).
As you'll see, this applies both before and after the branchpoint, which I
think is the natural thing to do. I have experience with this as one of
the release managers for GCC; Bugzilla is an important tool for monitoring
the state of things before branching and deciding when to branch.
Release managers in GCC don't have any special rights over the trunk to
review or apply patches - only the power to delay or not to delay
branching - but the community still seems to work to get features and
fixes in at the right times.
--
Joseph S. Myers
joseph@codesourcery.com