Gentoo Archives: gentoo-dev

From: Daniel Goller <morfic@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] QA Proposal v3
Date: Tue, 25 Apr 2006 01:00:57
In Reply to: Re: [gentoo-dev] QA Proposal v3 by Mark Loeser
2 Hash: SHA1
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.
23 is what you are saying that the line is superfluous since it is covered
24 by the paragraph below ?
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
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
43 > as soon as possible - exactly what it says, as soon as possible
46 >
47 > Basically, use common sense here please :)
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
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.
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 >
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
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.
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 >
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)
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?
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 >
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
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
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.
156 Version: GnuPG v1.4.2.1 (GNU/Linux)
157 Comment: Using GnuPG with Mozilla -
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