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 1FDmo0-000493-Gu for garchives@archives.gentoo.org; Mon, 27 Feb 2006 18:09:08 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1RI85RW016261; Mon, 27 Feb 2006 18:08:05 GMT Received: from smtp109.sbc.mail.re2.yahoo.com (smtp109.sbc.mail.re2.yahoo.com [68.142.229.96]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1RI64E5027926 for <gentoo-dev@lists.gentoo.org>; Mon, 27 Feb 2006 18:06:05 GMT Received: (qmail 3760 invoked from network); 27 Feb 2006 18:06:03 -0000 Received: from unknown (HELO server.grantgoodyear.org) (s?robertson@sbcglobal.net@67.67.81.246 with plain) by smtp109.sbc.mail.re2.yahoo.com with SMTP; 27 Feb 2006 18:06:03 -0000 Received: from [64.76.20.1] (dst [192.168.1.3]) (authenticated bits=0) by server.grantgoodyear.org (8.13.4/8.13.4) with ESMTP id k1RI62Fi002666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <gentoo-dev@lists.gentoo.org>; Mon, 27 Feb 2006 12:06:03 -0600 Message-ID: <44033F86.7060805@gentoo.org> Date: Mon, 27 Feb 2006 12:05:58 -0600 From: Grant Goodyear <g2boojum@gentoo.org> User-Agent: Thunderbird 1.5 (Windows/20051201) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] QA Team's role References: <20060226222217.GB17257@aerie.halcy0n.com> In-Reply-To: <20060226222217.GB17257@aerie.halcy0n.com> X-Enigmail-Version: 0.94.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF93A4F330B2661BE6B467D2E" X-Archives-Salt: 8f7a1df7-5baa-4589-ae58-c52a8282212a X-Archives-Hash: dc9cb1792048b248eef4fb7bced55bba This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF93A4F330B2661BE6B467D2E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark Loeser wrote: > * In case of emergency, or if package maintainers refuse to cooperate, > the QA team may take action themselves to fix the problem. My suspicion is that the more common problem is going to be inaccessible developers, rather than uncooperative ones. Certainly, if a maintainer cannot be contacted, then I would prefer that QA fix the problem rather than let it languish. So, yes, I do believe that QA needs the ability to go in and change any package that is broken. (It's worth noting, though, that every dev w/ tree access already has that ability, and the only real issue is the amount of pain that will be inflicted on a dev who changes packages both without permission and without skill. Very few devs will complain about somebody improving packages even without permission as long as the improvement is done well.) > * 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= =2E The > package should be dealt with per QA's request until such a time that = a > decision is made by the council. I'm somewhat ambivalent on this one on a couple of points, and the nxserver case (bug #123926) hits both of them. The first is that it seems to me that in a case like this one, where the package involved is a minor one that (I think) is not a dependency of any other packages, the most that QA should do is hard mask the package w/ a clear note pointing to the bug report, until some sort of resolution is achieved. Removing the package would seem to be a bit much. The second is the fact that I don't really like seeing policy bounced to the council unless absolutely necessary. Just as was seen here, a discussion on -dev might well lead to a reasonable compromise. If it doesn't, then the council can get involved. Of course, that leaves the question of who decides on the severity of a QA violation? Well, I would suggest that the QA team does, at the risk of getting publicly smacked down if they choose poorly. -g2boojum- --------------enigF93A4F330B2661BE6B467D2E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEAz+KptxxUuD2W3YRAiVmAJ4gm6KEUCjh44HPZ0moNN1DVv5jnQCcDJE/ gzErVbk+42HKMkCg92aUDRw= =eyyw -----END PGP SIGNATURE----- --------------enigF93A4F330B2661BE6B467D2E-- -- gentoo-dev@gentoo.org mailing list