On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson <tdawson@redhat.com> wrote:
>
> On Sun, Feb 19, 2023 at 4:34 PM Maxwell G <maxwell@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@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.