1 |
On Thursday 02 March 2006 03:53, Mark Loeser wrote: |
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 |
6 |
> pointing out issues to maintainers and, where necessary, taking direct |
7 |
> action. |
8 |
> * In case of emergency, or if package maintainers refuse to |
9 |
> cooperate, the QA team may take action themselves to fix the problem. |
10 |
> * The QA team may also offer to fix obvious typos and similar minor |
11 |
> issues, and silence from the package maintainers can be taken as |
12 |
> agreement in such situations. |
13 |
> * In the event that a developer still insists that a package does not |
14 |
> break QA standards, an appeal can be made at the next council |
15 |
> meeting. The package should be dealt with per QA's request until such |
16 |
> a time that a decision is made by the council. |
17 |
> * In the case of disagreement on policy among QA members, the majority |
18 |
> of established QA members must agree with the action. |
19 |
> * Just because a particular QA violation has yet to cause an issue does |
20 |
> not change the fact that it is still a QA violation. |
21 |
> * If a particular developer persistently causes breakage, the QA team |
22 |
> may request that devrel re-evaluates that developer's commit rights. |
23 |
> Evidence of past breakages will be presented with this request to |
24 |
> devrel. |
25 |
> * The QA team will maintain a list of current "QA Standards" with |
26 |
> explanations as to why they are problems, and how to fix the problem. |
27 |
> The list is not meant by any means to be a comprehensive document, but |
28 |
> rather a dynamic document that will be updated as new problems are |
29 |
> discovered. The QA team will also do their best to ensure all |
30 |
> developer tools are in line with the current QA standards. |
31 |
> |
32 |
|
33 |
I'd like to add the following two points: |
34 |
* Just because breaking policy breaks a QA tool, but is guaranteed to |
35 |
never break itself (formatting policy, like space vs. tab etc.) does not |
36 |
increase the severity of the breakage. |
37 |
* Before any enforcement is possible, QA must establish a well supported |
38 |
(debated on dev-) exception policy. While it were nice if exceptions are |
39 |
not needed, reality is that they can not be avoided. Therefore there |
40 |
must be an exception policy. |
41 |
|
42 |
An exception does not mean there is no violation (so appeal is |
43 |
pointless). An exception means that the violation is needed because it |
44 |
offers important features for the user, and the benefits outweigh the |
45 |
costs. At the same time that an exception is allowed, steps should be |
46 |
undertaken to get a structural solution to the problem. QA is |
47 |
responsible for ensuring that the maintainer(s) of the package in |
48 |
question keep on doing so. |
49 |
|
50 |
Paul |
51 |
|
52 |
-- |
53 |
Paul de Vrieze |
54 |
Gentoo Developer |
55 |
Mail: pauldv@g.o |
56 |
Homepage: http://www.devrieze.net |