From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4D77E138A1F for ; Fri, 31 Jan 2014 15:20:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2A7E3E09FD; Fri, 31 Jan 2014 15:20:47 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 37AB4E09C4 for ; Fri, 31 Jan 2014 15:20:46 +0000 (UTC) Received: from [172.27.98.219] (unknown [137.54.4.154]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: creffett) by smtp.gentoo.org (Postfix) with ESMTPSA id 599E033D8F2 for ; Fri, 31 Jan 2014 15:20:45 +0000 (UTC) Message-ID: <52EBBF48.8080209@gentoo.org> Date: Fri, 31 Jan 2014 10:20:40 -0500 From: Chris Reffett User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] January 2014 QA Policy Updates References: <52E9E755.4030107@gentoo.org> <20140131054838.3241.qmail@stuge.se> <52E9E755.4030107@gentoo.org> <20140131054838.3241.qmail@stuge.se> <20140131140727.10562.qmail@stuge.se> In-Reply-To: <20140131140727.10562.qmail@stuge.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: e41d0bd5-61c6-4120-808f-66e77e3c43de X-Archives-Hash: 5ea2a1da1d63631ca944dbbe45c972cc -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/31/2014 09:07 AM, Peter Stuge wrote: > Alec Warner wrote: >>> hmm? >> >> To be fair, I had a long discussion with this regarding when QA >> has the authority to temporarily ban a developer. > > Cool. > > >> In the case where policy is missing, QA does not have a clear >> case of authority there. It becomes a more murky area. I've tried >> to very much encourage QA to both publish the policies they want >> to enforce, and automate enforcement with better tooling (repoman >> or otherwise). Being transparent and consistent in enforcement >> of policy goes a long way for getting developers on your side. > > Absolutely. > > >> So in short, while one could read that passage as you did, I >> don't think that is their intention. > > To be clear, I don't think so either. > > > Rich Freeman wrote: >> I was really happy to see a public notice of meeting and a >> published summary. > > Yes, me too! > > > I still think it seems like QA could essentially introduce > arbitrary new policies and 2 weeks later be expected to effect > them. > > Fine when everyone agrees. Not so much at other times. The > responsibility is with QA to build support among the developers, > and I agree that the transparency goes a long way! > > > //Peter > Regarding the question in your first email: We will not create a policy then immeiately use the policy as justification to to go edit packages. The intention of the "we may ask the developer to stop" line is for cases where we suspect that what the developer is doing is causing a problem and would like to discuss it further. I feel that that is well within the bounds of GLEP 48. As for the "when/how we make and communicate fixes," I think that just about any policy we make will fall into the middle ground you omitted of "file a bug, wait 2 weeks, fix." So no, we will not be making arbitrary fixes just because we can. Regarding your concern about us introducing arbitrary policies: again, most will fall into the "file a bug" middle ground. We also are perfectly aware that you can't expect people to change overnight, and we will not be shouting at devs just because they didn't implement $(new-policy) right away. We will file bugs asking for changes, and we will try to offer suggestions or patches wherever possible to make it easier for maintainers. Chris Reffett Gentoo QA Lead -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iKYEARECAGYFAlLrv0hfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl bnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2NzU5RjUyMDczREJDQkVDQTBDRkE1NERC Nzk1QThBNDI2MTgzNTQACgkQ23laikJhg1QZ+wCeJre5n44E9BdZcUBgZdC5DjPe WR8AoJ1W9QuqVIFXxsVAWBO23yx+etak =5CIT -----END PGP SIGNATURE-----