My personal opinion here is that a _LOT_ of this should be common sense. But just to put in my two pennies..
On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser <[EMAIL PROTECTED]> wrote: > * The QA team's purpose is to provide cross-herd 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. Please clarify "neccessary". I don't want to see repeat occurances of non-issues bogging down real work. Also, please define around this a clear and documented policy so when its enforced, its well defended. > * 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. I have no objections, on the understanding that there is a definitive understanding of whats being changed and legitimate things aren't accidentally replaced. > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem. This is part and parcel of your first point and should be included as part of that. ie: definition of neccessary and surrounding policy. > * 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. as above. > * In the case of disagreement on policy among QA members, the majority > of established QA members must agree with the action. Perhaps pushing it to an open forum on -dev/-core for consensus works better here? > * Just because a particular QA violation has yet to cause an issue does > not change the fact that it is still a QA violation. Is this a statement or a policy? I assume that if this is policy the non-visible issue would go about appropriate scrutany, and in turn a long-term solution made in the situation where it is not easily resolvable/avoidable. > * 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. This is the case at the moment anyways isn't it? And this shouldn't be in a QA capacity but as a herd or individual. Perhaps this is better suited in a different proposal? > * The QA team will maintain a list of current "QA Standards". 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. > Can I suggest that such a document is also refered to by the policy surrounding a violations resolution. Especially when considering a violation which is not documented (and therefore can be fairly unknown) so that violations not listed might be treated with more tact. Thanks for presenting this to the list. - John -- Role: Gentoo Linux Kernel Lead Gentoo Linux: http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515
pgpQtTJfXrQYF.pgp
Description: PGP signature
