It occurs to me that in some ways, the package unretirement policy / process is inconsistent, and might lead to undesirable outcomes. For example, I still actively maintain a few packages on f37/f36 but I retired them from f38/rawhide because they're unused there.
Filing an unretirement ticket for any of these packages would result in me being removed as the main maintainer entirely, and give the package to somebody else, even though I'm still actively maintaining the package on older branches.
c.f. https://pagure.io/releng/issue/11372
Should the relevant policies distinguish between packages that are both retired and orphaned, and packages that retired but not orphaned?
Can this be handled similarly to EPEL branch requests? There the rule is that the current maintainer must either maintain EPEL or let the requester do that as a co-maintainer? Also the communication starts with a Bugzilla issue, which should work here as well.
One thing to consider is that currently, there are probably many truly retired packages that are not marked as orphaned. Apparently no automation or guidance moves them to that state.
That sounds like a good idea to me.
This is similar to what's documented here: https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
Though even those docs talk about a "former maintainer". I'm not the "former" maintainer of these packages, I am the actual maintainer, the packages were just dropped from rawhide ... that doesn't mean that I abandoned them.
There actually is automation to do this. Once a package is retired on all current branches of Fedora, the main admin is set to "orphan" and all other maintainers are removed. So it does happen, it just takes a few years to take effect.
I'm afraid it's "Once a package is retired on all current branches of Fedora and EPEL..." which takes a while considering epel7.
Metadata Update from @sgallagh: - Issue tagged with: stalled
So my understanding is that the person maintaining the given package on Rawhide should be the main admin of the package.
We can add a check into the unretirement process, and in the case that the rawhide is retired and gets unretired, we will need a check for any other active branches and set the previous main admin as a collaborator on that branch or as a co-admin. WDYT?
In my experience, this is sadly not the case for a lot of packages, so I don't think it can be relied on.
I don't think that's a good idea. If a package is retired but not orphaned, there's usually a reason why the package is in this state.
Log in to comment on this ticket.