This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]