On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon wrote:

Thomas Bächler wrote:

...

I think it is a good idea. We could create the "AUR moderator" position instead of calling it "Semi-TU".

This is a fine idea, and I see no harm in it.

Im in favour of this, my unique concern is about how hard will be creating another level of permission in the AUR, and some rules about, if a semi-tu can orphan packages from TUs or TU-Dev, figuring out that part, and assuming that will have an approbation, we will start writting patches, so this can be a "slow" process, (2 months or so if it's aproved? plus the time of discussion?). Let's see what happens! -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com

On Wed, Feb 3, 2010 at 12:37 PM, Florian Friesdorf wrote:

On Wed, Feb 03, 2010 at 12:31:37PM -0300, Angel Velásquez wrote:

...

On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon wrote:

...

Thomas Bächler wrote:

...

I think it is a good idea. We could create the "AUR moderator" position instead of calling it "Semi-TU".

This is a fine idea, and I see no harm in it.

Im in favour of this, my unique concern is about how hard will be creating another level of permission in the AUR, and some rules about, if a semi-tu can orphan packages from TUs or TU-Dev, figuring out that part, and assuming that will have an approbation, we will start writting patches, so this can be a "slow" process, (2 months or so if it's aproved? plus the time of discussion?).

I'd give an AUR moderator all permissions to mess around in the AUR, be it packages of TUs or not. If somebody messes up, he/she can be punished later.

Lol no punishment! I don't wanna hit anybody!; Well, other question how will be the process of selection of these semi-tu ? how will be called the group semi-tu ? trusted but not at all? there are many many questions until we can make this idea possible. Just that.

-- Florian Friesdorf  GPG FPR: EA5C F2B4 FBBB BA65 3DCD  E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: flo@chaoflow.net  OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC

-- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com

Am 03.02.2010 16:44, schrieb Angel Velásquez:

On Wed, Feb 3, 2010 at 12:37 PM, Florian Friesdorf wrote:

...

I'd give an AUR moderator all permissions to mess around in the AUR, be it packages of TUs or not. If somebody messes up, he/she can be punished later.

Agreed. They should be responsible enough to not do any bullshit.

Well, other question how will be the process of selection of these semi-tu ?

Application, vote, done. It shouldn't be that complicated.

how will be called the group semi-tu ? trusted but not at all?

I'd simply say "AUR Moderators". We have moderators on the forum, and on the wiki, so having them on the AUR makes sense - it is in fact a bit late, the AUR is too much anarchy for my taste. I'd suggest so start the process by just voting upon Lex and if (s)he (sorry, can't determine the sex from that name, my stupidity) is approved, one will see how it goes and if it's a good idea. Then one can think about adding more moderators or not. Just KISS.

On 03/02/10 19:57, Thomas Bächler wrote:

Am 03.02.2010 16:44, schrieb Angel Velásquez:

...

On Wed, Feb 3, 2010 at 12:37 PM, Florian Friesdorf wrote:

...

I'd give an AUR moderator all permissions to mess around in the AUR, be it packages of TUs or not. If somebody messes up, he/she can be punished later.

Agreed. They should be responsible enough to not do any bullshit.

...

Well, other question how will be the process of selection of these semi-tu ?

Application, vote, done. It shouldn't be that complicated.

...

how will be called the group semi-tu ? trusted but not at all?

I'd simply say "AUR Moderators". We have moderators on the forum, and on the wiki, so having them on the AUR makes sense - it is in fact a bit late, the AUR is too much anarchy for my taste.

I'd suggest so start the process by just voting upon Lex and if (s)he (sorry, can't determine the sex from that name, my stupidity) is approved, one will see how it goes and if it's a good idea. Then one can think about adding more moderators or not. Just KISS.

Lex/Alex/Alexander. Well, before we can set moderators, we must understand how that position will work from the code side. We can of course just grant access to orphan & delete, if i understood correctly.

On 04/02/10 05:24, Thomas Bächler wrote:

IMO, just setting them as Trusted Users in the AUR interface would suffice, at least short-term. Creating an "AUR moderator" position long-term is still a possibility.

It should almost suffice in the long term... That gives them full permissions on the AUR and no permissions for the [community] repo. The only thing they would have access to that maybe they should not is TU voting. Allan

On Wed, Feb 3, 2010 at 12:53 PM, Laszlo Papp wrote:

2010/2/3 Angel Velásquez :

...

On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon wrote:

...

Thomas Bächler wrote:

...

I think it is a good idea. We could create the "AUR moderator" position instead of calling it "Semi-TU".

This is a fine idea, and I see no harm in it.

Im in favour of this, my unique concern is about how hard will be creating another level of permission in the AUR,

It's not so long so obviously ...

It depends how time you consider "long-time"

...

and some rules about, if a semi-tu can orphan packages from TUs or TU-Dev, figuring out that part, and assuming that will have an approbation, we will start writting patches, so this can be a "slow" process, (2 months or so if it's aproved? plus the time of discussion?).

Uhm.. what.. really ? 2 monthes for you ?

2 months as a minimun, I said, could be more, after an aprovation (maybe this idea will be dissaproved), for me don't know how many long will be? it's long time .. so, are we in position of start a proposal? (defining it at least?)

Best Regards, Laszlo Papp

-- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com

On 02/03/2010 07:48 PM, Lex Rivera wrote:

The main reason why a asked for it is amount of crap in AUR. 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 12:31, Angel Velásquez wrote:

...

On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon wrote:

...

Thomas Bächler wrote:

...

I think it is a good idea. We could create the "AUR moderator" position instead of calling it "Semi-TU".

This is a fine idea, and I see no harm in it.

Im in favour of this, my unique concern is about how hard will be creating another level of permission in the AUR, and some rules about, if a semi-tu can orphan packages from TUs or TU-Dev, figuring out that part, and assuming that will have an approbation, we will start writting patches, so this can be a "slow" process, (2 months or so if it's aproved? plus the time of discussion?).

Let's see what happens!

-- Angel Velásquez angvp @ irc.freenode.net Arch Linux Trusted User Linux Counter: #359909 http://www.angvp.com

Let's start the cleaning here: http://aur.archlinux.org/packages.php?O=0&do_Orphans=Orphans&detail=0&C=0&SeB=nd&SB=v&SO=a&PP=25&outdated=on Maybe we should just delete all packages with no votes and that have been orphaned. -- Ape <Lauri Niskanen>

On Wed, Feb 3, 2010 at 12:55, Lauri Niskanen wrote:

Maybe we should just delete all packages with no votes and that have been orphaned.

-- Ape <Lauri Niskanen>

That seems like a terrible idea. We should only delete packages that no longer exist upstream or have been merged into another package.

On 03/02/10 18:58, Florian Friesdorf wrote:

On Wed, Feb 03, 2010 at 12:58:40PM -0500, Daenyth Blank wrote:

...

On Wed, Feb 3, 2010 at 12:55, Lauri Niskanen wrote:

...

Maybe we should just delete all packages with no votes and that have been orphaned.

-- Ape <Lauri Niskanen>

That seems like a terrible idea. We should only delete packages that no longer exist upstream or have been merged into another package.

+2 ;)

-- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: flo@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC

+100500, i explained why in my other mail to+100500 :)

On Wed, Feb 03, 2010 at 04:44:28PM -0500, Loui Chang wrote:

On Wed 03 Feb 2010 21:18 +0300, Lex Rivera wrote:

...

On 03/02/10 18:58, Florian Friesdorf wrote:

...

On Wed, Feb 03, 2010 at 12:58:40PM -0500, Daenyth Blank wrote:

...

On Wed, Feb 3, 2010 at 12:55, Lauri Niskanen wrote:

...

Maybe we should just delete all packages with no votes and that have been orphaned.

That seems like a terrible idea. We should only delete packages that no longer exist upstream or have been merged into another package.

+2 ;)

+100500, i explained why in my other mail to+100500 :)

Guys please stop the +X posts. It's a bit unnerving to read through threads full of these.

-1 ;) -- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: flo@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC

On Wed, Feb 03, 2010 at 06:48:34PM +0100, Lex Rivera wrote:

The main reason why a asked for it is amount of crap in AUR. 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 =(

In my opinion, the requested changes for AUR reported here are done very quickly, isn't it? And no special rights for AUR are needed to check the submitted packages. I see a lot of complexity, but I'm not sure for what added values. What should be the tasks for the AUR moderators? I can think of: - check submitted/changed PKGBUILDs (no special rights needed) - orphan/remove packages (IMO done quickly by TU's) - manage AUR accounts (same as above ...) - ? Cheers, Jaroslav -- Das beste Mittel gegen Zorn ist Abstand -- Lucius Annaeus Seneca (4-65 n.Chr.)

I have no problem with this idea :) AM - AUR Moderator TU - Trusted User Basically, AMs are TUs who have no time/do not want to package, but would rather be PKGBUILD hunters. Allow them access to do everything a TU can on the web interface, and modify a couple of things (like the TU dashboard) to suit their role. They may moderate discussions and advise on scripting (which should be a TU's job as well). Approval process may be the same as a TU application, with similar criteria. So this does not imply a less-capable position, and would demand the same kind of individuals that would apply to become Trusted Users. I have no problem with this idea, but I am not for or against it. As can be seen from the discussion, all the tasks this particular role will handle are already the responsibility of TUs now. If this motion passes, all that will happen is a theoretical reduced workload. +0 -- GPG/PGP ID: B42DDCAD

On Wed, Feb 03, 2010 at 06:04:52PM +0000, Pierre Chapuis wrote:

Le Wed, 03 Feb 2010 15:41:38 +0100, Thomas Bächler a écrit :

...

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 even think it could be a good idea to have "real" Trusted Users in the sense that they can be trusted as to which packages they publish on the AUR, not necessarily in binary form. They would be approved by some process, and then added to a list which could be used by software like yaourt / pakthan / bauerbill to let the users install their packages without checking the PKGBUILDs. The fact that a package on the AUR is maintained by one of these users (they would include current TUs and devs) would be accessible in the metadata (through the json RPC for example).

I know there used to be a flag like that on the AUR and that it didn't work, but I think it's mainly because it was on a "by package" basis instead of a "by user" basis, which makes it a lot more work for those who have to check.

As for what should be checked when users apply for this position, I would say at least:

- a sufficient expertise in packaging, proved by the existence of several good packages maintained by them on the AUR, and - a means to contact them efficiently (valid email address).

Anyway this is just my two cents as an Arch user, but I consider the lack of any way to trust AUR PKGBUILDs without reading them to be the thing that annoys me most with Arch as of now.

What about a peer trust network? Publishing packages on the AUR would involve giving an pgp public key. People sign their PKGBUILDs using their private key. People can define trust relationships towards other people ("I trust this person to write good PKGBUILDs" and "I trust this person's trust in other's"). Being a TU would mean to be signed by the TU-Authority (or whatever) and trusting the TU authority's trust would mean you can install packages that are created by TU's. -- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: flo@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC

On 02/03/2010 08:32 PM, Lex Rivera wrote:

On 03/02/10 19:10, Florian Friesdorf wrote:

...

On Wed, Feb 03, 2010 at 06:04:52PM +0000, Pierre Chapuis wrote:

...

Le Wed, 03 Feb 2010 15:41:38 +0100, Thomas Bächler a écrit :

...

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 even think it could be a good idea to have "real" Trusted Users in the sense that they can be trusted as to which packages they publish on the AUR, not necessarily in binary form. They would be approved by some process, and then added to a list which could be used by software like yaourt / pakthan / bauerbill to let the users install their packages without checking the PKGBUILDs. The fact that a package on the AUR is maintained by one of these users (they would include current TUs and devs) would be accessible in the metadata (through the json RPC for example).

I know there used to be a flag like that on the AUR and that it didn't work, but I think it's mainly because it was on a "by package" basis instead of a "by user" basis, which makes it a lot more work for those who have to check.

As for what should be checked when users apply for this position, I would say at least:

- a sufficient expertise in packaging, proved by the existence of several good packages maintained by them on the AUR, and - a means to contact them efficiently (valid email address).

Anyway this is just my two cents as an Arch user, but I consider the lack of any way to trust AUR PKGBUILDs without reading them to be the thing that annoys me most with Arch as of now.

What about a peer trust network? Publishing packages on the AUR would involve giving an pgp public key. People sign their PKGBUILDs using their private key. People can define trust relationships towards other people ("I trust this person to write good PKGBUILDs" and "I trust this person's trust in other's"). Being a TU would mean to be signed by the TU-Authority (or whatever) and trusting the TU authority's trust would mean you can install packages that are created by TU's.

-- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: flo@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC

Peer trust network? Isn't that too hard for ordinary user? Download key, import it, set trust level... If there will be some list of "Checked Users" this will be easier and friendlier. But peer trust net is nice idea anyway.

I agree that peer trust network is a nice idea and that pgp keys might be unnecessary. AUR accounts are already authenticated by the web system and user can be easily coupled with the uploaded files. You should be able to upload packages without any thrust status and also downloading and installing untrusted packages should be possible. There could be packages with trusted status, so the users wouldn't have that must packages to be checked by themselves. -- Ape <Lauri Niskanen>

Le Wed, 3 Feb 2010 19:55:55 +0100, Heiko Baums a écrit :

Am Wed, 03 Feb 2010 20:41:34 +0200 schrieb Lauri Niskanen :

...

I agree that peer trust network is a nice idea and that pgp keys might be unnecessary. AUR accounts are already authenticated by the web system and user can be easily coupled with the uploaded files.

You should be able to upload packages without any thrust status and also downloading and installing untrusted packages should be possible. There could be packages with trusted status, so the users wouldn't have that must packages to be checked by themselves.

This was previously implemented in and removed from AUR a long time ago. I guess there was a reason for this.

The reason was that only TUs could flag a package as trusted, and this was done by package and not by user, so it was a lot of work. Actually, if I remember well, I even think it was done by package *revision* which means packages had to be checked by TUs every time a new version was uploaded. It obviously couldn't scale. If the trust is given at the user level, it makes it much less trouble. For example, if the average "trusted" user has 20 packages, each of which has 5 revisions in the user's account's lifetime, it divides the amount of actions necessary by 100 (although it is more complex to check that a user can be trusted than that a package is safe). It is similat to the "give the man a fish" principle Archers should be familiar with. The drawback is that it is a bit less secure, probably, because ultimately more people have to be trusted. A trust network goes even further on both aspects (more scalability, less security). I'm not sure going that far is needed but it is a neat idea. -- catwell

On Wed, Feb 3, 2010 at 7:42 PM, Florian Friesdorf wrote:

On Wed, Feb 03, 2010 at 09:32:12PM +0300, Lex Rivera wrote:

...

On 03/02/10 19:10, Florian Friesdorf wrote:

...

What about a peer trust network? Publishing packages on the AUR would involve giving an pgp public key. People sign their PKGBUILDs using their private key. People can define trust relationships towards other people ("I trust this person to write good PKGBUILDs" and "I trust this person's trust in other's"). Being a TU would mean to be signed by the TU-Authority (or whatever) and trusting the TU authority's trust would mean you can install packages that are created by TU's.

Peer trust network? Isn't that too hard for ordinary user? Download key, import it, set trust level... If there will be some list of "Checked Users" this will be easier and friendlier. But peer trust net is nice idea anyway.

yaourt could ship with the TU-Auth's public key and it's default configuration could be to trust packages by people that are signed by the TU-Auth.

key management should further be integrated into yoaurt (or the like)

Yaourt is not supported officially, and it's buggy and abandoned program at this momment, and it has got a very bad design concept to parse URLs directly, so much people wouldn't like to use it ... Best Regards, Laszlo Papp

On 03/02/10 19:57, Florian Friesdorf wrote:

On Wed, Feb 03, 2010 at 07:55:10PM +0100, Laszlo Papp wrote:

...

On Wed, Feb 3, 2010 at 7:42 PM, Florian Friesdorf wrote:

...

On Wed, Feb 03, 2010 at 09:32:12PM +0300, Lex Rivera wrote:

...

On 03/02/10 19:10, Florian Friesdorf wrote:

...

What about a peer trust network? Publishing packages on the AUR would involve giving an pgp public key. People sign their PKGBUILDs using their private key. People can define trust relationships towards other people ("I trust this person to write good PKGBUILDs" and "I trust this person's trust in other's"). Being a TU would mean to be signed by the TU-Authority (or whatever) and trusting the TU authority's trust would mean you can install packages that are created by TU's.

Peer trust network? Isn't that too hard for ordinary user? Download key, import it, set trust level... If there will be some list of "Checked Users" this will be easier and friendlier. But peer trust net is nice idea anyway.

yaourt could ship with the TU-Auth's public key and it's default configuration could be to trust packages by people that are signed by the TU-Auth.

key management should further be integrated into yoaurt (or the like)

Yaourt is not supported officially, and it's buggy and abandoned program at this momment, and it has got a very bad design concept to parse URLs directly, so much people wouldn't like to use it ...

Well, what are people using to install packages from AUR?

-- Florian Friesdorf GPG FPR: EA5C F2B4 FBBB BA65 3DCD E8ED 82A1 6522 4A1F 4367 Jabber/XMPP: flo@chaoflow.net OTR FPR: 9E191746 213321FE C896B37D 24B118C0 31785700 IRC: chaoflow on freenode,ircnet,blafasel,OFTC Yaourt is popular, but there is other good alternatives to it. I like yaourt interface, but... It's extremely slow. And not developed anymore. Compare it to packer for example. Anyway, gpg support at least for binary packages can be great, but i haven't seen any pacman gpg patches or even preluminary support.