FS#17911 - aur packages should have the ability to support multiple maintainers

Attached to Project: AUR web interface
Opened by Anish Bhatt (anish) - Wednesday, 20 January 2010, 02:23 GMT
Last edited by Lukas Fleischer (lfleischer) - Tuesday, 09 June 2015, 06:56 GMT
Task Type Feature Request
Category Backend
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture All
Severity Low
Priority Normal
Reported Version 1.6.0
Due in Version 4.0.0
Due Date Undecided
Percent Complete 100%
Votes 9
Private No

Details

many packages have multiple people maintain them and do bug fixing, however updates are allowed only to packaged maintainers, and there can be only one maintainer per package. this can result in bug fixes being available, but packages not being updated because the aur maintainer is missing, or duplicate packages because the one and only maintainer has abandoned his/her aur package.

solution : support multiple maintainers for one package, or add hierarchy such that maintainer can give others permission to update.
This task depends upon

Closed by  Lukas Fleischer (lfleischer)
Tuesday, 09 June 2015, 06:56 GMT
Reason for closing:  Implemented
Additional comments about closing:  Implemented in 4.0.0-rc1.
Comment by Ray Rashif (schivmeister) - Monday, 07 June 2010, 18:44 GMT
Allowing "multiple maintainers" should never happen. There has to be a limit. Even with a permission-based system, the list of allowed contributors would be arbitrary and we can assume it can grow to allow "everyone", which is a moot point.

For important/useful/popular PKGBUILDs one can set up an svn or git repo to allow those interested in that particular package to contribute.
Comment by Gavin Bisesi (Daenyth) - Monday, 07 June 2010, 18:51 GMT
Archweb supports multiple maintainers for official packages. I don't see the problem for these. Why shouldn't we allow a list of users?
Comment by Anish Bhatt (anish) - Monday, 07 June 2010, 18:55 GMT
You don't need a svn/git repo to have users contribute, they already do that via the comments anyways, but it still comes down to the maintainer to update the package. Besdies, this has already been implemented for arch repo maintainers. Plus there are other issues like maintainers abandoning maintainence without actually abandoning package ownership. And most FOSS stuff always has multiple maintainers.
Comment by Ray Rashif (schivmeister) - Monday, 07 June 2010, 19:52 GMT
Archweb is not open to everyone, unlike the AUR. Allowing any registered AUR user to click "join as a contributor" (or a derivative thereof) is a potential risk for good PKGBUILDs being maintained properly, assuming that immediately upon "joining" that user is able to upload (and thus replace) a PKGBUILD. It is not as trivial to "revert" changes like in a revision system.

I'm not against a permission-based implementation, actually. Just that I don't think it'll be trivial to implement :)
Comment by Gavin Bisesi (Daenyth) - Monday, 07 June 2010, 20:52 GMT
example:

User clicks "adopt package". If no maintainer, user is set as maintainer. If there is an existing maintainer, he is asked to share ownership. If he accepts, then the user is added as a maintainer. They'd all have equal rights, and a disown would remove the user from the list.
Comment by Ray Rashif (schivmeister) - Monday, 07 June 2010, 20:57 GMT
Yes, that one would be fine :)
Comment by Anish Bhatt (anish) - Monday, 07 June 2010, 20:57 GMT
That might open it up to hijacking, if the new maintainer can remove the previous maintainer. Better to let the current maintainer grant requests or have tiered rights.
Comment by Gavin Bisesi (Daenyth) - Monday, 07 June 2010, 21:02 GMT
Tiered rights would be a little harder to do, and I don't think it's needed. Maintainers could only remove themselves, not the other. TUs would handle removing someone else as they currently handle deletions. If you don't trust someone, don't accept the request. I think that would be fine. ACLs would be really overengineered for this I think. What rights could possibly be denied? The only real thing that being a maintainer lets you do it upload new builds and set category.
Comment by Ray Rashif (schivmeister) - Monday, 07 June 2010, 21:05 GMT
Now, it appears we're rushing probabilities. The existing maintainer will already be the one who decides whether to accept the request (I'm sure there will be some kind of communication between them). So in that case, we blame it on his/her wise decision, and then the offending contributor can be jacked for real :P
Comment by Anish Bhatt (anish) - Monday, 07 June 2010, 21:09 GMT
Sounds about right. We can never make it 100% bulletproof anyways.

Now, if only any of us knew how to actually code for this :P
Comment by Tomas Mudrunka (harvie) - Friday, 06 August 2010, 00:56 GMT
What about basing AUR on GIT? (eg.: i have all my packages on github, so anyone can send me git-formated patch or pull request. btw: http://github.com/harvie/archlinux-packages )

And yes. At least patch and diff support would be cool.
Every package can have directory ./patches/ in it and users will be able to upload unlimited amount of patches (or even PKGBUILDS which will be processed using diff after upload) to it. There will be nice colorfull diffview and maintainer will be able to accept or reject the diff with single click. There can even be accept/reject links in notification mail, so we will be able to accept/reject the patch from mail using one single click on link.
Comment by (Det) - Monday, 08 April 2013, 23:43 GMT
Just maybe also add some daily cap for the amount of requests a single maintainer can receive (and maybe even some *Block* button for people who can't take the message). Also the unaccepted requests should expire at some point.

Then of course the other possibility would be for the 'main' maintainer himself to send requests to other people. If that could be combined with  FS#34692  in inactive cases, that'd be.. well awesome.

And for the fact that somebody might destroy other one's package there should be some sort of backup logic. It's not enough to just revert to what the package used to be after the main maintainer's last commit, since that might have been a _long_ time ago.
Comment by UnicornDarkness (Xorg) - Wednesday, 07 January 2015, 16:34 GMT
I see it's implanted with commit #fc23a9b (https://projects.archlinux.org/aur.git/commit/?id=b32458cb8a043422bfc2962c03a70deaee9eaca9).

But why not allow pull requests, or something like that ?
Comment by Lukas Fleischer (lfleischer) - Wednesday, 07 January 2015, 17:21 GMT
You can use git-send-email(1) or any GitHub-like service for pull requests. Git is a distributed VCS.

Loading...