Gentoo Archives: gentoo-dev

From: Daniel Goller <morfic@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: QA Proposal v3
Date: Mon, 24 Apr 2006 07:19:32
Message-Id: 444C7B60.1030608@gentoo.org
In Reply to: [gentoo-dev] Re: QA Proposal v3 by Duncan <1i5t5.duncan@cox.net>
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 Duncan wrote:
5 > Daniel Goller posted <444C5909.1010606@g.o>, excerpted below, on
6 > Sun, 23 Apr 2006 23:50:17 -0500:
7 >
8 >>> * In the case of disagreement on policy among QA members, the majority
9 >>> of established QA members must agree with the action.
10 >> you shouldn't disagree about this policy, or you might as well not have
11 >> this document, write disagree on the solution maybe?
12 >
13 > Don't take this wrong but you did mention you weren't a native English
14 > speaker, and I think this the interpretation demonstrates that.
15 > (That isn't to say it couldn't be made clearer, just that your
16 > interpretation isn't likely to occur to a native English speaker, thus the
17 > discussion.)
18
19 no, there should not be disagreement on the QA policy, seriously, only
20 disagreement on the solution is logical and possible
21 the exception is not covered by policy, the possibility for exceptions
22 is however integrated into the policy, so the only disagreements could
23 be in how the exception is implemented, maybe 3 QA devs find solution A
24 best while 5 find B best, but all devs should agree that an exception is
25 granted because the current tools do not allow adherence to usual QA
26 standards
27
28 >
29 > To me (as a native English speaker), it's strange to consider that a
30 > reference to /this/ policy. Rather, the reference is to QA policy and
31 > decision making in general -- how a disagreement on QA policy between
32 > members of the QA team is to be handled.
33
34 to me a policy is the writing as a whole with all the bullet points, not
35 each individual point being a policy, and even if you would explain yes
36 each point is a policy, then the points should not be argued within QA,
37 see above for what would leave room for argument
38
39 >
40 > That this is the case would be particularly obvious in context, coming
41 > after (as it does) the previous point, dealing with exceptions due to
42 > imperfect tools and mentioning that there /are/ such exceptions. The
43 > point in question above doesn't /only/ deal with that, thus it's its own
44 > bullet point, but the thought is clearly to provide some guidance in
45 > dynamic situations, where for whatever reason there's a difference of
46 > opinion within QA on how to proceed (as an imperfect tool exception could
47 > legitimately provoke, again, the handy example, not the only case, thus
48 > it's not a sub-point but its own bullet point).
49 >
50 > The other alternative would be unanimous agreement or the decision of the
51 > maintainer in question rules, altho there is of course the middle
52 > possibilities of say 3/5 or 2/3 or 3/4 super-majority required in ordered
53 > to overrule the maintainer.
54 >
55 > As I said, your interpretation, that it applied to /this/ policy, wouldn't
56 > be likely to occur to a native English speaker, and does in fact seem a
57 > bit odd. However, that's not to say the point isn't valid, as it's
58 > certainly best that the document be clear to all, including non-native
59 > English speakers to whom the point as now written obviously isn't entirely
60 > clear.
61
62 i'm afraid i have to repeat that the policy is the sum of all points,
63 the writing, so all QA devs should agree on this one policy, and only
64 have discussions on solution to individual points, and not the actual
65 points of the policy, if there was room for discussion of the points of
66 the policy, then the policy is not ready for consumption by the
67 developer community
68
69 >
70 > Actually, the point about a 2/3 (or whatever) super-majority, vs. simple
71 > majority of the QA team needed to overrule a maintainer, is a good one to
72 > debate as well. Perhaps developers would be less worried about abuse if
73 > the majority required was stronger, thus improving the safety margin.
74 > Assuming that's the case, the policy as a whole could probably have more
75 > teeth in the case of a super-majority required, than would be possible if
76 > it's only a simple majority. If some sort of a super-majority was
77 > required, it should be easier to accept certain decisions, when they
78 > seriously impact a developer or Gentoo in general. I know if I had a
79 > disagreement and out of a five member team, two sided with me and three
80 > against, making it a majority-of-one, I'd be less comfortable with the
81 > outcome than if it had required a 2/3 majority, and thus 4 members of the
82 > team voting against me.
83 >
84 > Another way to approach it would be to state that for purposes of packages
85 > (s)he maintains, a developer gets one vote on the QA as well. Thus, in
86 > ordered to overrule h(im|er), the QA team would need 50%+2, since 50%+1
87 > would be deadlock with the developer siding on the keep things as they are
88 > side.
89 >
90 > The idea in either case is to minimize the possibility of something
91 > occurring without enough of a majority opinion to make the decision look
92 > arbitrary or subject to immediate reversal upon the whims of a single QA
93 > team member, without making it impotent in certain cases due to a
94 > requirement for a unanimous decision. Reason in the middle ground?
95 >
96
97 well, i do find your majority rules interesting, something that should
98 be discussed and the best solution should be written down and made part
99 of the policy
100
101
102 the reason for my feedback was to have things laid out much clearer,
103 less vague and thus avoid problems down the road by situations occuring
104 in which things go like "well i thought i (a QA dev) had the right to
105 ...." or "i (reg dev) didn't know they (QA) could do ..."
106 be clear on both sides by laying this out so there are no
107 misunderstandings or misinterpretations
108
109
110 and seriously, i never have heard a single point of a policy be called a
111 policy, thus my reply as it has been to the point and in this reply
112
113 Thanks,
114
115 Daniel
116 -----BEGIN PGP SIGNATURE-----
117 Version: GnuPG v1.4.2.1 (GNU/Linux)
118 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
119
120 iD8DBQFETHtg/aM9DdBw91cRArQ1AKCzgD4q7Xmng+R4dGbOw629njM/mgCfdj+P
121 qMmtY4iSgvG1LOPLACvi6zM=
122 =D4eg
123 -----END PGP SIGNATURE-----
124 --
125 gentoo-dev@g.o mailing list

Replies

Subject Author
[gentoo-dev] Re: Re: QA Proposal v3 Duncan <1i5t5.duncan@×××.net>