On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > On Sun, Feb 19, 2023 at 4:34 PM Maxwell G <maxwell@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx> 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? It should probably be done by automation, not a person. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
