1 |
Mark Loeser <halcy0n@g.o> said: |
2 |
> Here is my updated version after some feedback from people: |
3 |
> |
4 |
> * The QA team's purpose is to provide cross-team assistance in keeping |
5 |
> the tree in a good state. This is done primarily by finding and pointing |
6 |
> out issues to maintainers and, where necessary, taking direct action. |
7 |
> * In case of emergency, or if package maintainers refuse to cooperate, |
8 |
> the QA team may take action themselves to fix the problem. |
9 |
> * The QA team may also offer to fix obvious typos and similar minor |
10 |
> issues, and silence from the package maintainers can be taken as agreement in |
11 |
> such situations. |
12 |
> * In the event that a developer still insists that a package does not |
13 |
> break QA standards, an appeal can be made at the next council meeting. The |
14 |
> package should be dealt with per QA's request until such a time that a |
15 |
> decision is made by the council. |
16 |
> * In the case of disagreement on policy among QA members, the majority |
17 |
> of established QA members must agree with the action. |
18 |
> * Just because a particular QA violation has yet to cause an issue does |
19 |
> not change the fact that it is still a QA violation. |
20 |
> * If a particular developer persistently causes breakage, the QA team |
21 |
> may request that devrel re-evaluates that developer's commit rights. |
22 |
> Evidence of past breakages will be presented with this request to |
23 |
> devrel. |
24 |
> * The QA team will maintain a list of current "QA Standards" with |
25 |
> explanations as to why they are problems, and how to fix the problem. The |
26 |
> list is not meant by any means to be a comprehensive document, but rather a |
27 |
> dynamic document that will be updated as new problems are discovered. The QA |
28 |
> team will also do their best to ensure all developer tools are in line with |
29 |
> the current QA standards. |
30 |
|
31 |
I'm happy enough to send the above to the Council. I think the only issue |
32 |
will be with bullet point 4. I know that the QA team as a whole like the |
33 |
wording this way leaving the onus on the package maintainer to prove the |
34 |
merrits of their package rather then having the onus on the QA team to |
35 |
prove fault. Personally I also like the wording this way (in most cases). |
36 |
|
37 |
In the cases where a clear technical solution presents itself to the |
38 |
problems the package presents that does not change the intended behavior |
39 |
(unless said behavior is what is broken) and the maintainer still |
40 |
refuses to apply the neceesary changes I think that the QA team should |
41 |
be cleared to make them. This is all under the understanding that the |
42 |
maintainer has the right to appeal in order to revert said changes. |
43 |
|
44 |
The tougher call comes when the severity of a QA violation comes into |
45 |
question. If the QA team presents a problem to a maintainer that they |
46 |
believe is severe enough to warrant a package's removal and no technical |
47 |
solution has presented itself to either the QA team or the maintainer to |
48 |
work around the issue I think that the QA team should have the right to |
49 |
hard mask the package pending an appeal. In such cases I'd almost say |
50 |
that an appeal should be automatically triggered so that a decision |
51 |
about the true severity of the QA issue can be ironed out. I certainly |
52 |
hope that there will be few enough of these that the council will not end |
53 |
up bogged down in policy decisions and QA conflict mediation. |
54 |
|
55 |
The above also has to be done on a case by case basis, if hardmasking a |
56 |
package would cause wide tree breakage itself then another choice has to |
57 |
be made. |
58 |
|
59 |
Concurrent with the above what I'd like to see is the QA team showing a |
60 |
willingness to help maintainers find workarounds to particualarly sticky |
61 |
violations. I'm not saying that they should have to learn the packages |
62 |
inside out or that they should not be allowed to act until a solution is |
63 |
found just that they should put a certain level of effort into helping |
64 |
find (or concoct) a solution. This is not to say that they are not doing |
65 |
this now, however, as has been said in the prior incarnation of this |
66 |
thread I also believe that the stickier problems are likely to arise |
67 |
because the maintainer in question did not see a better solution, so |
68 |
part of QA's roll should be to help educate the developer community. |
69 |
|
70 |
All in all the one thing I'd like to aviod is QA bugs getting closed as |
71 |
invalid (one of the events that lead up to this thread). I know there |
72 |
is a sense of territory with the ebuilds one maintains, but I'd really |
73 |
like to see an effort made to allow the QA team to explain themselves. |
74 |
If a bug gets opened up on one of your pacakges and it is unclear to you |
75 |
why something is a QA issue either comment on the bug asking th QA team |
76 |
to explain (and I consider pointing someone to existing offial documentation |
77 |
so long as it contains an explanation of what is wrong and how to |
78 |
generally fix such issues to be a valid explanation) or ping them |
79 |
online. |
80 |
|
81 |
I really hope that noone thinks the QA team is out to get them. They are |
82 |
here to make the experiance better for all of us as a whole (even if |
83 |
that sometimes means that the experiance for a particular package or two |
84 |
needs to be a little worse). Tree QA is something that we have never had |
85 |
before, at least not really (don't mean to trivialize the work that |
86 |
Mr_Bones_ does). It is something that I believe we need so lets all help |
87 |
with the transition instead of fighting it. |
88 |
|
89 |
Thanks, |
90 |
|
91 |
-- |
92 |
Daniel Ostrow |
93 |
Gentoo Foundation Board of Trustees |
94 |
Gentoo/{PPC,PPC64,DevRel} |
95 |
dostrow@g.o |