[RFC] : Repurpose glibc_X.Y keyword to mean "Fixed in glibc X.Y release branch"
Commit Message
The current purpose of the glic_X.Y keywords is to indicate that a given
bug needs to be backported to glibc_X.Y. My original idea behind this was
that users or distribution maintainers could request certain bugs fixed on
master to be backported to release/X.Y/master via this keyword, and we could
avoid creating a new bug for this request.
Instead of following this process, we have had a better process arise!
We have empowered distro maintainers and vendors to work upstream, backporting
bugs that matter to them (selected from their perspective distro bug
trackers). The distro maintainers are doing a fantastic job of backporting
bugs. Thanks you Aurelien, Florian, Siddhesh, Raji, Arjun, Dmitry, and
many more! This is exactly the way it should work. Need and interest driving
the work.
Therefore nobody uses glibc_X.Y to indicate anything. Developers backport the
bugs themselves, there is no need to mark a bug as needing a backport.
Users of the distros file these bugs in the downstream distro
bug trackers instead of upstream in the glibc bugzilla.
The one thing that is missing from this is an automated way to generate
the bug list on the *release branch* NEWS. We have that automation already
for master via milestone=X.Y, but the milestone UI widget is not multi-select.
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.
This way the process looks like this:
* Commit changes to master, set bug milestone=X.Y.
* Can update bug list at release with `./list-fixed-bugs.py 2.28`
* Commit changes to release/X.Y-1, set keyword glibc_X.Y-1 in bug.
* Run list-fixed-bugs.py, and commit the changes it generates.
* Get list of bugs for 2.27.1 with `./list-fixed-bugs.py -b release 2.27`
* Lists only bugs which were fixed after release e.g. glibc_2.27 keyword and FIXED.
This automates the generation of the list NEWS bug list for release branches.
Users need only cut-and-paste the results before they commit.
Cheers,
Carlos.
Comments
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.
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.
2018-03-15 Carlos O'Donell <carlos@redhat.com>
* scripts/list-fixed-bugs.py: Add -b support for listing bugs.
@@ -21,6 +21,24 @@
This script takes a version number as input and generates a list of
bugs marked as FIXED with that milestone, to be added to the NEWS file
just before release. The output is in UTF-8.
+
+If the -b "master" option is used the list of bugs is all of those
+bugs marked FIXED with that milestone i.e. fixed on master before the
+release. This is the same as running without -b (default).
+
+If the -b "both" option is used the list of bugs is all of those bugs
+marked FIXED with that milestone and keyword e.g. glibc_VERSION
+i.e. fixeed on master before the release and fixed subseqeuently on
+the release branch. This is the list of all the bugs fixed in a given
+minor X.Y* release.
+
+If the -b "release" option is used the list of bugs is all of those
+bugs marked FIXED with that keyword e.g. glibc_VERSION i.e. fixed on
+the release branch after the release. Once a commit has been cherry
+picked to the release branch, and the bug updated to include the
+keyword glibc_VERSION (indicates fixed on the matching release branch),
+the script can be run to get the new list of fixed bugs to update the
+release branch NEWS.
"""
import argparse
@@ -30,19 +48,47 @@ import textwrap
import urllib.request
+class BranchAction(argparse.Action):
+ def __init__(self, option_strings, dest, nargs=None, **kwargs):
+ if nargs is not None:
+ raise ValueError("nargs not allowed")
+ super(BranchAction, self).__init__(option_strings, dest, **kwargs)
+ def __call__(self, parser, namespace, values, option_string=None):
+ options = set(['master', 'release', 'both'])
+ if values not in options:
+ raise ValueError("Only one of 'master', 'release', "
+ "or 'both' can be used with -b.");
+ setattr(namespace, self.dest, values)
+
def get_parser():
"""Return an argument parser for this module."""
parser = argparse.ArgumentParser(description=__doc__)
+ parser.add_argument('-b', action=BranchAction, default='master'
+ help='One of "master", "release", or "both"')
parser.add_argument('version',
help='Release version to look up')
return parser
-def list_fixed_bugs(version):
- """List the bugs fixed in a given version."""
- url = ('https://sourceware.org/bugzilla/rest.cgi/bug?product=glibc'
- '&resolution=FIXED&target_milestone=%s'
- '&include_fields=id,component,summary' % version)
+def list_fixed_bugs(version, branch):
+ """List the bugs fixed in a given version on master and the matching
+ release branch (if branch is 'both'), or only on the matching release
+ branch (if branch is 'release'), or only on the master branch when
+ that the release was in development (if branch is 'master')."""
+ keyword=version
+ milestone=version
+
+ if branch == 'master':
+ keyword='NOMATCH'
+ if branch == 'release':
+ milestone='NOMATCH'
+
+ url =('https://sourceware.org/bugzilla/rest.cgi/bug?product=glibc'
+ '&f1=keywords&f2=target_milestone&j_top=OR'
+ '&o1=substring&o2=equals'
+ '&query_format=advanced'
+ '&v1=glibc_%s&v2=%s'
+ '&include_fields=id,component,summary' % (keyword, milestone))
response = urllib.request.urlopen(url)
json_data = response.read().decode('utf-8')
data = json.loads(json_data)
@@ -57,7 +103,7 @@ def main(argv):
"""The main entry point."""
parser = get_parser()
opts = parser.parse_args(argv)
- list_fixed_bugs(opts.version)
+ list_fixed_bugs(opts.version, opts.b)
if __name__ == '__main__':