[gentoo-project] Fwd: [gentoo-dev] rfc: formally allow qa to suspend commit rights

[William Hubbs]

----- Forwarded message from William Hubbs <williamh@g.o> -----

> Date: Sat, 18 Jan 2014 23:02:24 -0600
> From: William Hubbs <williamh@g.o>
> To: gentoo development <gentoo-dev@l.g.o>
> Subject: [gentoo-dev] rfc: formally allow qa to suspend commit rights
>
> All,
>
> I would like to bring back for discussion an old patch to glep 48 [1]
> which was suggested by Jorge [2].
>
> That patch evolved into this one [3], and in the council meeting back
> then [4], parts of it made their way into glep 48, but the rest seemed to
> be forgotten.
>
> Attached you will find an updated version of this patch taking into
> account the current version of glep 48.
>
> This is nothing new; the qa team has requested that commit rights be
> suspended before. I am just proposing that we actually add the parts of
> the old patch to the glep that spell out when and how this can happen.
>
> Thoughts?
>
> William
>
> [1] http://wiki.gentoo.org/wiki/GLEP:48
> [2] http://archives.gentoo.org/gentoo-project/msg_ac161677a6e06a8647e16420eeae8d47.xml
> [3] http://www.mail-archive.com/gentoo-qa@l.g.o/msg00144.html
> [4] http://www.gentoo.org/proj/en/council/meeting-logs/20110608-summary.txt

> diff --git a/GLEP:48.mw b/GLEP:48.mw
> index 1012011..a1633d7 100644
> --- a/GLEP:48.mw
> +++ b/GLEP:48.mw
> @@ -24,13 +24,15 @@ The QA team should be given certain abilities to look out for the best interests
>  * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action.
>  * The QA team is directed by a lead, chosen yearly by private or public election  among the members of the team, and confirmed by the council. The QA team lead can choose one member as a deputy. The deputy has all of his powers directly delegated from the QA team lead and thus his actions and decisions should be considered equal to those of the QA team lead. The deputy is directly responsible only to the QA team lead.
>  * The QA team lead must approve developers who would like to join the project. The applicant must demonstrate a thorough understanding of the duties he would like to perform. By accepting the applicant the QA team lead will accept the responsibility to direct them as part of the team and will be held responsible for any action the team member takes on behalf of the QA team.
> +* Any QA team lead decision can be revoked by major opposing vote from all current QA members. Given the nature of this action new elections should be held within 1 month to elect a new QA team lead.
>  * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem.  The QA team does not want to override the maintainer's wishes by default, but only wish to do so when the team finds it is in the best interest of users and fellow developers to have the issue addressed as soon as possible.
>  * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations.  Coding style issues fall under this category, and while they are not severe, they can make automated checks of the tree more difficult.
>  * There will be cases when our tools are incapable of handling a certain situation and policy must be broken in order to get something working completely.  This will hopefully not occur very often, but each time it does occur, the QA team and the maintainer will come to some agreement on an interim solution and it is expected that a bug will be opened with the appropriate team to work towards a correct solution.
>  * In the case of disagreement among QA members the majority of established QA members must agree with the action.  Some examples of disagreements are whether the perceived problem violates the policy or whether the solution makes the situation worse.
>  * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council.
>  * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation.
> -* If a particular developer persistently causes breakage, the QA team may request that Comrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to Comrel.
> +* In case a particular developer persistently causes breakage, the QA lead may request commit rights of that developer to be suspended by the Infra team. Comrel should then proceed to evaluate the situation, by finding a compromise or pernamently revoking those rights.
> +* Should a situation arise where a developer causes breakage to the point that it cannot be ascribed to an honest mistake, either the QA lead or two members of the QA team can require the Infra team to temporarily suspend commit access for the developer, pending analysis of the causes and resolution to be provided by the QA team within 14 days of said suspension.  Resolution for these kinds of issues is completely in the hands of the QA team, and only the Gentoo Council can revisit the case.
>  * The QA team will maintain a list of current "QA Standards" with explanations as to why they are problems, and how to fix the problem.  The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered.  The QA team will also do their best to ensure all developer tools are in line with the current QA standards.
>  * The QA team will work with Recruiters to keep related documentation and quizzes up to date, so that up and coming developers will have access to all of the necessary information to avoid past problems.
>  * QA will take an active role in cleaning up and removing from the tree unmaintained packages as they are found to be broken.  It is also encouraged of members of the QA team to assist in mentoring new developers that wish to take over unmaintained packages/herds.




----- End forwarded message -----