1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
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. |
13 |
|
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 |
17 |
|
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. |
23 |
|
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 |
28 |
|
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. |
34 |
|
35 |
thanks for the offer, sounds good |
36 |
|
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. |
43 |
|
44 |
sounds reasonable |
45 |
|
46 |
> * In the case of disagreement on policy among QA members, the majority |
47 |
> of established QA members must agree with the action. |
48 |
|
49 |
you shouldn't disagree about this policy, or you might as well not have |
50 |
this document, write disagree on the solution maybe? |
51 |
|
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. |
56 |
|
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? |
60 |
|
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. |
63 |
|
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 |
67 |
|
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. |
72 |
|
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? |
76 |
|
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. |
83 |
|
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. |
86 |
|
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. |
89 |
|
90 |
that shouldn't be too hard |
91 |
|
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. |
95 |
|
96 |
sounds good |
97 |
|
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 |
> |
104 |
|
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 |
110 |
|
111 |
finally had some time to read this in more detail |
112 |
hope the feedback helps |
113 |
|
114 |
Daniel |
115 |
|
116 |
|
117 |
-----BEGIN PGP SIGNATURE----- |
118 |
Version: GnuPG v1.4.2.1 (GNU/Linux) |
119 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
120 |
|
121 |
iD8DBQFETFkI/aM9DdBw91cRAgQWAKDBuxieQZTwcGw+VC2IGGNaGUnO8gCcDPTJ |
122 |
H296TQyH7S1dA3NfbscYj5Q= |
123 |
=ypTj |
124 |
-----END PGP SIGNATURE----- |
125 |
-- |
126 |
gentoo-dev@g.o mailing list |