1 |
On Sunday 26 February 2006 18:34, Mark Loeser wrote: |
2 |
> Stuart Herbert <stuart@g.o> said: |
3 |
> > On Sun, 2006-02-26 at 17:22 -0500, Mark Loeser wrote: |
4 |
> > > * In case of emergency, or if package maintainers refuse to cooperate, |
5 |
> > > the QA team may take action themselves to fix the problem. |
6 |
> > |
7 |
> > I'd like to see this say |
8 |
> > |
9 |
> > * In case of emergency, or after a failed appeal by the package |
10 |
> > maintainer to the council, the QA team may take action themselves |
11 |
> > to fix the problem, if the package maintainer(s) are unavailable |
12 |
> > or refuse to co-operate. |
13 |
> > |
14 |
> > That still gives the QA team the powers it needs for an enforcement |
15 |
> > role, which is all that it needs. |
16 |
> |
17 |
> Your change seems to imply that the QA team must wait for the council's |
18 |
> okay to go forth and fix the package, rather the QA team able to act on |
19 |
> its own. If that is the case, I don't see how we would ever be able to |
20 |
> get things done when someone disagrees with us. |
21 |
|
22 |
give the QA team the power to fix things, likely they act on something being |
23 |
broken rather than impose style changes, i do not think we want to start |
24 |
discussions and appeals while broken packages remain broken |
25 |
|
26 |
> |
27 |
> > > * In the event that a developer still insists that a package does not |
28 |
> > > break QA standards, an appeal can be made at the next council |
29 |
> > > meeting. The package should be dealt with per QA's request until such a |
30 |
> > > time that a decision is made by the council. |
31 |
> > |
32 |
> > I'd like to see an alternative wording: |
33 |
> > |
34 |
> > * In the event that a developer still insists that a package does not |
35 |
> > break QA standards, or that the QA standards are somehow defective, |
36 |
> > an appeal can be made at the next council meeting. |
37 |
> > |
38 |
> > If it is an emergency, then the QA team is still free to intervene |
39 |
> > before the council meeting. But, where it isn't an emergency, there is |
40 |
> > no need for immediate action, and so there should be no action until the |
41 |
> > appeal has been heard. |
42 |
> |
43 |
> Again, then we are going to get into the argument of the definition of |
44 |
> an emergency and never be able to get anything done. We really hope |
45 |
> problems never come down to this, which is why we left it worded this |
46 |
> way. |
47 |
|
48 |
again, give the QA team the benefit of the doubt, if they are willing to fix |
49 |
it before the maintainer, gentoo only has to gain, while hopefully everyone |
50 |
learns what not to repeat in the future |
51 |
> |
52 |
> > The QA team has no monopoly on what is right or wrong in Gentoo, and |
53 |
> > neither do package maintainers. If there is a disagreement that leads |
54 |
> > to an appeal, the onus should be on the QA team to have to present their |
55 |
> > case to the council, as they are the ones pushing for change. |
56 |
> |
57 |
> Again, this is taking away any power that the QA team might have, and |
58 |
> gets us stuck in the current situation where we can't do anything when |
59 |
> someone disagrees with us. We are hoping that most people are not going |
60 |
> to see us as idiots running around trying to change everything just because |
61 |
> we don't like it. It is expected that people will trust us to some degree, |
62 |
> and we are giving a way for people to challenge our decisions if they |
63 |
> believe we are wrong. |
64 |
|
65 |
again, the QA team should have final say, and their decision should only be |
66 |
appealable after the fact, not stallable with appeals before the fact |
67 |
leave the tree as is (unbroken/unfixed) until the council could review any |
68 |
appeal |
69 |
|
70 |
> |
71 |
> > > * Just because a particular QA violation has yet to cause an issue does |
72 |
> > > not change the fact that it is still a QA violation. |
73 |
> > |
74 |
> > I'd support the above if the following statement was also included: |
75 |
> > |
76 |
> > * QA standards, and the actions required to resolve them, must be |
77 |
> > pragmatic and proportional to the impact on actual end-users of |
78 |
> > Gentoo. |
79 |
> > |
80 |
> > Gentoo would be best served by a QA team that spent its time tackling |
81 |
> > issues that are urgent and important to end-users (quadrant 1 & 2 |
82 |
> > activities). A QA team that gets bogged down in the thick of thin |
83 |
> > things is a symptom of a team that has become self-serving. |
84 |
> |
85 |
> This is not quantifiable at all and will just get us into arguments with |
86 |
> people that disagree with us that there is a problem present. |
87 |
> |
88 |
> > > * The QA team will maintain a list of current "QA Standards". The list |
89 |
> > > is not meant by any means to be a comprehensive document, but rather |
90 |
> > > a dynamic document that will be updated as new problems are discovered. |
91 |
> > |
92 |
> > These QA standards are policy changes that affect the whole tree. The |
93 |
> > QA team does *not* own QA policy - we all do, as contributors to Gentoo. |
94 |
> > I'm asking the council to agree an adequate process for the approval of |
95 |
> > QA standards by a wider group than just the QA team. Maybe changes |
96 |
> > could be batched up into a GLEP, say once a quarter, with the option of |
97 |
> > fast-tracking GLEPs in between for emergency QA policy changes? This |
98 |
> > would allow the QA team to perform effectively, and have the added |
99 |
> > benefit of ensuring that the wider developer community knew what was |
100 |
> > coming in advance, and could "buy in" to the changes. |
101 |
> |
102 |
> Again, this bogs us down in useless process if someone wants to argue a |
103 |
> change that clearly breaks things, but isn't documented. It is |
104 |
> impossible to document every single thing that is a problem, and we are |
105 |
> asking for some freedom to be able to work on issues that fall under QA. |
106 |
|
107 |
the list of documented "Don't"s should be an open list, not an ultimate and |
108 |
final list, just because i mess up in a way noone ever thought of documenting |
109 |
before, should not give me the chance to be ignorant to the fact that i |
110 |
indeed broke a package/the tree |
111 |
|
112 |
> |
113 |
> > There's a secondary issue here for me. None of our tools are perfect; |
114 |
> > we all have to work pragmatically within the capabilities of what we |
115 |
> > have. Some of the real QA issues in the tree arise from the limitations |
116 |
> > of our tools. I'd like to see the following incorporated into the QA |
117 |
> > team's mandate. |
118 |
> > |
119 |
> > * If the QA team wishes to push standards about specific aspects of |
120 |
> > our tools, then those standards must be endorsed by the leads of |
121 |
> > those tools. |
122 |
> |
123 |
> So the Portage team will have to agree with us on every single problem |
124 |
> that is a QA issue? This seems like something we can leave alone until |
125 |
> it doesn't work, at which point we bring it before the council to figure |
126 |
> out how we can best handle this situation. Saying that another team |
127 |
> must approve all QA checks just seems silly. |
128 |
> |
129 |
> > Why? Because the QA team has no monopoly on what is right and wrong |
130 |
> > with the tree. If any proposed QA standard cannot pass a simple litmus |
131 |
> > test of the endorsement of the leads of the tools, how can it be fit for |
132 |
> > enforcement against the wider development community? What is a package |
133 |
> > maintainer to do? He/she can't go back to the tools team in question |
134 |
> > and ask for a fix; all they will get is that the tools team in question |
135 |
> > doesn't agree with the QA team, and doesn't support that particular |
136 |
> > standard. Better to have QA standards that are strongly supported than |
137 |
> > to have QA standards supported by just the one team. |
138 |
> |
139 |
> All of this seems to assume that the QA team is going to abuse its |
140 |
> power. So far we have had very few problems when we ask people to |
141 |
> fix issues that we have found for their packages. Is this going to |
142 |
> always be true? No, and someone needs to be able to get problems fixed |
143 |
> instead of just leaving things the way they are, and we want to fill |
144 |
> that role. |
145 |
|
146 |
agreed, most objections seem to aim at preventing abuse of power rather than |
147 |
commenting on how a QA team can work reliably |
148 |
|
149 |
> |
150 |
> > I'd like to see the QA team's primary role stated as "educational" |
151 |
> > first, then watchdog, then intervener in that order (emergencies |
152 |
> > not-withstanding). |
153 |
> |
154 |
> Which is what we plan on doing, and have been doing so far. |
155 |
|
156 |
just make sure the QA team can't be paralyzed with stubborn devs filing appeal |
157 |
after appeal, give them the power to act too, not just |
158 |
educate/watch/intervene in security issues |
159 |
|
160 |
> |
161 |
> > With that in mind, I suggest that the QA standards must include |
162 |
> > educational information about the problem(s) that the standard |
163 |
> > addresses, before they can be approved. This is in no way to challenge |
164 |
> > the legitimacy of the agreed standards. It's to help all developers do |
165 |
> > better QA on their own work (everyone does a better job if they |
166 |
> > understand the reasons why). It also serves the dual purpose of helping |
167 |
> > the next generation of QA testers when the current team members have |
168 |
> > moved on. This could be Ciaran's opportunity to see TheDoc become an |
169 |
> > "offical" document. |
170 |
> |
171 |
> We are working on a document, and hope to document all of the problems |
172 |
> and why they are problems. We don't plan on saying something is just |
173 |
> wrong and not give an explanation. |
174 |
|
175 |
all in all gentoo can only gain from an active, able to act QA team |