This is the mail archive of the libc-alpha@sourceware.org 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 03/15/2018 03:07 PM, Joseph Myers wrote:
> 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.

Agreed. I'll post a new non-RFC patch.

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

Correct. You have to commit the fix first. Then adjust the bugs. Then commit
the NEWS entry as a distinct "sync NEWS" commit.

At least now I can sync NEWS on the release branch whenever I want and keep
it updated to catch stray issues.

c.


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