1 |
On Sun, 26 Feb 2006 23:11:21 +0000 johnm@g.o wrote: |
2 |
| On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser |
3 |
| <halcy0n@g.o> wrote: |
4 |
| > * The QA team's purpose is to provide cross-herd assistance in |
5 |
| > keeping the tree in a good state. This is done primarily by finding |
6 |
| > and pointing out issues to maintainers and, where necessary, taking |
7 |
| > direct action. |
8 |
| |
9 |
| Please clarify "neccessary". I don't want to see repeat occurances of |
10 |
| non-issues bogging down real work. Also, please define around this a |
11 |
| clear and documented policy so when its enforced, its well defended. |
12 |
|
13 |
The problem is... It's impossible to document every single way in which |
14 |
someone can screw up. For example, I wouldn't've thought to document |
15 |
"you should not run mkdir in global scope", because I didn't think |
16 |
anyone would be daft enough to do it. Policy *has* to rely upon the |
17 |
basic assumption that developers won't do something crazy. |
18 |
|
19 |
| > * The QA team may also offer to fix obvious typos and similar minor |
20 |
| > issues, and silence from the package maintainers can be taken as |
21 |
| > agreement in such situations. |
22 |
| |
23 |
| I have no objections, on the understanding that there is a definitive |
24 |
| understanding of whats being changed and legitimate things aren't |
25 |
| accidentally replaced. |
26 |
|
27 |
Example of where this clause would be used, had said bug not been |
28 |
fixed quickly anyway: bug #122902. |
29 |
|
30 |
| > * In the case of disagreement on policy among QA members, the |
31 |
| > majority of established QA members must agree with the action. |
32 |
| |
33 |
| Perhaps pushing it to an open forum on -dev/-core for consensus works |
34 |
| better here? |
35 |
|
36 |
The problem with that is, it usually ends up with too many pointless |
37 |
comments from people saying how things could be fixed in the distant |
38 |
future, or whining that it isn't explicitly forbidden by policy on |
39 |
situations where the screwup was too weird to be documented previously. |
40 |
|
41 |
| > * Just because a particular QA violation has yet to cause an issue |
42 |
| > does not change the fact that it is still a QA violation. |
43 |
| |
44 |
| Is this a statement or a policy? I assume that if this is policy the |
45 |
| non-visible issue would go about appropriate scrutany, and in turn a |
46 |
| long-term solution made in the situation where it is not easily |
47 |
| resolvable/avoidable. |
48 |
|
49 |
This is to cover for situations where people claim that their screwups |
50 |
are ok because no-one has yet reported it as broken. |
51 |
|
52 |
-- |
53 |
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) |
54 |
Mail : ciaranm at gentoo.org |
55 |
Web : http://dev.gentoo.org/~ciaranm |