1 |
Tom Wijsman schrieb: |
2 |
> |
3 |
> [1]: https://wiki.gentoo.org/wiki/GLEP:48 |
4 |
> |
5 |
> "In the event that a developer still insists that a package does |
6 |
> not break QA standards, an appeal can be made at the next council |
7 |
> meeting. The package should be dealt with per QA's request until |
8 |
> such a time that a decision is made by the council." |
9 |
> |
10 |
|
11 |
|
12 |
Thanks for this pointer, i guess this makes the existing situation |
13 |
pretty clear: |
14 |
|
15 |
If QA does a commit and a dev does disagree, he can discuss it with QA |
16 |
or ask for council decision, but should never revert this QA change on |
17 |
his own. |
18 |
|
19 |
So if the dev then does ignore this rule, he does not follow our written |
20 |
rules (problem with the behaviour) and as a result this becomes a case |
21 |
for comrel. |
22 |
|
23 |
Now if comrel cannot convince the dev to accept the QA change (at least |
24 |
until council decision), it means comrel would have to take disciplinary |
25 |
action (e.g. commit access removal). |
26 |
|
27 |
|
28 |
|
29 |
With this in mind, i currently dont see any case where QA would need the |
30 |
ability to remove the commit access of a dev, so i dont see a need for |
31 |
this glep update. |
32 |
|
33 |
-- |
34 |
|
35 |
Thomas Sachau |
36 |
Gentoo Linux Developer |