Gentoo Archives: gentoo-dev

From: Mark Loeser <halcy0n@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] QA Proposal v3
Date: Mon, 24 Apr 2006 13:14:12
In Reply to: Re: [gentoo-dev] QA Proposal v3 by Daniel Goller
1 Daniel Goller <morfic@g.o> said:
2 > Mark Loeser wrote:
3 > > Here is the newest revision of my proposal. Not much has changed, but I
4 > > added and changed some small things. Constructive feedback is
5 > > appreciated. I'd like to get this voted on by the council at the next
6 > > meeting.
7 > >
8 > > * The QA team's purpose is to provide cross-team assistance in keeping
9 > > the tree in a good state. This is done primarily by finding and pointing
10 > > out issues to maintainers and, where necessary, taking direct action.
11 >
12 > describe what makes it necessary and what actions will be taken
13 > or if the paragraphs below are meant to do that, you can save that line
14 > in that paragraph
16 What makes it necessary is if something is broken or goes against
17 policy, and the actions are listed below. I was pretty sure this went
18 without saying.
20 > > * In case of emergency, or if package maintainers refuse to cooperate,
21 > > the QA team may take action themselves to fix the problem. The QA
22 > > team does not want to override the maintainer's wishes by default, but only
23 > > wish to do so when the team finds it is in the best interest of users
24 > > and fellow developers to have the issue addressed as soon as possible.
25 >
26 > define emergency, define as soon as possible (some bugs might be quite
27 > tricky to track and might be put on back burner and what little time is
28 > available used on things not taking up equal times), how do you know ia
29 > dev is not cooperating or if i he/she is just prioritizing
31 emergency - something that is broken and affects a great number of users
32 as soon as possible - exactly what it says, as soon as possible
34 Basically, use common sense here please :)
36 > > * In the case of disagreement on policy among QA members, the majority
37 > > of established QA members must agree with the action.
38 >
39 > you shouldn't disagree about this policy, or you might as well not have
40 > this document, write disagree on the solution maybe?
42 It was not referring to *this* policy, but the exact policy that is
43 dealing with the problem at hand. In this context, it was meant to be
44 read that what some of us to believe is a problem is actually a problem
45 here, and that the solution is reasonable. I will write the whole thing
46 out to improve clarity.
48 > > * Just because a particular QA violation has yet to cause an issue does
49 > > not change the fact that it is still a QA violation.
50 >
51 > Then you must be talking about coding style here? remove the point and
52 > add it above to coding style, as an example why you will deal with the
53 > coding style maybe? no other violation should be left to such vagueness
55 No, I'm talking about problems that were not noticed before and we just
56 realized the implications of what we are doing.
58 > > * If a particular developer persistently causes breakage, the QA team
59 > > may request that devrel re-evaluates that developer's commit rights.
60 > > Evidence of past breakages will be presented with this request to
61 > > devrel.
62 >
63 > define persistently, how do you presistently cause breakage? maybe this
64 > is one of those non native english speaker moments, but doesn't that
65 > mean like every commit is botched?
67 Not every commit, but a recognizable pattern can be seen.
69 > > * The QA team will maintain a list of current "QA Standards" with
70 > > explanations as to why they are problems, and how to fix the problem.
71 > > The list is not meant by any means to be a comprehensive document, but
72 > > rather a dynamic document that will be updated as new problems are
73 > > discovered. The QA team will also do their best to ensure all developer
74 > > tools are in line with the current QA standards.
75 >
76 > as said in the other two posts, maybe write it is a comprehensive list,
77 > just that it is not finite? that might clear this point up.
79 The wording as it currently stands is what I mean for it to say. Our
80 document should never be considered to cover *every* single thing you
81 can do wrong. It also covers that the document is never complete, and
82 that we are always working on improving it.
84 > > * QA will take an active role in cleaning up unmaintained and broken
85 > > packages from the tree. It is also encouraged of members of the QA team to
86 > > assist in mentoring new developers that wish to take over unmaintained
87 > > packages/herds.
88 > >
89 > >
90 >
91 > i am not sure how to read this one, it could mean broken packages that
92 > are unmaintained, but how it is written it could also mean unmaintained
93 > || broken, not only unmaintained && broken, i really wish you would at
94 > least consider not killing off unmaintained and not broken packages, and
95 > word it in some way that this comes out clear in that paragraph
97 It is written exactly how I meant for it to be interpretted. We will be
98 removing things that are unmaintained *and* broken. I'm sure the
99 security team will agree that this is a problem that currently plagues
100 them as well, and I think we can help them out by doing what we can in
101 this regard.
103 --
104 Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86)
105 email - halcy0n AT gentoo DOT org
106 mark AT halcy0n DOT com
107 web -


Subject Author
Re: [gentoo-dev] QA Proposal v3 Mark Loeser <halcy0n@g.o>
[gentoo-dev] Re: QA Proposal v3 Duncan <1i5t5.duncan@×××.net>
Re: [gentoo-dev] QA Proposal v3 Daniel Goller <morfic@g.o>