On Mon, Feb 20, 2023 at 6:45 AM Neal Gompa <[email protected]> wrote:
> On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson <[email protected]> wrote: > > > > On Sun, Feb 19, 2023 at 4:34 PM Maxwell G <[email protected]> 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 < > >> > [email protected]> 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. > That scares me more than anything. There are so many things that can go wrong when checking if a package is in the repo. The script I was planning on writing would send a list of packages to be removed somewhere and then someone would manually remove them. Troy
_______________________________________________ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
