On Mon, Sep 04, 2006 at 02:59:43PM -0400, Alec Warner wrote: > Bryan Ãstergaard wrote: > > If people are randomly given bugzie privs (or any other privs) this is > > something we need to fix. And just to make this clear to all - handing > > out privs is only half the equation and it's already hard enough for > > recruiters to keep track of devs even though we have well defined > > procedures etc. for that. > > Then you better get to patching bugs, since I can hand out gentoo-dev > and portage-dev privs on bugs without any problem (I tried it on > ferringb to check even; and i took them away right after). > This is being fixed now. Gentoo-dev gives access to (some) restricted bugs but doesn't give editbugs privs and portage-dev was somebody hitting a wrong checkbox. Likely a long time ago but a simple mistake never the less and not something that should be considered normal.
> >> B. Double bonus is that I don't even see why a GLEP is required? This > >> is a small subset of users using one resource (bugzilla) so perhaps > >> Infra and devrel and you can work out the requisite groups? Why is > >> there all this red tape? > > Because it's going to affect all devs if people don't need to pass > > quizzes (or we lower the threshhold substantially) before they can > > reassign, close, reopen etc. the maintainers bugs. > > And in this case I'm saying a subset. I'll use Java as an example. > Caster is like an awesome Java dude. Lets say I want to give him access > to bugs assigned to [EMAIL PROTECTED] Either I (as a member of that > herd/project) already have bugs perms to java bugs, or the group doesn't > exist and I need to ask JForman to make a java-bugs group and make it so > they can do stuff to bugs assigned to [EMAIL PROTECTED] If I'm already in the > group I can just delegate the java perms to Caster and be done. > > Aside from the java bugs, no one else is affected. No other permissions > on bugs are granted. The user can only mess with java bugs. > This is going to be a maintainence nightmare for several reasons. 1. Very few people can create new bugzilla groups and they'd have to take time out to do that instead of (what I'd consider) more important bugzilla maintainence. 2. You can't delete groups easily (probably can't delete groups at all) as lots of bugzilla data might be related to these groups. End result would be an enormous amounts of groups in a relatively short time if we were to micromanage privs that way. 3. Who's going to clean up all these privs when people turn inactive? Recruiters are already overloaded as is and certainly don't need the extra management burden from this. I'd much rather spend time recruiting new devs and making sure we do a good job at that than trying to keep bugzilla privs somewhat clean. > >> Create a group; come up with a subset of bugs that they can access, add > >> user to group -> done. As long as they can't access my bugs; I really > >> shouldn't (and trust me I don't) care. > > Who's going to admin that? We already have the Arch Tester / Herd Tester > > projects that defines a proper way of achieving the goal as I see it. > > > > Only problem with Herd Testers / Arch Testers compared to genstefs goal > > is that HTs/ATs deal with packages in the tree while sunrise > > contributors deal with packages outside the tree. > > > > And personally I'd very much like to draw the line somewhere. Genstef > > made the GLEP extremely vague regarding contributors (on purpose) but > > guess what? Everybody who files a new bug, submits a fixed ebuild etc. > > are contributors. So should we just remove all the restrictions now? > > This is definitely something we need to define before moving on, no > > matter if the GLEP is eventually denied or accepted. > > I liked my definition in my earlier mail ;) Generally contributing > requires you know someone rather well, such that they proxy your changes > into the tree. That's not adequate imo. Lots of people seem genuinely interested in helping only to disappear a few days/weeks later. Part of what the ebuild quiz does is that it tries to make sure people are going to stick around for a while. It doesn't always succeed and neither does recruiters but I still think it's important that he have some defined bar (level?) that you need to pass. > > >> C. No real standard on any other fora. I don't need a GLEP to add > >> someone to my project overlay, or grant them voice or ops in my > >> project's IRC channel. I don't need a GLEP to get them subscribed to my > >> mailing list and I don't need a GLEP to add them to (most) project > >> aliases. Why does this require one? > > Because this is about the entire Gentoo project and affects us all in a > > very direct way as opposed to random projects. > > I tried to make it clear above that it doesn't. I hope I succeeded. I still very much believe this affects all of gentoo, especially seen in light of the problems micromanaging bugzie privs would imply. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
