1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Dne 28.1.2011 23:42, Rich Freeman napsal(a): |
5 |
> 2011/1/28 Tomáš Chvátal <scarabeus@g.o>: |
6 |
>> So draft we would like to have implemented as Glep update is this diff: |
7 |
>> http://dev.gentoo.org/~scarabeus/glep-0048.diff |
8 |
>> |
9 |
>> Please comment and help us improve the "english" of the whole document |
10 |
>> so it gets accepted :) |
11 |
> |
12 |
> My only general comments are: |
13 |
|
14 |
Wow what a nice and long reply, thanks :) |
15 |
|
16 |
> |
17 |
> 1. It makes sense that in the event that a "Rogue" developer is |
18 |
> wreaking havoc on the tree that QA can get infra to suspend their |
19 |
> commit rights. That's safeguarding the tree in the face of imminent |
20 |
> harm. This should generally be limited to serious issues (people |
21 |
> running scripts to mass-update packages, bad changes to system |
22 |
> packages, etc), and not because there is some dispute over whether |
23 |
> some obscure package should or should-not be masked. |
24 |
> |
25 |
> 2. I don't think it makes sense for QA to discipline developers |
26 |
> permanently in these cases. They should suspend access pending Devrel |
27 |
> resolution of the issue. Devrel should of course strongly consider |
28 |
> the input of QA. |
29 |
> |
30 |
QA is not to discipline any developers. Everyone of us can cause |
31 |
breakage, heck even i killed profiles once :) |
32 |
Only case where we don't want Devrel interfere with QA decision at all |
33 |
is when someone Intentionaly breaks main tree. Seriously if someone |
34 |
really hit this issue i don't actually want him to apologize to another |
35 |
team and pretend like it never happened, i would prefer him long gone in |
36 |
a place far far away :) We really just want keep control over removing |
37 |
access for people that does breakage to main tree just for the breakage |
38 |
itself, aka it can't be excused in any way. |
39 |
""" |
40 |
Lets say you have this change for eclass which affects large part of the |
41 |
tree and on -dev ml people including QA members told you not to do so, |
42 |
yet you still proceed with the commit thus breaking part of the main |
43 |
tree in effect. |
44 |
In this situation normal accidental breakage or uneducated commit can't |
45 |
count in cause you were told of that it is not the way you should do it. |
46 |
So only way it can be described is deliberate act of main tree destruction. |
47 |
Since QA team is responsible for overall quality of main tree it is |
48 |
obvious we as team can't trust such person while he (or she) does not |
49 |
listen to us. So we would like to be the ones who decide that they |
50 |
should not be permitted to do direct commits to main tree. (they for |
51 |
sure can stay developers and write documentation and help in other areas |
52 |
they want to) |
53 |
""" |
54 |
|
55 |
> If Devrel is not adequately doing its job then this should be |
56 |
> escalated to the Devrel lead, or if necessary to the council (who can |
57 |
> step in if truly necessary). In the face of imminent harm QA can |
58 |
> always get a temporary ban on commits from infra. If this goes back |
59 |
> and forth (QA banning, Devrel unbanning) then I'm sure the council |
60 |
> will step in. |
61 |
> |
62 |
> So, in a nutshell here is how it works: |
63 |
> |
64 |
> 1. Developer starts messing something up (some crazy script is |
65 |
> committing junk to the tree, or dev is making some change to critical |
66 |
> package, or whatever). |
67 |
> 2. QA notices, or is told, or whatever. |
68 |
> 3. QA tries to ping dev - with severity of problem dictating how long |
69 |
> they should wait to resolve directly. |
70 |
> 4. QA determines that dev is unwilling to resolve a critical issue, |
71 |
> or cannot be reached and the matter can't wait. |
72 |
> 5. QA contacts infra, and infra suspends commit access to contain the damage. |
73 |
> 6a. QA initiates repairs (whatever this takes - they don't need to |
74 |
> personally do the work, etc). |
75 |
> 6b. QA logs complaint with DevRel. |
76 |
> 7. Devrel follows their process to resolve issue. Developer remains |
77 |
> banned until Devrel feels they can be unbanned, or dismissed. Devrel |
78 |
> takes input from QA. |
79 |
You actually pretty well described how we work when somebody breaks main |
80 |
tree without its primary intention to nuke it off. Which is still in |
81 |
effect with this update :) (everyone can make typo or forget to ask |
82 |
about something and accidentally do something disasterous :P) |
83 |
|
84 |
""" |
85 |
+* In case a particular developer persistently causes breakage, the QA |
86 |
+ lead may request commit rights of given developer to be suspended by |
87 |
+ the Infra team. Devrel should then proceed to evaluate the situation, by |
88 |
+ finding a compromise or permanently revoking those rights. |
89 |
""" |
90 |
> |
91 |
> If the issue here is that the Devrel and QA leads differ as to some |
92 |
> matter of policy or whatever, the council should be asked to resolve. |
93 |
> While the QA and Devrel teams may tend to self-govern, I don't think |
94 |
> the intent is that we end up having "three" Gentoos - the one ruled by |
95 |
> Devrel, the one ruled by QA, and the one ruled by the Council (not to |
96 |
> mention the Trustees). |
97 |
> |
98 |
> In practice I haven't really seen any situations where we're really |
99 |
> having problems over this, so I don't want to start a war over |
100 |
> something that isn't even a problem. |
101 |
> |
102 |
> In any case, the solution for developers is simple: |
103 |
> |
104 |
> 1. Don't do stupid stuff to the tree such that you tick EVERYBODY off. |
105 |
> 2. If you want to do something to the tree that you think is right |
106 |
> but which might tick a lot of people off (whether they are QA or not), |
107 |
> post notice of it in -dev first. |
108 |
> 3. If you and QA can't work it out before you do it, then work it out |
109 |
> with the council or something. |
110 |
> 4. Generally act like an adult. :) |
111 |
> |
112 |
> Ok, that was probably overly verbose. I don't see any issues with the |
113 |
> wording in the diff - this is more a matter of which is the right |
114 |
> policy. |
115 |
> |
116 |
> Finally, if Devrel, QA, and the Council have already talked this out |
117 |
> and agree that QA is in the best place to police technical commit |
118 |
> issues, then pipe this email to /dev/null... |
119 |
Yep QA is responsible for technical aspect of commits where Devrel |
120 |
handles the human side of it, so we usually give what we gather on named |
121 |
bad developer to Devrel to decide what to do with him. |
122 |
> |
123 |
> Rich |
124 |
> |
125 |
Tom |
126 |
-----BEGIN PGP SIGNATURE----- |
127 |
Version: GnuPG v2.0.17 (GNU/Linux) |
128 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
129 |
|
130 |
iEYEARECAAYFAk1DS0UACgkQHB6c3gNBRYcVFgCdHxzgXCepKzj0SY3oWCaKQpKR |
131 |
yDYAnj6Wg1Ew7Y8xtypkUXeoQ699/MNf |
132 |
=J775 |
133 |
-----END PGP SIGNATURE----- |