Re: calling all release branch managers

[Roland McGrath <roland at redhat dot com>]

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

Ok.  With bugzilla you can also use keywords and flags in ways that make
them usable for searching and filtering.  I think it merits some
attention to coming up with conventions that enable automation.  For me,
all should look toward the goal of each responsible person being able to
trivially peruse a priority list of things that require their attention,
and waste no time to discern and ignore things that do not.

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

That sounds reasonable enough to me.  My devil's advocate organ was
considering the case where 2.42 and 2.37 have active maintenance
(e.g. they are the system versions for heavily-used production systems
that pay maintainers for quick turnaround in fixes) while 2.39 is still
maintained but slowly (e.g. it is the system version for beloved arcane
hobby systems whose weekend hobby maintainers pay attention for a week
before their hobbyist convention twice a year).

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


Thanks,
Roland