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
Last edited by Kevin Morris (kevr) - Thursday, 10 February 2022, 01:09 GMT
Opened by Ido Rosen (idorosen) - Sunday, 17 July 2016, 18:35 GMT
Last edited by Kevin Morris (kevr) - Thursday, 10 February 2022, 01:09 GMT
|
Details
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
Closed by Kevin Morris (kevr)
Thursday, 10 February 2022, 01:09 GMT
Reason for closing: Fixed
Additional comments about closing: https://gitlab.archlinux.org/archlinux/a urweb/-/merge_requests/447 is now live on aur.archlinux.org
Thursday, 10 February 2022, 01:09 GMT
Reason for closing: Fixed
Additional comments about closing: https://gitlab.archlinux.org/archlinux/a urweb/-/merge_requests/447 is now live on aur.archlinux.org
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.
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.
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".
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?