Here is the newest revision of my proposal. Not much has changed, but I added and changed some small things. Constructive feedback is appreciated. I'd like to get this voted on by the council at the next meeting.
* 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.
* 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 on policy among QA members, the majority
of established QA members must agree with the action.
* 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 devrel re-evaluates that developer's commit rights.
Evidence of past breakages will be presented with this request to
devrel.
* 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.
* In order to join the QA team, you must be a developer for at least 4
months and must ask the current lead for approval.
* 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 unmaintained and broken
packages from the tree. It is also encouraged of members of the QA team to
assist in mentoring new developers that wish to take over unmaintained
packages/herds.
--
Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86)
email - halcy0n AT gentoo DOT org
mark AT halcy0n DOT com
web - http://dev.gentoo.org/~halcy0n/
http://www.halcy0n.com
pgpP8aunh9bTt.pgp
Description: PGP signature
