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.

Should the relevant policies distinguish between packages that are both retired and orphaned, and packages that retired but not orphaned?

That sounds like a good idea to me.

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.

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.

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.

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.

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?

So my understanding is that the person maintaining the given package on Rawhide should be the main admin of the package.

In my experience, this is sadly not the case for a lot of packages, so I don't think it can be relied on.

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?

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.

Attempt to un-stick this old ticket:

For un-retirement of non-orphaned packages: Maybe it would make sense to require packagers who want to un-retire packages that still have a "main admin" to become co-maintainers of the package first? Maybe by following a similar process to the one for stalled requests (or even the same process)?

Formal proposal: Before unretirement of a package that is not (yet) orphaned is processed, the new maintainer must first become a co-maintainer of the package, either by requesting and being granted access from the current maintainer(s), or by following the stalled requests process. The "main admin" role of the package will not automatically be transferred on unretirement unless this is explicitly requested, and acknowledged by the old "main admin".

This seems like a tiny corner case, but it sounds reasonable to me. +1

+1

So is this technically approved now? Counting myself as +1 for my own proposal, this looks like (+3, 0, -0) after 7 weeks :sunglasses: ...

At the very least I'll go ahead and remove the "stalled" tag since there was an actual proposal and votes are happening.

This was approved during today's meeting (logs):

AGREED: The last proposal in the ticket is approved (+7, 0, -0).
The Un-retirement policy will be updated accordingly.
(@decathorpe:fedora.im, 17:40:53)

I will prepare a PR for the Unretirement Policy.