| 1 |
g2boojum |
1.1 |
GLEP: 48
|
| 2 |
|
|
Title: QA Team's Role and Purpose
|
| 3 |
|
|
Version: $Revision: $
|
| 4 |
|
|
Last-Modified: $Date: $
|
| 5 |
|
|
Author: Mark Loeser <halcy0n@gentoo.org>,
|
| 6 |
|
|
Status: Draft
|
| 7 |
|
|
Type: Standards Track
|
| 8 |
|
|
Content-Type: text/x-rst
|
| 9 |
|
|
Created: 24 April 2006
|
| 10 |
|
|
Post-History: 24-Apr-2006
|
| 11 |
|
|
|
| 12 |
|
|
|
| 13 |
|
|
Abstract
|
| 14 |
|
|
========
|
| 15 |
|
|
|
| 16 |
|
|
This GLEP outlines the abilities and purpose of the Quality Assurance team
|
| 17 |
|
|
for Gentoo.
|
| 18 |
|
|
|
| 19 |
|
|
Motivation
|
| 20 |
|
|
==========
|
| 21 |
|
|
|
| 22 |
|
|
For years now developers have been saying how we need an empowered QA team to
|
| 23 |
|
|
handle problems concerning the tree. This GLEP provides the structure for
|
| 24 |
|
|
such a team and specifies the roles the team would fulfill.
|
| 25 |
|
|
|
| 26 |
|
|
Specification
|
| 27 |
|
|
=============
|
| 28 |
|
|
|
| 29 |
|
|
The QA team should be given certain abilities to look out for the best
|
| 30 |
|
|
interests of all developers, as well as our users. The QA team should also
|
| 31 |
|
|
work to ensure developers have the information they need, and that packages
|
| 32 |
|
|
are maintained.
|
| 33 |
|
|
|
| 34 |
|
|
* The QA team's purpose is to provide cross-team assistance in keeping the
|
| 35 |
|
|
tree in a good state. This is done primarily by finding and pointing out
|
| 36 |
|
|
issues to maintainers and, where necessary, taking direct action.
|
| 37 |
|
|
* In case of emergency, or if package maintainers refuse to cooperate,
|
| 38 |
|
|
the QA team may take action themselves to fix the problem. The QA team
|
| 39 |
|
|
does not want to override the maintainer's wishes by default, but only
|
| 40 |
|
|
wish to do so when the team finds it is in the best interest of users and
|
| 41 |
|
|
fellow developers to have the issue addressed as soon as possible.
|
| 42 |
|
|
* The QA team may also offer to fix obvious typos and similar minor issues,
|
| 43 |
|
|
and silence from the package maintainers can be taken as agreement in such
|
| 44 |
|
|
situations. Coding style issues fall under this category, and while they
|
| 45 |
|
|
are not severe, they can make automated checks of the tree more difficult.
|
| 46 |
|
|
* There will be cases when our tools are incapable of handling a certain
|
| 47 |
|
|
situation and policy must be broken in order to get something working
|
| 48 |
|
|
completely. This will hopefully not occur very often but each time it
|
| 49 |
|
|
does occur, the QA team and the maintainer will come to some agreement on
|
| 50 |
|
|
an interim solution and it is expected that a bug will be opened with the
|
| 51 |
|
|
appropriate team to work towards a correct solution.
|
| 52 |
|
|
* In the case of disagreement among QA members the majority of established
|
| 53 |
|
|
QA members must agree with the action. Some examples of disagreements are:
|
| 54 |
|
|
whether the percieved problem violates the policy or whether the solution
|
| 55 |
|
|
makes the situation worse.
|
| 56 |
|
|
* In the event that a developer still insists that a package does not break
|
| 57 |
|
|
QA standards, an appeal can be made at the next council meeting. The package
|
| 58 |
|
|
should be dealt with per QA's request until such a time that a decision is
|
| 59 |
|
|
made by the council.
|
| 60 |
|
|
* Just because a particular QA violation has yet to cause an issue does not
|
| 61 |
|
|
change the fact that it is still a QA violation.
|
| 62 |
|
|
* If a particular developer persistently causes breakage, the QA team
|
| 63 |
|
|
may request that devrel re-evaluates that developer's commit rights.
|
| 64 |
|
|
Evidence of past breakages will be presented with this request to devrel.
|
| 65 |
|
|
* The QA team will maintain a list of current "QA Standards" with explanations
|
| 66 |
|
|
as to why they are problems, and how to fix the problem. The list is not
|
| 67 |
|
|
meant by any means to be a comprehensive document, but rather a dynamic
|
| 68 |
|
|
document that will be updated as new problems are discovered. The QA team
|
| 69 |
|
|
will also do their best to ensure all developer tools are in line with the
|
| 70 |
|
|
current QA standards.
|
| 71 |
|
|
* In order to join the QA team, you must be a developer for at least 4 months
|
| 72 |
|
|
and must ask the current lead for approval.
|
| 73 |
|
|
* The QA team will work with Recruiters to keep related documentation and
|
| 74 |
|
|
quizzes up to date, so that up and coming developers will have access to all
|
| 75 |
|
|
of the necessary information to avoid past problems.
|
| 76 |
|
|
* QA will take an active role in cleaning up and removing from the tree
|
| 77 |
|
|
unmaintained packages as they are found to be broken. It is also
|
| 78 |
|
|
encouraged of members of the QA team to assist in mentoring new developers
|
| 79 |
|
|
that wish to take over unmaintained packages/herds.
|
| 80 |
|
|
|
| 81 |
|
|
|
| 82 |
|
|
Backwards Compatibility
|
| 83 |
|
|
=======================
|
| 84 |
|
|
|
| 85 |
|
|
Not a problem for this GLEP.
|
| 86 |
|
|
|
| 87 |
|
|
Copyright
|
| 88 |
|
|
=========
|
| 89 |
|
|
|
| 90 |
|
|
This document has been placed in the public domain.
|
| 91 |
|
|
|
Parent Directory
| 
Revision Log