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