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, Oct 29, 2009 at 09:05:08PM +0000, Joseph S. Myers wrote:
> 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.

This sounds fairly common-sense and sensible, I would expect that to be
the natural idea of anyone, but we can surely document this if noone is
against.  In case of multiple stable branches, why not just set the
milestone to the oldest branch, and the branch maintainer can reset it
to the next newer branch when he is done, if the maintainer of the newer
branch doesn't notice earlier, which is fairly likely given the rather
small amount of bugs that get opened.

> 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.

This would be a change from today in that branch manager would .

I have no idea how this would work in glibc, since it requires a lot of
cooperation between Ulrich and the branch manager; I don't know how this
would be done, and if Ulrich would be interested in any such cooperation
at all.

The policy you outline does seem as a overkill to me, though - I think
we are overdesigning for a case we know little about yet, it seems to me
to first try really maintaining stable branches for a release or two,
then we can decide if there would be major improvement in involving the
branch maintainer before tagging the major release; to get things
started, I think it's better to first have them just as stewards tagging
minor releases after the major one falls out from the trunk.

-- 
				Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth


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