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

[Thorsten Töpper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224

On Thu, 4 Feb 2010 01:34:21 +0100
Xyne <xyne at archlinux.ca> wrote:
> 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.

I fully agree with Xyne here, as long as sources are available, the
PKGBUILDs should be kept in AUR, even if they're outdated, who knows
if not someone will take it in a month, update it and maybe even the
whole project revives. Keeping them does not hurt.
 
> 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 thought about that the last hours and I also did not came up with any
real reason for that. Actually I myself am focusing on requests that
are sent here to the list under the week, as I am not able to build
packages when I'm at the university. Still I can read mails and use the
browser while making notes to the lecture, so I don't think it's wrong
if a TU doesn't want to maintain packages, but just keep an eye at the
AUR.

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

That sounds good, however I haven't looked at the Code of the AUR so I
don't know how much work it'll be to implement that.

> 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).
 
I don't think that's a bad idea, however I'm still thinking about the
way it'll change the behaviour of users.

Atsutane
- -- 
Jabber: atsutane at freethoughts.de Blog: http://atsutane.freethoughts.de/
Key: 295AFBF4     FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iFYEARELAAYFAktrUiYACgkQOeTxfyla+/RAbADeIXkw8AAk3yP4w7qOBecClPVV
lRvjqZL7Zuk7FgDfVewSTYHkhPVsQgcjRCVaZ8VxLspKaHUFwCdY1Q==
=+J2s
-----END PGP SIGNATURE-----