i also think automation is not the way to go. but the aur could be a lot more userfriendly. 3 things come to my mind:
1) removal request button - for the mainatiner only. This couldn't hurt if there's a text field for giving reasons why the
Am 21.09.2010 02:22, schrieb Ulf Winkelvos: package shall be removed. But I don't see a benefit. It's not more work to write a short e-mail to the mailing list. The e-mail actually has more advantages because with such a button you can send a removal request for only one package and you need to send a separate removal request for every package. In an e-mail you can add package names and the links to them for several packages at once. So I'd prefer not having such a button.
2) mark as dublicate button - needs 3 (? to prevent abuse) votes from different users Why do you need votes for reporting duplicates? A package is either a duplicate or it is not. This is not a democratic question. And like the removal request button I don't see an advantage to a simple e-mail.
3) orphran request button - needs 1 vote or a percentage of total usage votes - is only available when the package is flaged out of date for 7-14 days. This is not a democratic question, too. Read my first e-mail in this thread. This definitely will be abused by impatient people who don't want to ask if there's a reason why a package is not updated. And 7 to 14 days is far too short (e.g. holidays, bugs in the new version, etc.).
all requests are send to the mailing list. So TUs still have full control, but ist pretty handy for users that are not on the ml. So why then implement such buttons? Why not send an e-mail directly to
Another thing: Multiple maintainers would be realy nice... although anybody should put more thought into that, as it could easily become pretty messy. Can be nice. But a second maintainer may only be added by the first
And who shall adopt this package? Most of those impatient users certainly don't really want to adopt and maintain this package, And I bet that no one of those voters will try to contact the maintainer before voting. So such an orphan request button *must not* be implemented. The way it is currently is the way to go. The user who wants to adopt a package and who probably already has an updated PKGBUILD first must try to contact the maintainer by AUR comment and by private e-mail, must wait at least two or three weeks for respons, must probably try to contact the maintainer a second time and then send an orphan request to the mailing list, so that a TU can first review this request. This is the only way this can be done. But definitely not by voting in the AUR. the mailing list? See the advantages above. And some of those request *must not* get a voting feature because they are just ineligible. maintainer. Otherwise this can easily be abused by those impatient people. See above. In case of packages on which are working to people together who are in contact with each other regarding this package this could make it a bit easier. But in such a case only the maintainer of the package may add the second maintainer. Heiko