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 1FDnk0-0006HM-I7 for garchives@archives.gentoo.org; Mon, 27 Feb 2006 19:09:04 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id k1RJ8IpC026936; Mon, 27 Feb 2006 19:08:18 GMT Received: from aerie.halcy0n.com ([65.98.89.194]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id k1RJ6Kk3030031 for ; Mon, 27 Feb 2006 19:06:23 GMT Received: from localhost (localhost [127.0.0.1]) by aerie.halcy0n.com (Postfix) with ESMTP id 21CBF7E964 for ; Mon, 27 Feb 2006 14:06:20 -0500 (EST) Received: from aerie.halcy0n.com ([127.0.0.1]) by localhost (halcy0n.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 15140-08 for ; Mon, 27 Feb 2006 14:05:50 -0500 (EST) Received: by aerie.halcy0n.com (Postfix, from userid 1000) id C9E2F7EA02; Mon, 27 Feb 2006 14:05:50 -0500 (EST) Date: Mon, 27 Feb 2006 14:05:50 -0500 From: Mark Loeser To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [RFC] QA Team's role Message-ID: <20060227190550.GA15442@aerie.halcy0n.com> References: <20060226222217.GB17257@aerie.halcy0n.com> <44033F86.7060805@gentoo.org> 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="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <44033F86.7060805@gentoo.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at halcy0n.com X-Archives-Salt: df34fcd0-20b1-485e-8457-68ff25e7e58e X-Archives-Hash: 3f6a884eb54ea9c65f25c3e29a70d841 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=utf8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Grant Goodyear said: > 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. >=20 > 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. We hope that it is never the case when someone refuses to cooperate, but it is a possible situation we may likely have to deal with at some point. > > * 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. >=20 > 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. I agree. With regards to the nxserver case, we said the package should be removed if we could not come to a resolution. We never said that we were going to outright remove the package immediately. It is not our goal, nor our intent, to go around and remove people's packag= es =66rom the tree. This entire bullet point is really a worst case scenario = when all else breaks down. The same with if there is a disagreement within the majority of the QA team. I don't foresee this occuring often, if at all, but I felt it was important enough to address. --=20 Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEA02OCRZPokWLroQRAh9kAKCzix8/0geGT5ztAHNCUXS4S/Zr3QCgmlsR RXzUBPwxNPnAtcCDjlkjxI0= =iUnO -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- -- gentoo-dev@gentoo.org mailing list