AUR web interface

**This is the bug tracker for the AUR web interface.**

Use this tracker to report bugs or make feature requests regarding the behaviour or implementation of the AUR software.
Please read the Reporting Bug Guidelines before filing a new task.

- Please report bugs related to Arch Linux official packages here:
- Please report bugs for [community] packages here:
- For any packages in the AUR contact the maintainer or leave a comment on the package's detail page.

Source Code:

FS#50079 - orphan requests does not remove co-maintainers

Attached to Project: AUR web interface
Opened by Ido Rosen (idorosen) - Sunday, 17 July 2016, 18:35 GMT
Task Type Bug Report
Category Backend
Status Unconfirmed
Assigned To No-one
Architecture All
Severity Medium
Priority Normal
Reported Version 4.2.0
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No


It looks like orphan requests on AUR do not remove co-maintainers, so that when a package is orphaned and taken over by another.

Here's the order of operations:

[package: dpkg, maintainer: ido, comaintainer: lotia] --(orphan request by bertptrs)--> [maint: bertptrs, comaint: lotia] --(disown request by bertptrs)--> [maint: lotia].

So, is it possible that the comaintainers are not cleared when an orphan request is submitted?

(Note: For a disown request, it makes sense that the comaintainer should become the maintainer. For an orphan request, the comaintainers should probably be removed to avoid a situation where the new maintainer who adopts the package then disowns the package and leaves the old inactive comaintainer as the new maintainer from before the orphan request...)
This task depends upon

Comment by Ido Rosen (idorosen) - Sunday, 17 July 2016, 18:51 GMT
Oops, the first paragraph should read:

It looks like the automatically honored orphan requests (after a package is flagged out of date for a while) on AUR do not remove co-maintainers, so that when a package is orphaned and taken over by another maintainer, the new maintainer inherits the old comaintainers. Then, if that new maintainer that adopted after the orphan request disowns the package, the comaintainer (from before the orphan request) becomes the new maintainer. This prevents the old maintainer or other active users from re-adopting the package. If there were multiple co-maintainers, then there would have to be multiple orphan requests in a row to fully remove all inactive maintainers.

The current behavior leads to some confusion. Maybe the behavior should be:

1. If the orphan request comes from a comaintainer, make that person a maintainer and the current maintainer becomes a comaintainer (swap).
2. If the orphan request does not come from a comaintainer, remove all maintainers and comaintainers.

Comment by Lukas Fleischer (lfleischer) - Thursday, 10 May 2018, 07:39 GMT
Your suggestion sounds quite sensible to me. I wonder whether this is what everyone would expect, though...
Comment by Eli Schwartz (eschwartz) - Thursday, 10 May 2018, 13:46 GMT
If an orphan request is accepted, it's because the current maintainer is failing to fulfill the function of a maintainer. Given that comaintainers exist in order to share that burden, the logical extension to that is they weren't doing their job either.

If orphan requests are accepted I think we should just proceed straight to removing comaintainers, since keeping them results in this bug.

In the unlikely event a comaintainer is still active, they have the same chance as anyone else to adopt it.
Comment by Lukas Fleischer (lfleischer) - Thursday, 10 May 2018, 16:42 GMT
It may happen that the maintainer disappears while a co-maintainer remains very active. At some point, the co-maintainer might want to become a proper maintainer. It seems weird to ask him to file a request which removes himself, only to adopt the package later.
Comment by Eli Schwartz (eschwartz) - Thursday, 10 May 2018, 19:17 GMT

Does that really happen? I figured if the comaintainer is active, they don't really need to become a "proper" maintainer, unless they specifically wish to manage the comaintainer list. And if so, a rarely-seen maintainer might still be around "somewhere" and not want to do that.

Practically speaking, I don't remember seeing an instance of this happening during the time I've been an active TU. I guess I could download and search the aur-requests archives to check.

I'm not sure whether to special-case "request came from a comaintainer". I definitely think in general we should be more consistent about "cleaning house".
Comment by Eli Schwartz (eschwartz) - Thursday, 10 May 2018, 20:56 GMT
So on second thought, neither I nor Lukas seem to be able to figure out why this happens at all. See

It looks like any TU action to orphan a package automatically results in removing comaintainers, which is the behavior I specified.

Are you positive the comaintainer was not manually re-added by the person who adopted it?
Comment by Lars Rustand (lrustand) - Thursday, 15 August 2019, 06:50 GMT
I can confirm this bug is still present, because I had to remove the old comaintainer from a package I adopted after filing an orphan request. I think the orphan request might have been automatically accepted, but I'm not sure.