Orphaning EPEL Branches

[Maxwell G]

Hi EPEL folks,

In the past couple EPEL SCo meetings, we have been discussing adding a
new package retirement policy for EPEL packages.

However, we have not found a satisfactory solution to the scenario where
a packager no longer wishes to maintain their package in EPEL, but the
package does not have unpatched CVEs, a dead upstream, or other reasons
to warrant completely retiring it. In Fedora itself, there is a specific
policy/procedure[1] for orphaning packages:
> When Fedora maintainers do not want or are not able to maintain a
> package any longer, they can orphan or retire the package.
> In case the package is still useful for Fedora, it should be orphaned.
> Then other maintainers that are interested in maintaining it, can take
> ownership of this package.

<snip>
> Orphan packages will be retired if they remain orphaned for six weeks.

<snip>

I omitted the parts that are specific to the Fedora release cycle.
Currently, EPEL packages can be retired from any EPEL branch at any
time. However, it is currently impossible to independently orphan EPEL
branches for the following reasons:

1. EPEL branches can't be orphaned separately. It's only possible to
orphan the entire repository, which is not wanted in all cases.

2. Technically, it's possible to set the Bugzilla assignee for EPEL to
"orphan" but that doesn't really accomplish anything. Currently with
this approach:

There is no way for packagers to pick up orphaned EPEL branches in a
    self-service fashion. There are no notifications when these packages
    are orphaned, so it's unlikely that anyone will pick them up. We'd
    also need to figure out how to handle retiring packages from EPEL
    that remain orphaned there for six weeks. This solution still
    doesn't solve the situation where e.g. a maintainer no longer wishes
    to maintain their package in epel7 but wants to maintain it in
    epel9.

What do y'all think about this issue? How do you think we should address
it? Keep in mind that orphaning a package basically amounts to delayed
retirement, unless someone picks it up.

Here are my thoughts:

If an entire Fedora package that has (an) EPEL branch(es) is orphaned,
the EPEL branch(es) should probably be orphaned at the same time as the
rawhide branch. Otherwise, we'd have to treat only orphaning an EPEL
branch as a special case:

We could create an issue tracker for this. Packagers would have to
submit a ticket requesting to orphan a certain package's EPEL branch(es)
and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
could have a provenpackager in the SIG go through and manually retire
the packages that haven't been picked up after six weeks. The later will
be difficult if we have a large volume, but I don't expect that. We
could script this if necessary or just ask the submitter to do it
themself.

This doesn't allow picking up packages in a self-service manner, but I
don't think that's a huge deal for our case.

[1]: https://docs.fedoraproject.org/en-US/fesco/Policy_for_orphan_and_retired_pac...

[Kevin Fenzi]

On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> Hi EPEL folks,
>
> In the past couple EPEL SCo meetings, we have been discussing adding a
> new package retirement policy for EPEL packages.

That reads amusingly to me... to be clear 'new policy' not 'new packages'.

...snip...
> Here are my thoughts:
>
> If an entire Fedora package that has (an) EPEL branch(es) is orphaned,
> the EPEL branch(es) should probably be orphaned at the same time as the
> rawhide branch. Otherwise, we'd have to treat only orphaning an EPEL
> branch as a special case:
>
> We could create an issue tracker for this. Packagers would have to
> submit a ticket requesting to orphan a certain package's EPEL branch(es)
> and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> could have a provenpackager in the SIG go through and manually retire
> the packages that haven't been picked up after six weeks. The later will
> be difficult if we have a large volume, but I don't expect that. We
> could script this if necessary or just ask the submitter to do it
> themself.
>
> This doesn't allow picking up packages in a self-service manner, but I
> don't think that's a huge deal for our case.

I'm not sure we want to CC epel-devel on these, perhaps we could have a
script that processes them once a week or so and sends a summary to the
list? But I am not sure how much volume we would expect here. ;(

I wonder if we could get some cycles from developers to adjust
pagure-dist-git for this case to make it more self-service. 
(taking orphan packages over).

kevin

[Troy Dawson]

On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi  wrote:
> On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> > We could create an issue tracker for this. Packagers would have to
> > submit a ticket requesting to orphan a certain package's EPEL branch(es)
> > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> > could have a provenpackager in the SIG go through and manually retire
> > the packages that haven't been picked up after six weeks. The later will
> > be difficult if we have a large volume, but I don't expect that. We
> > could script this if necessary or just ask the submitter to do it
> > themself.
> >
> > This doesn't allow picking up packages in a self-service manner, but I
> > don't think that's a huge deal for our case.

After some discussion in our weekly EPEL Steering Committee meeting
Maxwell's idea seems to lead the way.
Maxwell has setup of pagure repo, to track these orphan issues.
A pagure repo gives us the opportunity to have a nice README that people
can see if they are unsure of the process.
A pagure issue also seems more user friendly than a bugzilla.  Both for the
person creating the issue, and for others tracking it.

https://pagure.io/epel/package-orphan-requests

The policy isn't setup yet, but we are moving in the right direction.

Troy

[Maxwell G]

On Wednesday, August 10, 2022 4:07:29 PM CDT Troy Dawson wrote:
> On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi  wrote:
> > On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> > > We could create an issue tracker for this. Packagers would have to
> > > submit a ticket requesting to orphan a certain package's EPEL branch(es)
> > > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> > > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> > > could have a provenpackager in the SIG go through and manually retire
> > > the packages that haven't been picked up after six weeks. The later will
> > > be difficult if we have a large volume, but I don't expect that. We
> > > could script this if necessary or just ask the submitter to do it
> > > themself.
> > >
> > > This doesn't allow picking up packages in a self-service manner, but I
> > > don't think that's a huge deal for our case.
>
> After some discussion in our weekly EPEL Steering Committee meeting
> Maxwell's idea seems to lead the way.
> Maxwell has setup of pagure repo, to track these orphan issues.
> A pagure repo gives us the opportunity to have a nice README that people
> can see if they are unsure of the process.
> A pagure issue also seems more user friendly than a bugzilla.  Both for the
> person creating the issue, and for others tracking it.
>
> https://pagure.io/epel/package-orphan-requests

So, I've started working on this. So far, I have a structured issue template, 
and I've started writing a tool to go through the issues and act on them 
(creating an announcement, etc. 
While I had originally wanted to use a Pagure issue tracker, I decided to 
switch to Gitlab half way through. There were three reasons:

* The Pagure API does not allow tagging existing issues. I had planned to 
liberally use tags to manage the issues.
* Gitlab already has a nice Python wrapper (python-gitlab), which is much 
easier to work with.
* It's more future proof, as the state of Pagure in Fedora is a bit up in the 
air.

I really appreciate Pagure, and I wanted to make it work, but I'm trying to be 
pragmatic. Currently, the plan for identity verification is to make sure the 
sure the user is a member of the Fedora group on Gitlab. For non-matching 
usernames, I should be able to provide a dedicated field for that and cross 
reference the custom username with the FAS Gitlab field. Does anybody know if 
it's possible to limit issue submissions to only Fedora members while keeping 
the issue tracker public? That would make this easier.

I have one question: who should be able to orphan EPEL branches? In Fedora, 
it's only the main 
admin. Do we also want to open this up to people with other privileges? 
Currently, anybody with any type of write permissions on a repository can 
retire the package. If the actual people who maintain the EPEL branches don't 
have permissions to orphan EPEL branches, I worry it will make the policy 
ineffective.
> The policy isn't setup yet, but we are moving in the right direction.

Indeed :).

[Neal Gompa]

On Tue, Aug 23, 2022 at 8:42 PM Maxwell G via epel-devel
 wrote:
> On Wednesday, August 10, 2022 4:07:29 PM CDT Troy Dawson wrote:
> > On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi  wrote:
> > > On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote:
> > > > We could create an issue tracker for this. Packagers would have to
> > > > submit a ticket requesting to orphan a certain package's EPEL branch(es)
> > > > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all
> > > > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we
> > > > could have a provenpackager in the SIG go through and manually retire
> > > > the packages that haven't been picked up after six weeks. The later will
> > > > be difficult if we have a large volume, but I don't expect that. We
> > > > could script this if necessary or just ask the submitter to do it
> > > > themself.
> > > >
> > > > This doesn't allow picking up packages in a self-service manner, but I
> > > > don't think that's a huge deal for our case.
> >
> > After some discussion in our weekly EPEL Steering Committee meeting
> > Maxwell's idea seems to lead the way.
> > Maxwell has setup of pagure repo, to track these orphan issues.
> > A pagure repo gives us the opportunity to have a nice README that people
> > can see if they are unsure of the process.
> > A pagure issue also seems more user friendly than a bugzilla.  Both for the
> > person creating the issue, and for others tracking it.
> >
> > https://pagure.io/epel/package-orphan-requests
>
> So, I've started working on this. So far, I have a structured issue template,
> and I've started writing a tool to go through the issues and act on them
> (creating an announcement, etc.
> While I had originally wanted to use a Pagure issue tracker, I decided to
> switch to Gitlab half way through. There were three reasons:
> The Pagure API does not allow tagging existing issues. I had planned to
>
> liberally use tags to manage the issues.

What? You can do this with the "update issue information" API call:
https://pagure.io/api/0/#issues-tab

This is done by the CentOS Hyperscale folks for the package-updates
tracker: https://pagure.io/centos-sig-hyperscale/package-updates

The automation for it is present in that repo.

[Maxwell G]

On Tuesday, August 23, 2022 7:49:15 PM CDT Neal Gompa wrote:
> > The Pagure API does not allow tagging existing issues. I had planned to
> >
> > liberally use tags to manage the issues.
>
> What? You can do this with the "update issue information" API call:
> https://pagure.io/api/0/#issues-tab

According to the documentation, the only valid inputs to "Update issue 
information" are "title" and "issue_content". https://pagure.io/pagure/issue/
4761 was opened for this and never closed. Is there some undocumented 
parameter?

[Neal Gompa]

On Tue, Aug 23, 2022 at 9:00 PM Maxwell G  wrote:
> On Tuesday, August 23, 2022 7:49:15 PM CDT Neal Gompa wrote:
> > > The Pagure API does not allow tagging existing issues. I had planned to
> > >
> > > liberally use tags to manage the issues.
> >
> > What? You can do this with the "update issue information" API call:
> > https://pagure.io/api/0/#issues-tab
>
> According to the documentation, the only valid inputs to "Update issue
> information" are "title" and "issue_content". https://pagure.io/pagure/issue/
> 4761 was opened for this and never closed. Is there some undocumented
> parameter?

Nope, I misread this. Sorry.