From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1PjpUz-00087F-IS for garchives@archives.gentoo.org; Mon, 31 Jan 2011 08:52:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A83FD1C03D; Mon, 31 Jan 2011 08:52:28 +0000 (UTC) Received: from mail-fx0-f53.google.com (mail-fx0-f53.google.com [209.85.161.53]) by pigeon.gentoo.org (Postfix) with ESMTP id D5FB31C019 for ; Mon, 31 Jan 2011 08:52:03 +0000 (UTC) Received: by fxm11 with SMTP id 11so6527206fxm.40 for ; Mon, 31 Jan 2011 00:52:03 -0800 (PST) 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 Received: by 10.223.100.8 with SMTP id w8mr1045153fan.55.1296463923027; Mon, 31 Jan 2011 00:52:03 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.223.78.202 with HTTP; Mon, 31 Jan 2011 00:52:02 -0800 (PST) In-Reply-To: <4D466F6D.1080907@gentoo.org> References: <4D433102.3060804@gentoo.org> <20110131060456.643d0dd5@epia.jer-c2.orkz.net> <4D466F6D.1080907@gentoo.org> Date: Mon, 31 Jan 2011 00:52:02 -0800 X-Google-Sender-Auth: TKIJnQs30xnTC3wGcQNy_VTa_Co Message-ID: Subject: Re: [gentoo-dev] Glep 48 update (as nominated for next meeting) From: Alec Warner To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: f4f96b0c92d8909ce486dcb3d2b5f254 I'm going to basically reply with my normal QA rant. 1) QA is important to the overall health of Gentoo. People will not use broken shit. 2) QA should be straightforward. If a developer need to do X to assure quality it should be fairly obvious why X is required. It should be clear where to go for help. 2a) A developer should not get chewed out for asking for assistance or questioning policies. 3) If a QA policy is not straightforward; developers will not follow it. 4) QA should not be a road-block to most developers. If you make development harder people will often stop working on development. I think a number of developers understand why QA exists, why they should test packages, run repoman, and other policies that often get followed. Examining policies that are ignored will likely lead to a lack of understanding, documentation, or just bloat in policy. In general I hate talking about 'bad' QA versus 'good' QA because no one on the QA team ever talked about measurement. QA is 'bad' when some new person heads up the team and (s)he is going to 'clean up QA' by instituting these new policies. None of the policies have any kind of measurement attached so there is no real way to see if the new policies are effective. Perhaps this sort of thing is 'too corporate' and not possible in a volunteer project (I happen to think otherwise.) -A On Mon, Jan 31, 2011 at 12:14 AM, Petteri R=C3=A4ty = wrote: > On 01/31/2011 07:04 AM, Jeroen Roovers wrote: >> >>> 2. =C2=A0I don't think it makes sense for QA to discipline developers >>> permanently in these cases. =C2=A0They should suspend access pending De= vrel >>> resolution of the issue. =C2=A0Devrel should of course strongly conside= r >>> the input of QA. >> >> That should be anyone's input, really. If a Gentoo Linux user finds a >> nasty `rm -rf /' timebomb, I suppose he could point that out to infra >> directly. And it's infra that suspends access, by the way. And devrel >> should be the intermediate between developers. And QA "aims to keep the >> portage tree in a consistent state"[1]. Wait, everyone is already in >> place? >> > > Actually recruiters can also suspend commit access and DevRel lead has > used that to safe guard the tree in the past. > > Regards, > Petteri > >