This makes sense (apart from one thing), however what bothers me is this:

If a maintainer no longer has time, we should make orphaning as easy as possible. If we make it hard, the maintainer will rather not do it and we will have a nonresponsive maintainer problem.

What we could do is to have automation that responds to a package being orphaned by e-mailing the comaintainers and dependent packages maintainers. However this is currently actually covered by the "Orphaned packages to be retired" e-mails I send.

Likewise any automatic processes doing orphaning should also simply make the first next admin, or co-maintainer the new main-admin rather then blindly orphaning a package.

Automatic orphaning is always accompanied with intensive bugzilla bombarding. Either with the nonresponsive procedure or with the FTBFS procedure. If the comaintainers ignore this bugzilla requests they should not be automatically made main admins as there are most likely unresponsive as well. They can dtill become main admins by their own choosing.

Hi,

On 15-02-19 13:24, Miro Hrončok wrote:

This makes sense (apart from one thing), however what bothers me is this:

If a maintainer no longer has time, we should make orphaning as easy as possible. If we make it hard, the maintainer will rather not do it and we will have a nonresponsive maintainer problem.

What we could do is to have automation that responds to a package being orphaned by e-mailing the comaintainers and dependent packages maintainers. However this is currently actually covered by the "Orphaned packages to be retired" e-mails I send.

Except that that happens after the fact. Now if http://src.fedoraproject.org/ would
have a take-it button for orphaned packages (like pkgdb used to have) then that
would be fine.

But since http://src.fedoraproject.org/ lacks a way to easily take-over a package
after it has been orphaned we need to have the co-maintainer mails happen up-front
not afterwards.

That or make it a lot easier to take-over an orphaned package.

Likewise any automatic processes doing orphaning should also simply make the first next admin, or co-maintainer the new main-admin rather then blindly orphaning a package.

Automatic orphaning is always accompanied with intensive bugzilla bombarding. Either with the nonresponsive procedure or with the FTBFS procedure.

Ok.

If the comaintainers ignore this bugzilla requests they should not be automatically made main admins as there are most likely unresponsive as well. They cans till become main admins by their own choosing.

Is that so, how do I become the main-admin of a package where I'm not the main
admin, I've never seen a button for that in the interface. Also I would expect
this option to not be open for co-maintainers (vs co-admins).

Regards,

Hans

The pkgdb-like buttons are missing and it is a pain, I agree.

how do I become the main-admin of a package where I'm not the main admin

With the nonresponsive maintainer policy, just ask in the FESCo issue. Example.

With the FTBFS policy, I have no idea, as the policy has so far only been theoretical.

On 15-02-19 13:33, Miro Hrončok wrote:

how do I become the main-admin of a package where I'm not the main admin

With the nonresponsive maintainer policy, just ask in the FESCo issue. Example.

That is not exaction "frictionless", this will work for the person
starting the nonresponsive maintainer policy, but it would be really
good to have a way for maintainers with package-deps which are
caught in the crossfire to also have an easy way to pick-up these
packages.

With the FTBFS policy, I have no idea, as the policy has so far only been theoretical.

So on both cases the story will probably end up being file a ticket
with rel-eng meaning an extra hurdle for the maintainer to overcome
and extra work for rel-eng.

Thinking about this more, the problem might not be the orphan-procedure
itself, but for a big part also the unorphan procedure.

Is there any specific reason why the new http://src.fedoraproject.org/
interface does not have a "take over package" button for people who are
already package-maintainers, like pkgdb used to have?

Or is this just an oversight which has been papered over with
"file an issue with rel-eng" as stop gap measure?

Is there any specific reason why the new http://src.fedoraproject.org/
interface does not have a "take over package" button for people who are
already package-maintainers, like pkgdb used to have?

I believe the specific reason is that nobody wrote that functionality, not hat we would not want it.

BTW See also Automate Unretirement and Unorphan procedures.

This means that even if a package has active co-maintainers or co-admins, if the main admin decides he no longer has time, the package gets orphaned, which is rather silly.

Yes, +💯 to this

Each time this happens the co-maintainers need to spend time to file a ticket with rel-eng to unorphan the package and rel-eng needs to spend time time to fix things.
I believe we can avoid this needless churn by changing the Orphan procedure to include a new step 1. where the person doing the orphaning must first check if there are co-maintainers and must first offer to "give" the package to them before orphaning it.
This may seem obvious, but judging from current experiences it looks like this needs to be explicitly spelled out.

Indeed +1

Likewise any automatic processes doing orphaning should also simply make the first next admin, or co-maintainer the new main-admin rather then blindly orphaning a package.

I personally agree with this.

A second improvement to the procedure for manually orphaning a package would be adding a step 2. (after the new step 1.) which requires the person doing the orphaning to run:
sudo dnf repoquery --whatrequires <packagename>

Yeah and also for --srpm. (Though we should really have scripts for these things.)

And ask them to contact maintainers of any pkgs which show there, asking those maintainers if they want to take-over the package.
This means asking some extra work from the orphaner, but we are all members of the same community and I believe a simple courtesy like this to fellow community members when orphaning packages is important.

I agree

Automatic orphaning is always accompanied with intensive bugzilla bombarding.

Only if there are open bugs, right?

Automatic orphaning is always accompanied with intensive bugzilla bombarding.

Only if there are open bugs, right?

There is AFAIK no automatic orphaning without bugs.

The nonresponsive maintainer demands a bugzilla.

Mass rebuild FTBFS also is handled in bugzilla.

Is there any other automatic orphaning?

Yeah I think the real problem here is the retirement of pkgdb. Fedora lost many features with the switch away from it, not just this problem. IMO, it would be better to focus on fixing those problems because adopting an orphaned package should be easy and should not involve releng.

The procedure as documented on wiki made sense when we had pkgdb. My proposal would be to add a recommendation to ask the co-maintainers or on fedora-devel before orphaning, iff the owner has time to do this. Otherwise, simply orphan as currently described. This should allow people to perform orphaning without overhead if they don't have time, but still avoid releng involvement in many cases.

Once we get the pkgdb functionality back, we can consider reverting this change.

Is there a proposal to vote on?

This was discussed in today's meeting:
AGREED: APPROVED: A recommendation to ask the co-maintainers or on fedora-devel before orphaning, iff the owner has time to do this is to be added. (+7, 0, 0)

I edited the page that describes the procedure:
https://fedoraproject.org/w/index.php?title=Orphaned_package_that_need_new_maintainers&type=revision&diff=535785&oldid=531528

Nitpick:

The current list of maintainers can be found in the "Users & Groups" tab of the setting for the package repo. The URL will look something like this — https://src.fedoraproject.org/rpms/PACKAGE_NAME/settings.
2. After the first step is finished, visit your package's Pagure repository, and navigate to the settings tab.

The second step is now basically "go to the URL from step 1".

(I don't know how to rephrase that.)

Indeed. Reworded to avoid the repetition. It also didn't make sense to have "navigate to your repo" as a separate bullet point, so I merged points 2 and 3.