1 |
On 28-01-2011 22:11:30 +0100, Tomáš Chvátal wrote: |
2 |
> So draft we would like to have implemented as Glep update is this diff: |
3 |
> http://dev.gentoo.org/~scarabeus/glep-0048.diff |
4 |
> |
5 |
> Please comment and help us improve the "english" of the whole document |
6 |
> so it gets accepted :) |
7 |
|
8 |
(:Nread http://dev.gentoo.org/~scarabeus/glep-0048.diff) |
9 |
> --- glep-0048.txt 2006-09-05 22:45:04.000000000 +0200 |
10 |
> +++ glep-0048.new.txt 2011-01-25 13:49:38.525343000 +0100 |
11 |
> @@ -34,6 +34,20 @@ |
12 |
> * The QA team's purpose is to provide cross-team assistance in keeping the |
13 |
> tree in a good state. This is done primarily by finding and pointing out |
14 |
> issues to maintainers and, where necessary, taking direct action. |
15 |
> +* The QA team is directed by a lead, chosen yearly by private or |
16 |
> + public election among the members of the team. The QA team lead can |
17 |
> + choose one member as a deputy. The deputy has all of his powers directly |
18 |
> + delegated from the QA team lead and thus his actions and decisions should |
19 |
> + be considered equal to those of the QA team lead. The deputy is directly |
20 |
> + responsible only to the QA team lead. |
21 |
|
22 |
Since QA is getting lots of powers these days, I strongly object to |
23 |
this, see also my comment on becoming a QA member. I suggest the |
24 |
following: |
25 |
|
26 |
The QA lead is yearly elected by the whole dev-community (active |
27 |
developers), same procedure as being used for a council voting. The |
28 |
nomination is also done by developers, but they can only chose from the |
29 |
current QA-members. |
30 |
|
31 |
> +* The QA team lead must approve developers who would like to join the project. The |
32 |
> + applicant must demonstrate a thorough understanding of the duties he would like |
33 |
> + to perform. By accepting the applicant the QA team lead will accept |
34 |
> + the responsibility to direct them as part of the team and will be held |
35 |
> + responsible for any action the team member takes on behalf of the QA team. |
36 |
|
37 |
Again, I strongly object to this plan. Instead: |
38 |
|
39 |
To become a QA member, one must be a current developer, for at least 6 |
40 |
months, and one must go through a quiz. The quiz is then evaluated by |
41 |
the QA lead or a replacing member from the QA team, in the same way as |
42 |
recruiters evaluate new developers. The outcome of the evaluation is |
43 |
signed by the QA lead. In case of decline of a new member after the |
44 |
evalation, the QA lead must be able to provide a written argumentation |
45 |
of this decline, which can be requested by said member or by devrel. If |
46 |
providing such argumentation is impossible within a week after |
47 |
evaluation, QA must accept said member to the QA team. |
48 |
|
49 |
> +* Any QA team lead decision can be revoked by a major opposing vote from |
50 |
> + all current QA members. Given the nature of this action new elections |
51 |
> + should be held within 1 month to elect a new QA team lead. |
52 |
> * In case of emergency, or if package maintainers refuse to cooperate, |
53 |
> the QA team may take action themselves to fix the problem. The QA team |
54 |
> does not want to override the maintainer's wishes by default, but only |
55 |
> @@ -50,7 +64,7 @@ |
56 |
> an interim solution and it is expected that a bug will be opened with the |
57 |
> appropriate team to work towards a correct solution. |
58 |
> * In the case of disagreement among QA members the majority of established |
59 |
> - QA members must agree with the action. Some examples of disagreements are: |
60 |
> + QA members must agree with the action. Some examples of disagreements are: |
61 |
|
62 |
sentences are separated by double spaces, nevertheless, this doesn't |
63 |
belong in this patch |
64 |
|
65 |
> whether the percieved problem violates the policy or whether the solution |
66 |
> makes the situation worse. |
67 |
> * In the event that a developer still insists that a package does not break |
68 |
> @@ -59,17 +73,23 @@ |
69 |
> made by the council. |
70 |
> * Just because a particular QA violation has yet to cause an issue does not |
71 |
> change the fact that it is still a QA violation. |
72 |
> -* If a particular developer persistently causes breakage, the QA team |
73 |
> - may request that devrel re-evaluates that developer's commit rights. |
74 |
> - Evidence of past breakages will be presented with this request to devrel. |
75 |
> +* In case a particular developer persistently causes breakage, the QA |
76 |
> + lead may request commit rights of given developer to be suspended by |
77 |
> + the Infra team. Devrel should then proceed to evaluate the situation, by |
78 |
> + finding a compromise or permanently revoking those rights. |
79 |
> +* Should a situation arise where a developer causes breakage to the point |
80 |
> + that it cannot be ascribed to bona-fide mistake, either the QA lead or two |
81 |
> + members of the QA team can require the Infra team to temporarily suspend |
82 |
> + access to said developer, pending analysis of the causes and resolution |
83 |
> + to be provided by the QA team within 14 days of said suspension. |
84 |
> + Resolution for this kind of issue is completely in hands of the QA team |
85 |
> + and only the Gentoo Council can revisit the case. |
86 |
|
87 |
It seems I feel the same as Rich here. I object against this policy, |
88 |
instead: |
89 |
|
90 |
After QA suspension, resolution must go through devrel with QA lead as the |
91 |
party that sets up the argumentation/evidence for said actions, and |
92 |
suggested resolution. However, devrel will evaluate and perform the |
93 |
final statement/actions here. |
94 |
|
95 |
> * The QA team will maintain a list of current "QA Standards" with explanations |
96 |
> as to why they are problems, and how to fix the problem. The list is not |
97 |
> meant by any means to be a comprehensive document, but rather a dynamic |
98 |
> document that will be updated as new problems are discovered. The QA team |
99 |
> will also do their best to ensure all developer tools are in line with the |
100 |
> current QA standards. |
101 |
> -* In order to join the QA team, you must be a developer for at least 4 months |
102 |
> - and must ask the current lead for approval. |
103 |
> * The QA team will work with Recruiters to keep related documentation and |
104 |
> quizzes up to date, so that up and coming developers will have access to all |
105 |
> of the necessary information to avoid past problems. |
106 |
|
107 |
|
108 |
-- |
109 |
Fabian Groffen |
110 |
Gentoo on a different level |