That's the main reason why i asked for it. I have my own repo, maybe that's why i'm not interested in [community]. But AUR have huge list of orphaned, outdated, obsolette packages. Most of them can be deleted, since they have no use now. I see them nearly everyday, and... Well, i think you catch that. AUR needs moderators. AUR must be clean. Sorry for my bad english =(
That's the second time you've chanted the "AUR needs moderators. AUR must be clean." mantra. I strongly disagree with your conception of "clean". Many orphans and other neglected package in the AUR could easily updated by anyone who's interested in them. It doesn't hurt to have them there either, so why should we remove them? There are admittedly some packages which are completely dead upstream, or which are truly obsolete for other such reasons (changes in revision control, etc), but I do not want to see a team of "seek-and-destroy moderators" combing the AUR for every little package they can delete. That will just lead to a loss of potentially good packaging starting points. The other issue is trust. The argument put forward so far has been that because AUR moderators have limited powers, they may be appointed with less consideration. Even if they can't access official binary repos, they could still do some major damage if they were so inclined. Imagine an AUR moderator who writes a script to simultaneous adopt several popular packages and upload malware in their place. It would be quickly detected and the moderator status could be revoked along with a heavy blow of the ever-so-frightening banhammer, but how many users might be affected within that window? AUR mods would have to be trusted and then one has to ask what the difference between and AUR mod and a TU would be. A whole new position just to create a slightly crippled TU account doesn't make sense to me, especially considering how well the current system works. There isn't exactly a flood of AUR requests inundating this list to the point where TUs can't keep up. I'm actually happily surprised on the rare occasions that I am the first one to find and handle such a request. I think a better solution, if there is even a problem to begin with, is to create a TU dashboard for the AUR and add buttons to the interface to request adoption or deletion. Adoption requests could send an email to the maintainer and then a TU could see on the dashboard how long ago the email was sent, along with other information such as how long a package has been flagged out of date and when the maintainer was last active. Using that information, the TU could then decide to approve the adoption, which would then transfer the file directly to that user. The adoption request button could also only appear after the package has been flagged out-of-date for a while, or using some other conditional metric such as maintainer inactivity. It would also make it clear that a user who requests a deletion is the same user how uploaded the package (or is the current maintainer). On the related issue of a network of trust for AUR users, the proposed suggestions, while interesting, are just too complicated to get implemented. We can't even get signing for official packages and the general spirit around innovation, at least as I've perceived it, is not one of enthusiasm. A more practical approach would be to extend the voting system to enable users to vote confidence points for other users. Just add a "Trust Level" or whatever to the web page and JSON output. TUs would naturally have some special status (e.g. "TU" instead of the vote count, and TU's votes could also be considered specially, which would enable TUs to effectively tag users which they trust. This framework could be incorporated into AUR frontends (I would definitely support it in Bauerbill). Along with the votes one would need to see who voted though, to prevent manipulated vote counts via botting. A new search type would probably be needed on the RPC interface, which would let you search by user. The results would contain an array named "trusts" and the names of AUR users trusted by the user, "trusted by" with an array of users that trust the user, and "trust level" of whatever, which shows "TU", "TU-trusted", or the number of votes (thinking out loud here).