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 1FDVTR-0004Rr-Hp for garchives@archives.gentoo.org; Sun, 26 Feb 2006 23:38:45 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1QNc1lr001445; Sun, 26 Feb 2006 23:38:01 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 k1QNa5K1017946 for ; Sun, 26 Feb 2006 23:36:05 GMT Received: from dogmatix.willow.local ([192.168.0.100] helo=dogmatix) by getafix.willow.local with smtp (Exim 4.54) id 1FDVQl-0004Iz-1w for gentoo-dev@lists.gentoo.org; Sun, 26 Feb 2006 23:36:05 +0000 Received: by dogmatix (sSMTP sendmail emulation); Sun, 26 Feb 2006 23:35:58 +0000 From: johnm@gentoo.org Date: Sun, 26 Feb 2006 23:35:58 +0000 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] QA Team's role Message-ID: <20060226233558.GD11930@dogmatix.willow.local> References: <20060226222217.GB17257@aerie.halcy0n.com> <20060226231121.GB11930@dogmatix.willow.local> <20060226232147.37349bc2@snowdrop.home> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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="orO6xySwJI16pVnm" Content-Disposition: inline In-Reply-To: <20060226232147.37349bc2@snowdrop.home> User-Agent: Mutt/1.5.11 X-Spam-Score: -0.9 (/) X-Archives-Salt: c49ba38f-39e2-4e7d-a10a-35a99283fed1 X-Archives-Hash: 74b901142b88341dcf41584357e271aa --orO6xySwJI16pVnm Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 26, 2006 at 11:21:47PM +0000, Ciaran McCreesh wrote: > On Sun, 26 Feb 2006 23:11:21 +0000 johnm@gentoo.org wrote: > | On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser > | 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. > |=20 > | 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. >=20 > The problem is... It's impossible to document every single way in which > someone can screw up. For example, I wouldn't've thought to document > "you should not run mkdir in global scope", because I didn't think > anyone would be daft enough to do it. Policy *has* to rely upon the > basic assumption that developers won't do something crazy. yeah, thats totally understandable. Its a best-efforts thing. I just don't want neccessary to be deemed true for something which has an arguable point with technical merit. Blatent mkdir-esque madness would be more black than white, and I'd hope for this to try and sanitise the gray :) > | > * In the case of disagreement on policy among QA members, the > | > majority of established QA members must agree with the action. > |=20 > | Perhaps pushing it to an open forum on -dev/-core for consensus works > | better here? >=20 > The problem with that is, it usually ends up with too many pointless > comments from people saying how things could be fixed in the distant > future, or whining that it isn't explicitly forbidden by policy on > situations where the screwup was too weird to be documented previously. This is very much a case-by-case thing. I still feel the debate should be better answered outside of conflicting qa members. > | > * Just because a particular QA violation has yet to cause an issue > | > does not change the fact that it is still a QA violation. > |=20 > | 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. >=20 > This is to cover for situations where people claim that their screwups > are ok because no-one has yet reported it as broken. I guess that also falls under the first point, based on the quality or vagueness of the documention :) - 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 --orO6xySwJI16pVnm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEAjteNzVYcyGvtWURAs7tAKDYaSApxzA9Ad//ZzJ/JMYtd2H1kwCeOaXn NnYGc92U7GEv3ab5R9HAwVE= =og8Y -----END PGP SIGNATURE----- --orO6xySwJI16pVnm-- -- gentoo-dev@gentoo.org mailing list