Gentoo Archives: gentoo-dev

From: Daniel Goller <morfic@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] QA Proposal v3
Date: Mon, 24 Apr 2006 04:52:55
In Reply to: [gentoo-dev] QA Proposal v3 by Mark Loeser
2 Hash: SHA1
4 Mark Loeser wrote:
5 > Here is the newest revision of my proposal. Not much has changed, but I
6 > added and changed some small things. Constructive feedback is
7 > appreciated. I'd like to get this voted on by the council at the next
8 > meeting.
9 >
10 > * The QA team's purpose is to provide cross-team assistance in keeping
11 > the tree in a good state. This is done primarily by finding and pointing
12 > out issues to maintainers and, where necessary, taking direct action.
14 describe what makes it necessary and what actions will be taken
15 or if the paragraphs below are meant to do that, you can save that line
16 in that paragraph
18 > * In case of emergency, or if package maintainers refuse to cooperate,
19 > the QA team may take action themselves to fix the problem. The QA
20 > team does not want to override the maintainer's wishes by default, but only
21 > wish to do so when the team finds it is in the best interest of users
22 > and fellow developers to have the issue addressed as soon as possible.
24 define emergency, define as soon as possible (some bugs might be quite
25 tricky to track and might be put on back burner and what little time is
26 available used on things not taking up equal times), how do you know ia
27 dev is not cooperating or if i he/she is just prioritizing
29 > * The QA team may also offer to fix obvious typos and similar minor
30 > issues, and silence from the package maintainers can be taken as agreement
31 > in such situations. Coding style issues fall under this category, and
32 > while they are not severe, they can make automated checks of the tree more
33 > difficult.
35 thanks for the offer, sounds good
37 > * There will be cases when our tools are incapable of handling a certain
38 > situation and policy must be broken in order to get something working
39 > completely. This will hopefully not occur very often but each time it
40 > does occur, the QA team and the maintainer will come to some agreement
41 > on an interim solution and it is expected that a bug will be opened with
42 > the appropriate team to work towards a correct solution.
44 sounds reasonable
46 > * In the case of disagreement on policy among QA members, the majority
47 > of established QA members must agree with the action.
49 you shouldn't disagree about this policy, or you might as well not have
50 this document, write disagree on the solution maybe?
52 > * In the event that a developer still insists that a package does not
53 > break QA standards, an appeal can be made at the next council meeting. The
54 > package should be dealt with per QA's request until such a time that a
55 > decision is made by the council.
57 The default could be that the ebuild not be touched unless it is a issue
58 that breaks the tree or is security related where time is of the
59 essence. word it in that direction?
61 > * Just because a particular QA violation has yet to cause an issue does
62 > not change the fact that it is still a QA violation.
64 Then you must be talking about coding style here? remove the point and
65 add it above to coding style, as an example why you will deal with the
66 coding style maybe? no other violation should be left to such vagueness
68 > * If a particular developer persistently causes breakage, the QA team
69 > may request that devrel re-evaluates that developer's commit rights.
70 > Evidence of past breakages will be presented with this request to
71 > devrel.
73 define persistently, how do you presistently cause breakage? maybe this
74 is one of those non native english speaker moments, but doesn't that
75 mean like every commit is botched?
77 > * The QA team will maintain a list of current "QA Standards" with
78 > explanations as to why they are problems, and how to fix the problem.
79 > The list is not meant by any means to be a comprehensive document, but
80 > rather a dynamic document that will be updated as new problems are
81 > discovered. The QA team will also do their best to ensure all developer
82 > tools are in line with the current QA standards.
84 as said in the other two posts, maybe write it is a comprehensive list,
85 just that it is not finite? that might clear this point up.
87 > * In order to join the QA team, you must be a developer for at least 4
88 > months and must ask the current lead for approval.
90 that shouldn't be too hard
92 > * The QA team will work with Recruiters to keep related documentation
93 > and quizzes up to date, so that up and coming developers will have access
94 > to all of the necessary information to avoid past problems.
96 sounds good
98 > * QA will take an active role in cleaning up unmaintained and broken
99 > packages from the tree. It is also encouraged of members of the QA team to
100 > assist in mentoring new developers that wish to take over unmaintained
101 > packages/herds.
102 >
103 >
105 i am not sure how to read this one, it could mean broken packages that
106 are unmaintained, but how it is written it could also mean unmaintained
107 || broken, not only unmaintained && broken, i really wish you would at
108 least consider not killing off unmaintained and not broken packages, and
109 word it in some way that this comes out clear in that paragraph
111 finally had some time to read this in more detail
112 hope the feedback helps
114 Daniel
118 Version: GnuPG v1.4.2.1 (GNU/Linux)
119 Comment: Using GnuPG with Mozilla -
122 H296TQyH7S1dA3NfbscYj5Q=
123 =ypTj
124 -----END PGP SIGNATURE-----
125 --
126 gentoo-dev@g.o mailing list


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