Contents of /xml/htdocs/proj/en/glep/glep-0048.txt

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.2 - (show annotations) (download)
Tue Sep 5 20:34:26 2006 UTC (11 years, 10 months ago) by g2boojum
Branch: MAIN
Changes since 1.1: +3 -3 lines
File MIME type: text/plain

1 GLEP: 48
2 Title: QA Team's Role and Purpose
3 Version: $Revision: 1.1 $
4 Last-Modified: $Date: 2006/04/24 17:26:48 $
5 Author: Mark Loeser <halcy0n@gentoo.org>,
6 Status: Final
7 Type: Standards Track
8 Content-Type: text/x-rst
9 Created: 24 April 2006
10 Post-History: 24-Apr-2006
13 Abstract
14 ========
16 This GLEP outlines the abilities and purpose of the Quality Assurance team
17 for Gentoo.
19 Motivation
20 ==========
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.
26 Specification
27 =============
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.
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.
82 Backwards Compatibility
83 =======================
85 Not a problem for this GLEP.
87 Copyright
88 =========
90 This document has been placed in the public domain.

  ViewVC Help
Powered by ViewVC 1.1.20