On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson <tdawson(a)redhat.com> wrote:
On Sun, Feb 19, 2023 at 4:34 PM Maxwell G <maxwell(a)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(a)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?
It should probably be done by automation, not a person.
--
真実はいつも一つ!/ Always, there's only one truth!