From a494670358ab81615551e7103fa9d7c370b4989d Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Jul 16 2020 18:13:05 +0000 Subject: [PATCH 1/4] Fix docstring in the adjust-eol.py script. Signed-off-by: Ralph Bean --- diff --git a/scripts/pdc/adjust-eol.py b/scripts/pdc/adjust-eol.py index 0c9c99f..d265497 100755 --- a/scripts/pdc/adjust-eol.py +++ b/scripts/pdc/adjust-eol.py @@ -1,16 +1,10 @@ #!/usr/bin/python3 -""" create-branch.py - Add a new branch to PDC *by hand*. +""" adjust-eol.py - Modify the EOL on an existing SL, on an existing branch. -In general, you shouldn't use this script. The "front door" for new branches -is to have people use the fedrepo-req tool to request branches, and to have -cvsadmin members use the fedrepo-req-admin tool to process them. That tool -creates branches in PDC and new repos in pagure. This tool should be used as -the backdoor option, in case releng needs to create a branch manually. +Adjust EOLs with care. Read the SOP first for policy. https://pdc.fedoraproject.org/rest_api/v1/component-branches/ -Note that branches must be associated with SLAs and EOLs. - You can run this on pdc-backend01, the token is in /etc/pdc.d/ You can also find the token in the private git repo. """ From 3c18f682de8e2c35ddc1ad9a2d579552dd3b0523 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Jul 16 2020 18:14:23 +0000 Subject: [PATCH 2/4] Python2/3 compat in the pdc utilities lib. Signed-off-by: Ralph Bean --- diff --git a/scripts/pdc/utilities.py b/scripts/pdc/utilities.py index b63e64b..c8f2f71 100644 --- a/scripts/pdc/utilities.py +++ b/scripts/pdc/utilities.py @@ -8,7 +8,11 @@ from fedscm_admin import STANDARD_BRANCH_SLAS def prompt(message, force): - return force or input(message + " [y/N]: ").lower() in ('y', 'yes') + try: + question = input # python3 + except NameError: + question = raw_input # python2 + return force or question(message + " [y/N]: ").lower() in ('y', 'yes') def die(message): From e06cc2cbbd5f81a1f168e9988d9970c1f223fc1a Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Jul 16 2020 18:14:24 +0000 Subject: [PATCH 3/4] A friendly print statement. Signed-off-by: Ralph Bean --- diff --git a/scripts/pdc/utilities.py b/scripts/pdc/utilities.py index c8f2f71..39cfe13 100644 --- a/scripts/pdc/utilities.py +++ b/scripts/pdc/utilities.py @@ -89,6 +89,8 @@ def patch_eol(pdc, package, eol, branch, type, force): # A base query query = dict(branch=branch, global_component=package, branch_type=type) slas = list(pdc.get_paged(endpoint, **query)) + print("Found %i existing SLs in PDC." % len(slas)) + fmt = lambda s: "({type}){global_component}#{name} {sla}:{eol}".format(**s) modified = [] for sla in slas: From 8f140e275b50e086e5cfde3714181311801ece77 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Jul 16 2020 18:14:24 +0000 Subject: [PATCH 4/4] A SOP for adjusting EOLs on arbitrary branches. Signed-off-by: Ralph Bean --- diff --git a/docs/source/sop.rst b/docs/source/sop.rst index 250a454..4c358e3 100644 --- a/docs/source/sop.rst +++ b/docs/source/sop.rst @@ -56,6 +56,7 @@ Standard Operating Procedures sop_custom_spins sop_deprecate_ftbfs_packages sop_end_of_life + sop_eol_change sop_package_announce_update sop_mass_branching sop_bodhi_activation diff --git a/docs/source/sop_eol_change.rst b/docs/source/sop_eol_change.rst new file mode 100644 index 0000000..15bcfb8 --- /dev/null +++ b/docs/source/sop_eol_change.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: CC-BY-SA-3.0 + +================================ +Adjust EOLs and SLs on branches +================================ + +.. note:: This SOP is about adjust EOLs and SLs on so-called "arbitrary" + branches. Unretiring a package *also* involves changing the EOL on a + branch, but you won't find information on that here. See the unretirement + SOP for more info there. + +Description +=========== + +With "arbitrary branching", modules can include streams for an RPM that are not +directly associated with a Fedora release. Modules *themselves* can have +branches not directly associated with a Fedora release. For instance, our +`python3` module has a `3.6` branch. The SLs on that module branch all go EOL +on 2018-06-01. **@torsava**, one of the `python3 module maintainers +`_, may request that this +branch have its EOL extended until 2018-12-01. + +When a maintainer wants to change EOL on a rpm, module, or container branch, +they need to file a `releng ticket `_ +requesting it. They have no way to do it on their own. Releng must review the +request, and then process it. + +Policy +====== + +Here are some *policy* guidelines to help you (releng) make decisions about these tickets + +- Clarify. Does the maintainer want the EOL lengthed for an rpm? Or for a + module? Or for a container? If they just say "increase the EOL for `httpd`, + please", it is not clear which thing they're really talking about. + +- Expect that maintainers generally know *when* their EOL should go until. You + don't need to go and research upstream mailing lists to figure out what makes + sense. Politely asking the maintainer for some background information on + *why* the EOL should be changed is good to record in the ticket for + posterity. Bonus points if they can provide references to upstream + discussions that make the request make sense. + +- EOLs should *almost always* only be extended into the future. Shortening an + EOL should only be done with care. There might be modules out there that + depend on an rpm branch with a conflicting EOL of their own. If a *shorter* + EOL is requested for an rpm branch, you should verify that no modules that + depend on it have a conflicting EOL. If a *shorter* EOL is requested for a + module branch, you should verify that no other modules require it that have a + conflicting EOL. + +- EOLs should not be arbitrary dates. At Flock 2017, we `decided on using two + standard dates `_ for EOLs to help + make things less crazy. You should use December 1st or June 1st of any given + year for all EOL dates. + +- Many branches will *often* have multiple SLs all with the *same* EOL. I.e., + the branch is fully supported until such time as it is totally retired. + There is no gray area. However, it is *possible* to have branches with + piecemeal SLs and EOLs. A branch may support `bug_fixes` until time X but + will further support `security_fixes` until time Y. This is nicely flexible + for the maintainers, but also introduces complexity. If a maintainer + requests piecemeal SL EOLs, ask to make sure they really want this kind of + complexity. + +Action +====== + +We have a script in the releng repo:: + + $ PYTHONPATH=scripts/pdc python3 scripts/pdc/adjust-eol.py -h + +.. note:: Run it with `python3`. It imports `fedrepo_req` which is python3 by default. + Installing `python2` dependencies should be possible when needed. + +Here is an example of using it to increase the SL of the `3.6` branch of the +`python3` module (not the rpm branch):: + + $ PYTHONPATH=scripts/pdc python3 scripts/pdc/adjust-eol.py \ + fedora \ + SOME_TOKEN \ + python3 \ + module \ + 3.6 \ + 2018-12-01 + Connecting to PDC args.server 'fedora' with token 'a9a1e4cbca122c21580d1fe4646e603a770c5280' + Found 2 existing SLs in PDC. + Adjust eol of (module)python3#3.6 security_fixes:2018-06-01 to 2018-12-01? [y/N]: y + Adjust eol of (module)python3#3.6 bug_fixes:2018-06-01 to 2018-12-01? [y/N]: y + Set eol to 2018-12-01 on ['(module)python3#3.6 security_fixes:2018-06-01', '(module)python3#3.6 bug_fixes:2018-06-01']