Re: calling all release branch managers

[Roland McGrath <roland at redhat dot com>]

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

> If people prefer, the procedure could say "open a new bug" - I'm 
> just going by GCC practice where if we think something should be fixed on 
> a release branch (rather than just trunk), we leave it open until it is.

The practice you've suggested seems straightforward if in practice there is
only really one release branch that is active in getting fixes backported
at any one time.  I'm just wondering how well it works when that is the
other case.  I have experienced the "clone to a new bug and use bug
dependencies" method, and I'm ambivalent about its advantages and
disadvantages.

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


Thanks,
Roland