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 1EFPNP-00064c-Do for garchives@archives.gentoo.org; Wed, 14 Sep 2005 05:00:07 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j8E4skCB007796; Wed, 14 Sep 2005 04:54:46 GMT Received: from outbound4.mail.tds.net (outbound4.mail.tds.net [216.170.230.94]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j8E4r753000871 for ; Wed, 14 Sep 2005 04:53:08 GMT Received: from outaamta02.mail.tds.net (outaamta02.mail.tds.net [216.170.230.32]) by outbound4.mail.tds.net (8.13.4/8.12.2) with ESMTP id j8E4vhOf019735 for ; Tue, 13 Sep 2005 23:57:43 -0500 (CDT) Received: from cerberus.oppresses.us ([69.21.249.129]) by outaamta02.mail.tds.net with ESMTP id <20050914045743.NQDM30338.outaamta02.mail.tds.net@cerberus.oppresses.us> for ; Tue, 13 Sep 2005 23:57:43 -0500 Received: by cerberus.oppresses.us (Postfix, from userid 500) id 813924ABFB; Wed, 14 Sep 2005 00:57:40 -0400 (EDT) Date: Wed, 14 Sep 2005 00:57:40 -0400 From: Jon Portnoy To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC Message-ID: <20050914045740.GA4006@cerberus.oppresses.us> 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> <4327A1B5.6040203@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: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4327A1B5.6040203@gentoo.org> User-Agent: Mutt/1.5.8i X-Archives-Salt: 4e8d6664-830f-4ec5-b670-d2a6865fd7d6 X-Archives-Hash: b9775085c342a234ecf58791297ff370 On Wed, Sep 14, 2005 at 12:06:13AM -0400, Curtis Napier wrote: > 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). The other thing that'd fix the 'devrel takes so long' problem would be if people would let devrel fix its resolution policies 8) (see recent -devrel ml thread) > > 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? > QA and devrel have two different jobs. QA doesn't have to be devrel's problem and devrel tasks don't have to be QA's problem (how much do the QA folks really want to deal with the usual bitchfest when somebody with a lot of friends gets suspended for something?) if they work together on repeated problem developers. > 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. > Does Saturn's stop button also kick the apparently responsible individual out of the building? Otherwise this analogy would work better if applied to ebuilds and the maintainership thereof, not developers and their CVS access. (And on another note, Saturn? Known for quality? Bwahahahah... err. :) ) -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list