This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: RFC: automatically listing fixed bugs for NEWS
- From: "FrÃdÃric Buclin" <lpsolit at gmail dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Wed, 4 Nov 2015 22:47:05 +0100
- Subject: Re: RFC: automatically listing fixed bugs for NEWS
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1510291644120 dot 10299 at digraph dot polyomino dot org dot uk> <563A548D dot 6070507 at reserved-bit dot com> <alpine dot DEB dot 2 dot 10 dot 1511042123440 dot 18787 at digraph dot polyomino dot org dot uk>
Le 04. 11. 15 22:26, Joseph Myers a écrit :
>> I wonder if bugzilla has some hidden field that stores the next release
>> number so that if it is closed without a set milestone, it defaults to
>> the next one. It then becomes the responsibility of the release manager
>> to bump that bugzilla value on release.
>
> Frédéric, is there such a feature in Bugzilla to set a default milestone
> automatically whenever a bug (in glibc product in sourceware Bugzilla, not
> for any other product there) is resolved as FIXED (such that the release
> manager can then edit the default milestone when making a new release)?
Each product has a default milestone which is used when *reporting* a
new bug, but there is no such feature when *resolving* a bug as FIXED.
The default milestone for the glibc product is "---". One possibility
would be to add code into the GCC extension to detect if the bug has
this milestone, and if true, then set it to some appropriate current
milestone. Bugzilla lets product managers deactivate old milestones (not
deleting them, just marking them as inactive), so I could tell the GCC
extension to use the next active milestone. As milestones have a sort
key, it would select the one with the smaller sort key (excluding the
default milestone, of course). Would this work for you? This would be
the less invasive solution code-wise, and doesn't require a lot of
effort from product managers.
Frédéric