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?
Troy
_______________________________________________ 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
