This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]