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:
> > Reopen if you think there's any branch that should have the fix that
> > doesn't.
>
> How does that interact with milestone settings? What (aside from the bug
> comment trail) keeps track of which of various branches have merged the fix?
In GCC, milestone of closed bug = earliest release on earliest branch that
has the fix, milestone of open bug = next release on earliest branch for
which the fix is wanted. Tracking statuses in many different trees is
something bug tracking systems in general don't seem very good at, but I
think the comment trail is good enough in practice.
> > Another procedure we need is: open separate bugs for libc and ports, and
> > preferably separate bugs for different ports, rather than one bug with
> > both libc and ports patches, as different people will be dealing with
> > different areas and a maintainer should be able to close a bug once
> > they've dealt with the parts in their area.
>
> That sentence makes a lot of sense and keeps doing so when you
> s/libc/trunk/ and s/ports/branches/. For example, say Tom owns the bug on
> the trunk, Dick owns the bug on the 2.72 branch, and Harry owns the bug on
> the 3.14 branch. To whom is the bug assigned? How does each of them go
> about doing their daily "things that are still my problem" bugzilla query?
If you want different owners then multiple bugs makes sense - but I
generally presume that something should be fixed on trunk before 2.11 and
on 2.11 before 2.10, and with that principle you only need one active
owner at a time.
(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.)
--
Joseph S. Myers
joseph@codesourcery.com