1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Mark Loeser wrote: |
5 |
> Daniel Goller <morfic@g.o> said: |
6 |
>> Mark Loeser wrote: |
7 |
>>> Here is the newest revision of my proposal. Not much has changed, but I |
8 |
>>> added and changed some small things. Constructive feedback is |
9 |
>>> appreciated. I'd like to get this voted on by the council at the next |
10 |
>>> meeting. |
11 |
>>> |
12 |
>>> * The QA team's purpose is to provide cross-team assistance in keeping |
13 |
>>> the tree in a good state. This is done primarily by finding and pointing |
14 |
>>> out issues to maintainers and, where necessary, taking direct action. |
15 |
>> describe what makes it necessary and what actions will be taken |
16 |
>> or if the paragraphs below are meant to do that, you can save that line |
17 |
>> in that paragraph |
18 |
> |
19 |
> What makes it necessary is if something is broken or goes against |
20 |
> policy, and the actions are listed below. I was pretty sure this went |
21 |
> without saying. |
22 |
|
23 |
is what you are saying that the line is superfluous since it is covered |
24 |
by the paragraph below ? |
25 |
|
26 |
> |
27 |
>>> * In case of emergency, or if package maintainers refuse to cooperate, |
28 |
>>> the QA team may take action themselves to fix the problem. The QA |
29 |
>>> team does not want to override the maintainer's wishes by default, but only |
30 |
>>> wish to do so when the team finds it is in the best interest of users |
31 |
>>> and fellow developers to have the issue addressed as soon as possible. |
32 |
>> define emergency, define as soon as possible (some bugs might be quite |
33 |
>> tricky to track and might be put on back burner and what little time is |
34 |
>> available used on things not taking up equal times), how do you know ia |
35 |
>> dev is not cooperating or if i he/she is just prioritizing |
36 |
> |
37 |
> emergency - something that is broken and affects a great number of users |
38 |
|
39 |
you could elaborate on "broken" some more, since you seem to have |
40 |
skipped over my addendum to my email and the terms 'broken' and |
41 |
'breakage' are used as if they define themselves |
42 |
|
43 |
> as soon as possible - exactly what it says, as soon as possible |
44 |
|
45 |
|
46 |
> |
47 |
> Basically, use common sense here please :) |
48 |
|
49 |
common sense ain't that common, to think any two people consider the |
50 |
same thing as common sense is an assumption, and those are not that good |
51 |
|
52 |
> |
53 |
>>> * In the case of disagreement on policy among QA members, the majority |
54 |
>>> of established QA members must agree with the action. |
55 |
>> you shouldn't disagree about this policy, or you might as well not have |
56 |
>> this document, write disagree on the solution maybe? |
57 |
> |
58 |
> It was not referring to *this* policy, but the exact policy that is |
59 |
> dealing with the problem at hand. In this context, it was meant to be |
60 |
> read that what some of us to believe is a problem is actually a problem |
61 |
> here, and that the solution is reasonable. I will write the whole thing |
62 |
> out to improve clarity. |
63 |
> |
64 |
ok, so we refer to points of this policy as policies. do not leave |
65 |
wiggle room, either it is a problem or not. discuss the solutions? yes |
66 |
of course. |
67 |
|
68 |
>>> * Just because a particular QA violation has yet to cause an issue does |
69 |
>>> not change the fact that it is still a QA violation. |
70 |
>> Then you must be talking about coding style here? remove the point and |
71 |
>> add it above to coding style, as an example why you will deal with the |
72 |
>> coding style maybe? no other violation should be left to such vagueness |
73 |
> |
74 |
> No, I'm talking about problems that were not noticed before and we just |
75 |
> realized the implications of what we are doing. |
76 |
> |
77 |
|
78 |
this can then be struck or combined to the point where you say the list |
79 |
is not finite, i really wish you would say it is comprehensive yet not |
80 |
finite, like list everything as a reference, so people can look at it if |
81 |
they go "oh i think i can do it this way!" then they read the list and |
82 |
find it in the minor/major/critical section of the comprehensive yet not |
83 |
finite document. |
84 |
comprehensive does not mean finite, so i would like to understand why |
85 |
you refuse to make it a comprehensive list and call it that |
86 |
|
87 |
>>> * If a particular developer persistently causes breakage, the QA team |
88 |
>>> may request that devrel re-evaluates that developer's commit rights. |
89 |
>>> Evidence of past breakages will be presented with this request to |
90 |
>>> devrel. |
91 |
|
92 |
>> define persistently, how do you presistently cause breakage? maybe this |
93 |
>> is one of those non native english speaker moments, but doesn't that |
94 |
>> mean like every commit is botched? |
95 |
> |
96 |
> Not every commit, but a recognizable pattern can be seen. |
97 |
> |
98 |
|
99 |
let's say someone consistently brings us good on the toolchain, but in |
100 |
the process we get a few hiccups, is that such a pattern that would get |
101 |
him to meet devrel? (considering it is him who does all the work and the |
102 |
fixing "as soon as possible" anyway) |
103 |
|
104 |
are (picking a number) 10 wrong digests the same as 10 instances where |
105 |
glibc/gcc wouldn't build, or did build but caused a broken system? |
106 |
|
107 |
>>> * The QA team will maintain a list of current "QA Standards" with |
108 |
>>> explanations as to why they are problems, and how to fix the problem. |
109 |
>>> The list is not meant by any means to be a comprehensive document, but |
110 |
>>> rather a dynamic document that will be updated as new problems are |
111 |
>>> discovered. The QA team will also do their best to ensure all developer |
112 |
>>> tools are in line with the current QA standards. |
113 |
>> as said in the other two posts, maybe write it is a comprehensive list, |
114 |
>> just that it is not finite? that might clear this point up. |
115 |
> |
116 |
> The wording as it currently stands is what I mean for it to say. Our |
117 |
> document should never be considered to cover *every* single thing you |
118 |
> can do wrong. It also covers that the document is never complete, and |
119 |
> that we are always working on improving it. |
120 |
> |
121 |
|
122 |
see above how this list could be utilized, so it should list it all, |
123 |
really, avoids people going "well, it wasn't listed, repoman didn't |
124 |
complain, so i thought it was ok" |
125 |
might also be nice to use that list when you inherit a package from |
126 |
someone that builds and works fine, but you could go sit down check all |
127 |
the solutions in it against the list and clean up the ebuild, thus |
128 |
helping the QA team in the process, aside from not creating new ebuilds |
129 |
with evil things in them |
130 |
|
131 |
either way, can you provide a list of such things as they stand right |
132 |
now? to look over, i think it should be part of the policy/glep and |
133 |
should be seen beforehand |
134 |
|
135 |
>>> * QA will take an active role in cleaning up unmaintained and broken |
136 |
>>> packages from the tree. It is also encouraged of members of the QA team to |
137 |
>>> assist in mentoring new developers that wish to take over unmaintained |
138 |
>>> packages/herds. |
139 |
>>> |
140 |
>>> |
141 |
>> i am not sure how to read this one, it could mean broken packages that |
142 |
>> are unmaintained, but how it is written it could also mean unmaintained |
143 |
>> || broken, not only unmaintained && broken, i really wish you would at |
144 |
>> least consider not killing off unmaintained and not broken packages, and |
145 |
>> word it in some way that this comes out clear in that paragraph |
146 |
> |
147 |
> It is written exactly how I meant for it to be interpretted. We will be |
148 |
> removing things that are unmaintained *and* broken. I'm sure the |
149 |
> security team will agree that this is a problem that currently plagues |
150 |
> them as well, and I think we can help them out by doing what we can in |
151 |
> this regard. |
152 |
|
153 |
|
154 |
|
155 |
-----BEGIN PGP SIGNATURE----- |
156 |
Version: GnuPG v1.4.2.1 (GNU/Linux) |
157 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
158 |
|
159 |
iD8DBQFETXOU/aM9DdBw91cRAhzlAKCIKqYLXzLa9tvv+gmzBvOwKgpmUACfe+ly |
160 |
6t2AX/8lAswhv5/H/mNP+0A= |
161 |
=W+Wp |
162 |
-----END PGP SIGNATURE----- |
163 |
-- |
164 |
gentoo-dev@g.o mailing list |