This is the mail archive of the
mailing list for the glibc project.
Re: [RFC]: Repurpose glibc_X.Y keyword to mean "Fixed in glibc X.Y release branch"
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 Mar 2018 21:07:26 +0000
- Subject: Re: [RFC]: Repurpose glibc_X.Y keyword to mean "Fixed in glibc X.Y release branch"
- References: <firstname.lastname@example.org>
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