Re: calling all release branch managers

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Thu, Oct 29, 2009 at 8:23 PM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Thu, 29 Oct 2009, Roland McGrath wrote:
>> Right. ?We've discussed this a little in the context of branch managers'
>> discretion to backport or not. ?Bits firmly established are things like any
>> behavior change (pure fixes included) in a branch only after the trunk has
>> committed to what the new behavior will be. ?Other considerations like the
>> ones you mention we have mostly lumped as "good sense of a branch manager".
>> Of course, that means wise branch managers collaborate on documenting
>> guidelines for all to see, to whatever degree of codification is useful.
>
> I'm thinking of the ones I mention as to some extent being guidance to
> those who aren't branch managers on when to use milestones to flag
> something for a branch manager's attention - "I think this ABI breakage
> needs fixing before we branch" or "I think the fix for this bug, which is
> on trunk, is safe and appropriate for this branch". ?If the branch manager
> disagrees, they then close the bug / remove the milestone. ?If they think
> the patch needs to be tested for another month on trunk before
> backporting, they say so and leave the milestone or put it back to the
> next point release.

I reorganized the top level glibc wiki page to make it a little more coherent:
http://sourceware.org/glibc/wiki/HomePage

I've tried to document everything in this thread here:
http://sourceware.org/glibc/wiki/bugzilla/procedures

You can see the keyword list here to know which bugs are needed on
which release branches:
http://sources.redhat.com/bugzilla/describekeywords.cgi

I have also added the target milestone "2.11" for the upcoming release.

I am against creating new bugs to backport a fix to another branch.

I am for creating multiple bugs for each port, or target.

I am a big believer in getting the SNR as high as possible and
automating queries so maintainers don't have to waste time.

Cheers,
Carlos.