On Thursday 02 March 2006 03:53, Mark Loeser wrote: > Here is my updated version after some feedback from people: > > * 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 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. > * 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. > * In the case of disagreement on policy among QA members, the majority > of established QA members must agree with the action. > * 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. >
I'd like to add the following two points: * Just because breaking policy breaks a QA tool, but is guaranteed to never break itself (formatting policy, like space vs. tab etc.) does not increase the severity of the breakage. * Before any enforcement is possible, QA must establish a well supported (debated on dev-) exception policy. While it were nice if exceptions are not needed, reality is that they can not be avoided. Therefore there must be an exception policy. An exception does not mean there is no violation (so appeal is pointless). An exception means that the violation is needed because it offers important features for the user, and the benefits outweigh the costs. At the same time that an exception is allowed, steps should be undertaken to get a structural solution to the problem. QA is responsible for ensuring that the maintainer(s) of the package in question keep on doing so. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgprXCemTv9v5.pgp
Description: PGP signature
