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:
> > (There should also be some policy for when milestones are set at all.
> > GCC bases it around regressions; for glibc I'd suggest something more
> > flexible related to whether a fix is available, how safe the fix appears,
> > when the fix is available and how important the bug seems to fix - ABI
> > breakage bugs would be important even without a fix ready, for example.)
>
> 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.
--
Joseph S. Myers
joseph@codesourcery.com