[EPEL-devel] Re: EPEL2RHEL - New Wording? - New Workflow?

[Troy Dawson]

On Mon, Feb 20, 2023 at 6:45 AM Neal Gompa  wrote:
> On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson  wrote:
> > On Sun, Feb 19, 2023 at 4:34 PM Maxwell G  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 <
> > > > [e-mail]> 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