1 |
Hi Mark, |
2 |
|
3 |
Thanks for posting this. I've a few suggestions to make (see below). I |
4 |
support all the other points in your proposal. |
5 |
|
6 |
On Sun, 2006-02-26 at 17:22 -0500, Mark Loeser wrote: |
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 |
|
10 |
I'd like to see this say |
11 |
|
12 |
* In case of emergency, or after a failed appeal by the package |
13 |
maintainer to the council, the QA team may take action themselves |
14 |
to fix the problem, if the package maintainer(s) are unavailable |
15 |
or refuse to co-operate. |
16 |
|
17 |
That still gives the QA team the powers it needs for an enforcement |
18 |
role, which is all that it needs. |
19 |
|
20 |
> * In the event that a developer still insists that a package does not |
21 |
> break QA standards, an appeal can be made at the next council meeting. The |
22 |
> package should be dealt with per QA's request until such a time that a |
23 |
> decision is made by the council. |
24 |
|
25 |
I'd like to see an alternative wording: |
26 |
|
27 |
* In the event that a developer still insists that a package does not |
28 |
break QA standards, or that the QA standards are somehow defective, |
29 |
an appeal can be made at the next council meeting. |
30 |
|
31 |
If it is an emergency, then the QA team is still free to intervene |
32 |
before the council meeting. But, where it isn't an emergency, there is |
33 |
no need for immediate action, and so there should be no action until the |
34 |
appeal has been heard. |
35 |
|
36 |
The original wording is, imho, unfairly unbalanced. What will happen |
37 |
under the original wording is that the QA team is free to force their |
38 |
demands up front, and most developers will go with the flow rather than |
39 |
take the trouble to take the issue to the council. |
40 |
|
41 |
The QA team has no monopoly on what is right or wrong in Gentoo, and |
42 |
neither do package maintainers. If there is a disagreement that leads |
43 |
to an appeal, the onus should be on the QA team to have to present their |
44 |
case to the council, as they are the ones pushing for change. |
45 |
|
46 |
> * Just because a particular QA violation has yet to cause an issue does |
47 |
> not change the fact that it is still a QA violation. |
48 |
|
49 |
I'd support the above if the following statement was also included: |
50 |
|
51 |
* QA standards, and the actions required to resolve them, must be |
52 |
pragmatic and proportional to the impact on actual end-users of |
53 |
Gentoo. |
54 |
|
55 |
Gentoo would be best served by a QA team that spent its time tackling |
56 |
issues that are urgent and important to end-users (quadrant 1 & 2 |
57 |
activities). A QA team that gets bogged down in the thick of thin |
58 |
things is a symptom of a team that has become self-serving. |
59 |
|
60 |
> * The QA team will maintain a list of current "QA Standards". The list |
61 |
> is not meant by any means to be a comprehensive document, but rather a |
62 |
> dynamic document that will be updated as new problems are discovered. |
63 |
|
64 |
These QA standards are policy changes that affect the whole tree. The |
65 |
QA team does *not* own QA policy - we all do, as contributors to Gentoo. |
66 |
I'm asking the council to agree an adequate process for the approval of |
67 |
QA standards by a wider group than just the QA team. Maybe changes |
68 |
could be batched up into a GLEP, say once a quarter, with the option of |
69 |
fast-tracking GLEPs in between for emergency QA policy changes? This |
70 |
would allow the QA team to perform effectively, and have the added |
71 |
benefit of ensuring that the wider developer community knew what was |
72 |
coming in advance, and could "buy in" to the changes. |
73 |
|
74 |
There's a secondary issue here for me. None of our tools are perfect; |
75 |
we all have to work pragmatically within the capabilities of what we |
76 |
have. Some of the real QA issues in the tree arise from the limitations |
77 |
of our tools. I'd like to see the following incorporated into the QA |
78 |
team's mandate. |
79 |
|
80 |
* If the QA team wishes to push standards about specific aspects of |
81 |
our tools, then those standards must be endorsed by the leads of |
82 |
those tools. |
83 |
|
84 |
Why? Because the QA team has no monopoly on what is right and wrong |
85 |
with the tree. If any proposed QA standard cannot pass a simple litmus |
86 |
test of the endorsement of the leads of the tools, how can it be fit for |
87 |
enforcement against the wider development community? What is a package |
88 |
maintainer to do? He/she can't go back to the tools team in question |
89 |
and ask for a fix; all they will get is that the tools team in question |
90 |
doesn't agree with the QA team, and doesn't support that particular |
91 |
standard. Better to have QA standards that are strongly supported than |
92 |
to have QA standards supported by just the one team. |
93 |
|
94 |
I'd like to see the QA team's primary role stated as "educational" |
95 |
first, then watchdog, then intervener in that order (emergencies |
96 |
not-withstanding). |
97 |
|
98 |
With that in mind, I suggest that the QA standards must include |
99 |
educational information about the problem(s) that the standard |
100 |
addresses, before they can be approved. This is in no way to challenge |
101 |
the legitimacy of the agreed standards. It's to help all developers do |
102 |
better QA on their own work (everyone does a better job if they |
103 |
understand the reasons why). It also serves the dual purpose of helping |
104 |
the next generation of QA testers when the current team members have |
105 |
moved on. This could be Ciaran's opportunity to see TheDoc become an |
106 |
"offical" document. There are few things worse than standards |
107 |
autocratically and inflexibily applied long after the original |
108 |
supporters have left, and no-one else can remember why they were |
109 |
necessary in the first place. |
110 |
|
111 |
There *may* be arguments about how much effort it takes to produce this |
112 |
educational material, and I'm sympathetic to that. But for me, what it |
113 |
boils down to is this: QA is something that we all need to do. I'd |
114 |
rather have a QA team that's busy teaching the rest of us do things |
115 |
better than spending all its time cleaning up after a developer |
116 |
community that becomes more dazed and confused and left behind as time |
117 |
goes on. And it also scales much better :) |
118 |
|
119 |
This document does nothing to address the QA of anything other than the |
120 |
package tree. If the scope of the team is limited to just the package |
121 |
tree, then I'd like to see the team named appropriately - tree-qa |
122 |
perhaps - because they would be a general, all-ranging QA team. |
123 |
|
124 |
Best regards, |
125 |
Stu |
126 |
-- |
127 |
Stuart Herbert stuart@g.o |
128 |
Gentoo Developer http://www.gentoo.org/ |
129 |
http://blog.stuartherbert.com/ |
130 |
|
131 |
GnuGP key id# F9AFC57C available from http://pgp.mit.edu |
132 |
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C |
133 |
-- |