From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.54) id 1FDV6M-00053u-08 for garchives@archives.gentoo.org; Sun, 26 Feb 2006 23:14:54 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1QNDf7u007814; Sun, 26 Feb 2006 23:13:41 GMT Received: from getafix.willow.local (169.248.adsl.brightview.com [80.189.248.169] (may be forged)) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1QNBSfH009998 for <gentoo-dev@lists.gentoo.org>; Sun, 26 Feb 2006 23:11:28 GMT Received: from dogmatix.willow.local ([192.168.0.100] helo=dogmatix) by getafix.willow.local with smtp (Exim 4.54) id 1FDV2v-0003wE-US for gentoo-dev@lists.gentoo.org; Sun, 26 Feb 2006 23:11:28 +0000 Received: by dogmatix (sSMTP sendmail emulation); Sun, 26 Feb 2006 23:11:21 +0000 From: johnm@gentoo.org Date: Sun, 26 Feb 2006 23:11:21 +0000 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] QA Team's role Message-ID: <20060226231121.GB11930@dogmatix.willow.local> References: <20060226222217.GB17257@aerie.halcy0n.com> Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="adJ1OR3c6QgCpb/j" Content-Disposition: inline In-Reply-To: <20060226222217.GB17257@aerie.halcy0n.com> User-Agent: Mutt/1.5.11 X-Spam-Score: -0.9 (/) X-Archives-Salt: b9953949-6702-4981-828d-930ea3219f17 X-Archives-Hash: 7dfa53bdfce7edd672a576ff7a346b78 --adJ1OR3c6QgCpb/j Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 <halcy0n@gentoo.org> = 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 agreem= ent 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. >=20 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 --=20 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 --adJ1OR3c6QgCpb/j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEAjWZNzVYcyGvtWURAnLBAKDMGJLHMFya7m4MJHlR/qXCPiNXQACg24Fy 2P9g+dexOmcfnfMdjgRH5PE= =S0wW -----END PGP SIGNATURE----- --adJ1OR3c6QgCpb/j-- -- gentoo-dev@gentoo.org mailing list