[aur-general] TU without [community] maintaining?
Hi all. I wanna ask is it possible to become TU without [community] maintaining, just as AUR moderator?
On Wed, Feb 3, 2010 at 09:32, Lex Rivera <x-demon@x-demon.org> wrote:
Hi all. I wanna ask is it possible to become TU without [community] maintaining, just as AUR moderator?
That's not currently possible.
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.
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. -- Chris
On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon <cmbrannon79@gmail.com> 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 03, 2010 at 12:31:37PM -0300, Angel Velásquez wrote:
On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon <cmbrannon79@gmail.com> 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. -- Florian Friesdorf <flo@chaoflow.net> 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 3, 2010 at 12:37 PM, Florian Friesdorf <flo@chaoflow.net> 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 <cmbrannon79@gmail.com> 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 <flo@chaoflow.net> 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
On Wed, Feb 03, 2010 at 12:44:19PM -0300, Angel Velásquez wrote:
On Wed, Feb 3, 2010 at 12:37 PM, Florian Friesdorf <flo@chaoflow.net> wrote:
On Wed, Feb 03, 2010 at 12:31:37PM -0300, Angel Velásquez wrote:
Thomas Bächler wrote: 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
On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon <cmbrannon79@gmail.com> wrote: 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!;
;) still - I don't see the advantages of too restrictive rules. Let's start answering the questions - her my suggestions:
Well, other question how will be the process of selection of these semi-tu?
- (self-)proposal on this list with short personal description. - 10 people in favour: et voila - one opposing: AUR-TUs vote about it - less than ten AUR-TUs: TU's vote along the AUR-TUs
how will be called the group semi-tu ? trusted but not at all?
AUR-TUs - trusted user of the AUR
there are many many questions until we can make this idea possible. Just that.
Let's get going :) -- Florian Friesdorf <flo@chaoflow.net> 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
Am 03.02.2010 16:44, schrieb Angel Velásquez:
On Wed, Feb 3, 2010 at 12:37 PM, Florian Friesdorf <flo@chaoflow.net> 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 Wed, Feb 03, 2010 at 07:57:21PM +0100, Thomas Bächler wrote:
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.
Following the reasoning elsewhere in this threa, that: a) TUs do a great job b) some TUs don't want to do cleanup work in the AUR c) Lex does want to do cleanup work in the AUR d) Lex does not want to take care of things in [community] and KISS: Why not make Lex a TU who puts the focus on the AUR? Just because you can write in [community] does not mean you have to. Is an application of Lex for TU sane on that base? -- Florian Friesdorf <flo@chaoflow.net> 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 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 <flo@chaoflow.net> 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.
Am 03.02.2010 20:05, schrieb Lex Rivera:
Lex/Alex/Alexander.
Ah, "he" then :)
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.
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.
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
2010/2/3 Angel Velásquez <angvp@archlinux.com.ve>:
On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon <cmbrannon79@gmail.com> 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 ...
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 ? Best Regards, Laszlo Papp
On Wed, Feb 3, 2010 at 12:53 PM, Laszlo Papp <djszapi@archlinux.us> wrote:
2010/2/3 Angel Velásquez <angvp@archlinux.com.ve>:
On Wed, Feb 3, 2010 at 12:22 PM, Chris Brannon <cmbrannon79@gmail.com> 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
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 <cmbrannon79@gmail.com> 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 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 <cmbrannon79@gmail.com> 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 03, 2010 at 07:55:36PM +0200, Lauri Niskanen wrote:
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.
+1 -- Florian Friesdorf <flo@chaoflow.net> 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 3, 2010 at 12:55, Lauri Niskanen <ape@ape3000.com> 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 Wed, Feb 03, 2010 at 12:58:40PM -0500, Daenyth Blank wrote:
On Wed, Feb 3, 2010 at 12:55, Lauri Niskanen <ape@ape3000.com> 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 <flo@chaoflow.net> 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 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 <ape@ape3000.com> 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 <flo@chaoflow.net> 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 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 <ape@ape3000.com> 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.
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 <ape@ape3000.com> 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 <flo@chaoflow.net> 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
I think it's wrong way. Some of packages just install old versions, they can be adopted by users and updated easily. Take a look at helium, for example. Fully working pkgbuild, only pkgver needs to be changed to get it up-to-date. Firstly we must take care about really obsolette packages. For example - sim-im. SVN snapshop, even when we have normal SVN pkgbuild and normal stable pkgbuild. So sim-im must be removed. And so on. When we finish cleaning up obsoletes, we can start cleaning up orphans. Here is my vision how this must work: 1. There is addittional button on pkgbuild's page - Report obsolete. 2. If user clicks this button, notify will be sent, for example, to aur-mods maillist 3. Mod will remove this packages 4. Package must be moved to some sort of archive - there will always be human mistakes. That archive can be cleaned, for example, every month. Or not cleaned at all - pkgbuilds are pretty small :) 5. When user try to create new PKGBUILD with pkgname = name of previously removed pkgbuild, maybe we must print some notice and link to old pkgbuild. Old projects can be revived sometimes. On 03/02/10 19:55, Lauri Niskanen wrote:
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 <cmbrannon79@gmail.com> 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 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.)
- check submitted/changed PKGBUILDs (no special rights needed) - orphan/remove packages (IMO done quickly by TU's) - manage AUR accounts (same as above ...) - ?
+1 ! I can think of one more thing, to develop AUR, but it can be done without this right too. Best Regards, Laszlo Papp
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
Le Wed, 03 Feb 2010 15:41:38 +0100, Thomas Bächler <thomas@archlinux.org> 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. -- catwell
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 <thomas@archlinux.org> 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 <flo@chaoflow.net> 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 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 <thomas@archlinux.org> 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 <flo@chaoflow.net> 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.
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 <thomas@archlinux.org> 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 <flo@chaoflow.net> 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>
Am Wed, 03 Feb 2010 20:41:34 +0200 schrieb Lauri Niskanen <ape@ape3000.com>:
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. I disagree that AUR needs additional moderators. That's what among others TUs are for, this is why they are called TUs, and they are doing this job really good. If you post something (deletion request, orphaning request etc.) to this mailing list it's usually done within a few minutes. Greetings, Heiko
Le Wed, 3 Feb 2010 19:55:55 +0100, Heiko Baums <lists@baums-on-web.de> a écrit :
Am Wed, 03 Feb 2010 20:41:34 +0200 schrieb Lauri Niskanen <ape@ape3000.com>:
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 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) -- Florian Friesdorf <flo@chaoflow.net> 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 3, 2010 at 7:42 PM, Florian Friesdorf <flo@chaoflow.net> 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 Wed, Feb 03, 2010 at 07:55:10PM +0100, Laszlo Papp wrote:
On Wed, Feb 3, 2010 at 7:42 PM, Florian Friesdorf <flo@chaoflow.net> 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 <flo@chaoflow.net> 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 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 <flo@chaoflow.net> 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 <flo@chaoflow.net> 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.
Le Wed, 3 Feb 2010 19:55:10 +0100, Laszlo Papp <djszapi@archlinux.us> a écrit :
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 ...
Yaourt is not abandonned, and he did say "and the like", which includes Bauerbill, Pakthan... Bauerbill already implements a way to trust users but the names of the users that can be trusted have to be configured manually. I used to dislike those wrappers very strongly when they didn't allow their user to verify PKGBUILDs. Now they all do, and that's their default behavior. I still don't use them because they wouldn't save me much time, the most time-consuming part of the installation of AUR packages being to check the PKGBUILDs. I might switch to bauerbill though, because although what it does is not enough, at least it allows me to trust selected users. -- catwell
On Wed, Feb 3, 2010 at 3:32 PM, Lex Rivera <x-demon@x-demon.org> wrote:
Hi all. I wanna ask is it possible to become TU without [community] maintaining, just as AUR moderator?
What's the problem with the current TU jobs/members ? I think they do their work pretty well, they react for the requests quickly enough on this mailing list! What tasks are there that can't be done by current TUs ? The first sentence from here: http://wiki.archlinux.org/index.php/AUR_Trusted_User_Guidelines "The Trusted User (TU) is a member of the community charged with keeping the AUR in working order." I think this is the task of every TUs, so ... Otherwise you can send codes, patches, feature implementations to Louipc, I didn't have any problem with it earlier, he applied them quickly ... Best Regards, Laszlo Papp
participants (14)
-
Allan McRae
-
Angel Velásquez
-
Chris Brannon
-
Daenyth Blank
-
Florian Friesdorf
-
Heiko Baums
-
Jaroslav Lichtblau
-
Laszlo Papp
-
Lauri Niskanen
-
Lex Rivera
-
Loui Chang
-
Pierre Chapuis
-
Ray Rashif
-
Thomas Bächler