Re: [aur-general] TU without [community] maintaining?
On 02/03/2010 02:41 PM, Thomas Bächler wrote:
Am 03.02.2010 15:32, schrieb Lex Rivera:
Hi all. I wanna ask is it possible to become TU without [community] maintaining, just as AUR moderator?
I think it is a good idea. We could create the "AUR moderator" position instead of calling it "Semi-TU".
When I was a TU, I didn't care at all about moderating the AUR, and maybe other TUs feel the same and rather do packaging. Conversely, you don't seem to care about packaging but about AUR moderation.
I am forwarding this to arch-dev-public for reference, but I guess ultimately the TUs have to decide.
I also think there is a lot of work to be done "polishing" the AUR, and that could be a good start.
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 =( On 03/02/10 15:58, Andrea Fagiani wrote:
On 02/03/2010 02:41 PM, Thomas Bächler wrote:
Am 03.02.2010 15:32, schrieb Lex Rivera:
Hi all. I wanna ask is it possible to become TU without [community] maintaining, just as AUR moderator? I think it is a good idea. We could create the "AUR moderator" position instead of calling it "Semi-TU".
When I was a TU, I didn't care at all about moderating the AUR, and maybe other TUs feel the same and rather do packaging. Conversely, you don't seem to care about packaging but about AUR moderation.
I am forwarding this to arch-dev-public for reference, but I guess ultimately the TUs have to decide.
I also think there is a lot of work to be done "polishing" the AUR, and that could be a good start.
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).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA224
On Thu, 4 Feb 2010 01:34:21 +0100
Xyne
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@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-----
participants (4)
-
Andrea Fagiani
-
Lex Rivera
-
Thorsten Töpper
-
Xyne