From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-64538-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 635F1138247
for <garchives@archives.gentoo.org>; Wed, 22 Jan 2014 19:42:22 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id A2D85E09FD;
Wed, 22 Jan 2014 19:42:16 +0000 (UTC)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174])
(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id BB67CE0999
for <gentoo-dev@lists.gentoo.org>; Wed, 22 Jan 2014 19:42:15 +0000 (UTC)
Received: by mail-ig0-f174.google.com with SMTP id hl1so14847962igb.1
for <gentoo-dev@lists.gentoo.org>; Wed, 22 Jan 2014 11:42:15 -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=198G4n6XgJcaVN+WQ1N6WqSwI1ol1rMAbjLsmqVuN44=;
b=A8ZCRDihfrgHRd9eixXJDUce5p1Eexc3ACLyiXSMtgqXzOrDmNOR7CRRr4eQ3r1MWT
zKnjo45acC9fbZ6+79p4cE8ciJ5ESJoN8NeRdTFlsPiZJ5NDMV/dhLPPB3ySp0mDcj2/
ZvAgjFATCBKKhjKL3P8hvw/nJLv3Oro+P/bednfiH/C7LMNv5fTv/ff/BEtFrpBw/yHa
k36XgWObILXY/fZ8jgCvXi/WQ649Mk6lgpeLw9TyAdDpGlQieA6yOqEwWvgp67fJRt5l
Y8OWM9yAx75QXLfHH7g7GyWiErukCOKsgdwE4n2D8NBzbpvdvOqLVUK02ppO9Uxjrv8U
lrig==
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
X-Received: by 10.50.61.232 with SMTP id t8mr4859909igr.32.1390419735055; Wed,
22 Jan 2014 11:42:15 -0800 (PST)
Sender: freemanrich@gmail.com
Received: by 10.64.73.99 with HTTP; Wed, 22 Jan 2014 11:42:14 -0800 (PST)
In-Reply-To: <52DFBABD.8090102@gentoo.org>
References: <20140119050224.GA7898@laptop.home>
<CAAr7Pr-1GsHbL5zzyS5u-N8QsR+Qf-tKev2N-O4k94AgWHY8_A@mail.gmail.com>
<20140120035446.063a31be@TOMWIJ-GENTOO>
<CAGfcS_mZof7ni67U_ob2DWiXBqvs8DLrx_1ar7e7avXQ6Vq-uA@mail.gmail.com>
<52DD2E2A.2020303@gmail.com>
<20140121155616.6a8cdf9b@TOMWIJ-GENTOO>
<52DF6C7E.8020908@gmail.com>
<52DFBABD.8090102@gentoo.org>
Date: Wed, 22 Jan 2014 14:42:14 -0500
X-Google-Sender-Auth: WOOHS7Aygbw1F6I6UAtMFWo4ngU
Message-ID: <CAGfcS_ke5e1_TyRBGmf+FAcobH5JrUfHXzgL10oBL6-nF8N9+A@mail.gmail.com>
Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Archives-Salt: 035e33aa-9fdd-43f3-9cc2-73a17039170c
X-Archives-Hash: ef655f13605b83c4900307a18c3cde4e
On Wed, Jan 22, 2014 at 7:34 AM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 01/22/2014 03:00 PM, Alan McKinnon wrote:
>> I don't want to appear rude, but when reading this entire mail all I see
>> is someone who has probably never had to do it for real.
>>
>> People are not machines. Volunteers really do not like having their
>> freely given time nullified and access removed because one person
>> thought it was deserved.
>
> Well ...
>
> if these persons actively break things, and endanger others, *and* they
> don't respond to multiple verbal warnings/threats ...
>
> ... what would you do?
So, this was what I was trying to get at in my email. I see a couple
of different models being thrown around and they really differ on the
guidelines as to how QA would apply the power to suspend devs.
One scenario that came up is the runaway script. Some dev is doing
something that is going to create a lot of work to fix and it gets
noticed. QA can't quickly ping them, so they suspend access to halt
the damage. Presumably they then fire off an email saying, "hey, I
noticed your script was doing foo and suspended your access to halt it
until we talk about it - let me know when you've terminated your
scripts and I'll get your access reinstated - ping me when you get a
chance."
That's very different from the scenario you're suggesting, which
amounts to deliberate ignoring of warnings and thus they require a
semi-permanent ban that might become permanent.
The first scenario could happen to the best of us. The second
shouldn't. The first is purely a technical solution to a technical
problem. The second is a people problem, being mitigated with a
technical solution. A ban might be inevitable, but what should the
process be?
Has the QA team discussed this internally and come to some kind of
consensus about just what they want their role to actually be? I can
see an argument being made for many different possible roles. What I
really am most concerned about is understanding just what the role of
QA is and how the way we do QA accomplishes as much as possible with
the least burnout for all impacted. I'm all for policy changes in
support of this, but I'd rather see us hash out how we want to make it
work and turn it into policy and not create a policy and then figure
out how to make it work.
Rich