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 92C74138247 for ; Tue, 21 Jan 2014 15:47:58 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 71A8CE0EFE; Tue, 21 Jan 2014 15:47:52 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8B072E0EF7 for ; Tue, 21 Jan 2014 15:47:51 +0000 (UTC) Received: by mail-ig0-f173.google.com with SMTP id c10so11191784igq.0 for ; Tue, 21 Jan 2014 07:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=mSS/f5o9zxqvnQg7XGwyz2C1Z2sOnxg+jKaMsR2DIu4=; b=lqvKenes4o0Pn/3KCKaFfCi9+qgoYFgvQ9JD57x4+FRhH3YMJGESW5rgyvrCsw20nP OQU52btDNoZU8qOm0XUholFOkUOgmYqHdOyiIBQ6V13+pvdrUKOWbM98EobKpJV98Udi 3xHkJyVHnAwduHPvUTnNC0oWZ8vgTpu6WnDiTl+yyLFNyhCT8851HrZT7Jkv7SrJSJmH 03h+GnrZ2I3bAiEUqweKRBteE0U7925vkXDsE0LelBXuku4b1CvHw/+vZgOeXL1D0ijO sG8y+/bOk/dh0DZiCvP/dPz5kFJQL5rvQKo7eyq2YCDkh0sYbo8qcy1hhwld3UtMvT30 Tjsg== 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 X-Received: by 10.43.140.77 with SMTP id iz13mr6963376icc.47.1390319270942; Tue, 21 Jan 2014 07:47:50 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.73.99 with HTTP; Tue, 21 Jan 2014 07:47:50 -0800 (PST) In-Reply-To: <20140121155616.6a8cdf9b@TOMWIJ-GENTOO> References: <20140119050224.GA7898@laptop.home> <20140120035446.063a31be@TOMWIJ-GENTOO> <52DD2E2A.2020303@gmail.com> <20140121155616.6a8cdf9b@TOMWIJ-GENTOO> Date: Tue, 21 Jan 2014 10:47:50 -0500 X-Google-Sender-Auth: BFfT9wMGujBqhS1HkTOI2lpEde8 Message-ID: Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=ISO-8859-1 X-Archives-Salt: 2a7eaa5c-96fb-4e15-8807-f52cc74c5745 X-Archives-Hash: d0221edfba6b911f343abf375e5b0f45 On Tue, Jan 21, 2014 at 9:56 AM, Tom Wijsman wrote: > If a developer does an unannounced mass action that breaks the tree > severely or is heavily prohibited by policy, is unreachable while he > continues to commit this; then it would be handy to "temporarily" be > able to withdraw the commit access to bring it to that developer's > attention. Hadn't really thought about it in this light. In this situation restricting commit access is being used as a technical solution to a technical problem - not unlike killing a runaway process. I have no issues at all with QA taking action in a manner like this, though unless that mass-update is really slow I doubt we'd ever react in time. What I don't like is the idea of QA taking what amounts to punitive measures. I think that this is a role best held by Comrel. I do appreciate Markos's comments regarding Comrel not being the right solution to a technical problem. I do not see Comrel has having a role in mediating a dispute between QA and a developer over the correctness of policy or its enforcement (personal conflicts are a different matter as Markos acknowledges). What I do see Comrel has having a role in is a developer who simply refuses to follow policy - whether that is CoC, technical policy, or whatever. In the case of CoC Cevrel is judge, jury, and executive (that is, they determine whether it was violated in addition to dealing with the fact that it was). In the case of a QA issue QA is the jury (they determine if the policy was violated), and Comrel is the judge and executive (they determine how to get the dev to go along with policy or get rid of them). If Comrel really objects to this I'm not entirely opposed to letting QA have the reins (certainly we can't just let policy go unenforced entirely). However, I would encourage the teams to give some thought as to whether it makes sense to work together to separate the human vs technical factors here. This discussion has been helpful... Rich