On Sun, Feb 19, 2023 at 4:34 PM Maxwell G <maxw...@gtmx.me> wrote: > Hi Troy, > > On Tue Nov 1, 2022 at 07:07 -0700, Troy Dawson wrote: > > On Fri, Sep 2, 2022 at 10:55 AM Davide Cavalca via epel-devel < > > epel-devel@lists.fedoraproject.org> wrote: > > > > > On Thu, 2022-09-01 at 12:12 -0500, Maxwell G via epel-devel wrote: > > > > I think this whole process should be automated. File bugs that say > > > > "Heads up: > > > > your package will be automatically retired after the release of RHEL > > > > X.X" and > > > > provide some explanation. > > > > > > Agreed. This is a pretty mechanical process: all the maintainer would > > > do is run "fedpkg retire" for the appropriate branches, and that looks > > > reasonable to automate. If we're concerned about bugs in the automation > > > retiring packages that shouldn't be impacted, we can have it file a > > > ticket for signoff on the EPEL tracker (or have some other process to > > > spot check, at least until we're confiden it'll do the right thing). > > > > > > > Sorry for delaying this for so long. Things came up, but now I have some > > time. > > > > I think step one in this automation workflow is to not assign the bugs to > > the package at all. > > Assign the bugs to EPEL / distribution, but keep them as blockers on the > > EPEL2RHEL tracker[1]. > > This gets rid of the busy maintainer problem. Where they just read the > > subject and do what it says. > > This also allows the automation to not have to deal with all the > different > > packages. > > I'm not sure filling against distribution is a good idea. I'd just file > bugs against the affected component, set the bug assignee to yourself, > and close it once you preform the automatic retirement. This way, you > won't have to worry about CCing the proper maintainer on the > distribution bug and the bugs will be more organized. The subject is a > separate problem. > > > I think for the automation to happen, we also have to get the subject > line > > updated. > > If we can get it to have what release is in it, parsing the subject line > is > > much easier than going through all the bugzilla comments trying to find > > what release this is supposed to come out in. > > Something like "Remove yara from epel8 when RHEL 8.7 is released" > > I'd prefer something like the originally suggested "Notice: PACKAGE_HERE > will be automatically retired in RHEL X.X" so it's clear that > maintainers don't need to take manual action. >
That is a good point. On a related note. For the past month or so, as new packages get added to the tracker I've been manually adding a comment that the package shouldn't be retired until (date) which is when (release) will come out. That has usually been May 2023 when RHEL 8.8 / 9.2 comes out. Several of the maintainers have thanked me for the clarification. I've been doing this mainly so I can get a feel for what the script should be doing. But one thing came up that I don't have an answer to. I haven't said "We will automatically retire this for you" because I don't know who "we" is/are. Is it the committee? (could be, that seems the most likely) Is it the epel-packagers-sig? (I don't think that's right.) Is it a different "retirement group"? Thoughts? Troy
_______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
