On Mon, Feb 20, 2023 at 6:45 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Mon, Feb 20, 2023 at 9:44 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote:
>
> 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?
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 -- 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
