[aur-general] TU without [community] maintaining?

[Xyne]

> 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).