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.43) id 1EFOcG-0003yd-9N for garchives@archives.gentoo.org; Wed, 14 Sep 2005 04:11:25 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j8E45m0g013150; Wed, 14 Sep 2005 04:05:48 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j8E41Zl0027585 for ; Wed, 14 Sep 2005 04:01:35 GMT Received: from smtp109.sbc.mail.re2.yahoo.com ([68.142.229.96]) by smtp.gentoo.org with smtp (Exim 4.43) id 1EFOXH-0006kD-7y for gentoo-dev@lists.gentoo.org; Wed, 14 Sep 2005 04:06:15 +0000 Received: (qmail 23235 invoked from network); 14 Sep 2005 04:06:15 -0000 Received: from unknown (HELO ?192.168.1.4?) (curtis119@sbcglobal.net@69.221.3.79 with plain) by smtp109.sbc.mail.re2.yahoo.com with SMTP; 14 Sep 2005 04:06:15 -0000 Message-ID: <4327A1B5.6040203@gentoo.org> Date: Wed, 14 Sep 2005 00:06:13 -0400 From: Curtis Napier Organization: Gentoo Linux User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050804) X-Accept-Language: en-us, en 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC References: <4325D12A.5050601@gentoo.org> <200509131702.45512.vapier@gentoo.org> <43275620.3060501@gentoo.org> <200509131906.08912.vapier@gentoo.org> <4327613B.80409@gentoo.org> <432764D3.9050106@gentoo.org> In-Reply-To: <432764D3.9050106@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Archives-Salt: 550c5ebf-dd08-4ff3-928b-20edaf0e2f75 X-Archives-Hash: 39326eb15915f0fdb5a04d133ebca93e Lance Albertson wrote: snip ... > I tend to agree with Donnie on this partially. Devrel's main focus isn't > the QA of the tree, its dealing with developers. QA should have the > authority to limit access to the tree if someone isn't following the > guidelines properly. They are the ones with the technical know how to > make the judgment on that. Obviously, they will need to come up with > guidelines if someone does make a goof up. Give them some probationary > time, maybe make them take the quiz again to improve their ebuild > skills. I just don't think devrel is the right place for that kind of > authority. > I'm not an ebuild dev so I may not know enough about this situation to competantly comment on it but it seems to me that QA should have some sort of limited ability to "temporarily" take away write access to the tree until devrel has a chance to look over the evidence and come to a decision. This would fix the problem of "devrel takes to long" plus it would really help to ensure higher quality work is submitted (because ebuild devs WILL stop purposely commiting bad work if they know a QA team member can take away their write access at a moments notice for repeated violations). As Lance said in an earlier post, infra already does this "temporary removal of access" if it is an immediate security threat and then submits the evidence to devrel for followup. Why can't it work exactly the same for the QA team? If they have done their due diligence by contacting the dev in question, pointing out their mistakes and offering assistance to correct the mistakes and the dev just keeps right on commiting bad stuff QA should be able to "temporarily" stop them until devrel has a chance to follow up and investigate. That's what QA is, Quality Assurance, if they have no power to actually "Assure Quality" then why does this team even exist? I'll give an example: Saturn car company has a great big red "STOP" button at every point in the assembly line that can turn off the entire manufacturing line if QA spots a mistake. The QA team does not have to ask anyone first, they simply push the button so the low quality car does not get through, remove the offending car from the line "temporarily" until a team investigates and decides if the quality is good enough to put it back on the assembly line. Saturn is known for the quality of it's cars because of this. The gentoo QA team should have this same ability. -- gentoo-dev@gentoo.org mailing list