Re: [RFC]: Repurpose glibc_X.Y keyword to mean "Fixed in glibc X.Y release branch"

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 15 Mar 2018, Carlos O'Donell wrote:

> I would like to propose we re-purpose the glibc_X.Y tag to indicate
> "Fixed in glibc_X.Y", and enhance the list-fixed-bugs.py script to
> process keywords in-addition to milestone.

Fixed in X.Y, or fixed in X.Y *after the release*?

I don't see what the "-b both" option is supposed to be for.  I think a 
simpler interface should suffice: if the version passed is a two-part 
version such as 2.28, it means to find the bugs fixed on master before the 
release; if a three-part version such as 2.27.1, it means to find the bugs 
fixed for that branch version after the previous release for that branch 
was made (say we add keywords for 2.27.1, 2.26.1, ... versions for active 
branches - if there were any point releases, there could be .2 etc. 
keywords, but in the absence of actual .1 point releases we don't need 
such keywords).  No -b option; the argument passed would always be the 
version for which a list of fixed bugs is to be generated.

As long as the entries in NEWS are created manually on the branch, there 
is still an ordering issue here: we're saying the keyword means fixed on 
the branch, properly you should commit the fix there before setting the 
keyword, but you need to set the keyword before list-fixed-bugs.py will 
include the bug in its list.  I suppose one option would be to say that 
branch maintainers should update the list of fixed bugs from time to time 
(monitoring for any commits for which people fail to set the keyword) 
rather than each committer needing to do so.

-- 
Joseph S. Myers
joseph@codesourcery.com