1 |
On Tue, 21 Jan 2014 22:03:22 +0100 |
2 |
Thomas Sachau <tommy@g.o> wrote: |
3 |
|
4 |
> With this in mind, i currently dont see any case where QA would need |
5 |
> the ability to remove the commit access of a dev, so i dont see a |
6 |
> need for this glep update. |
7 |
|
8 |
The case you have enumerated is just one possible case, this is a case |
9 |
where policy is in place; it is however not always the case that there |
10 |
is policy, or perhaps even that policy is unclear. In these other cases |
11 |
the QA team has to take an actual decision instead of "it is policy"; in |
12 |
such cases, the reasoning behind this becomes technical and you get the |
13 |
whole idea we have been discussing here. |
14 |
|
15 |
Besides that, you also have the possibility for bigger breakages to |
16 |
happen; regardless of whether or not they are written down in policy. |
17 |
|
18 |
In some of these cases the roles of QA and ComRel become questionable; |
19 |
cfr. the whole discussion on #gentoo-qa, where I also asked the reverse |
20 |
question as to why QA has the power to suspend people in a technical |
21 |
area like the Portage tree when it is not part of their terrains. |
22 |
|
23 |
And just to make it clear one more time; it is the ability to |
24 |
"temporarily" "suspend" the commit access, as a means to get the |
25 |
developer to contact us where the developer was otherwise unavailable |
26 |
or intended to not communicate or listen to us. It is no way an actual |
27 |
removal or permanent decision; or well, it might be if this is about |
28 |
repeated behavior, but that's a whole different story... |
29 |
|
30 |
-- |
31 |
With kind regards, |
32 |
|
33 |
Tom Wijsman (TomWij) |
34 |
Gentoo Developer |
35 |
|
36 |
E-mail address : TomWij@g.o |
37 |
GPG Public Key : 6D34E57D |
38 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D |