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 D8B5C138247 for ; Tue, 21 Jan 2014 05:27:36 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E9521E0E4C; Tue, 21 Jan 2014 05:27:30 +0000 (UTC) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E875CE0E47 for ; Tue, 21 Jan 2014 05:27:29 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ij19so3233526vcb.6 for ; Mon, 20 Jan 2014 21:27:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Oa1pPXtD+E0lgxz2RSH57TpLwredcowhgs3rg6P4qPc=; b=mJ6KbFlOPoAteWcREL5glJWwoUcWEd0VbljrfnHmdH4SRSeg9biMsc/wGfTxqdKN+O 3frdNYT7i5q7mKWHSO2t9TG+3ddDpmGSUYDRqJIbqUkHAeRKtCMPr+iZKSHvjGvRUkuz RvqAuQnw0ODUrn8d3PHd69Mwq6goqEgSTqB/tsPoMumGgVKYCFfNzG+Wj5HILauazmt0 NeDaBarjHfKlzNrGFOegcEi2V52cKt6gPhOg9UXjW3bxseinowFdHRHALgSaJ7yaP0CY dVBjctdqlwfP4jpRc9Ihkvu81bKavH0B38Bpnd4Z6La3fUlrftAs1KzlAq5KSl65vAh8 9ovQ== X-Gm-Message-State: ALoCoQnC7CZzsVNRaLsJlgdQsr046araQkXFf0pR1Ac5VlKT+Bacwj1Y0VkPW6FSkW6CdjWsNgzF 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.221.20.199 with SMTP id qp7mr2371321vcb.24.1390282049054; Mon, 20 Jan 2014 21:27:29 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.220.59.71 with HTTP; Mon, 20 Jan 2014 21:27:28 -0800 (PST) X-Originating-IP: [173.8.165.226] In-Reply-To: <52DDBDBF.1020206@gentoo.org> References: <20140119050224.GA7898@laptop.home> <20140120035446.063a31be@TOMWIJ-GENTOO> <52DD2E2A.2020303@gmail.com> <52DDBDBF.1020206@gentoo.org> Date: Mon, 20 Jan 2014 21:27:28 -0800 X-Google-Sender-Auth: 6O7D-8ydpbmbKgVv7XwUxOQgi5U Message-ID: Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights From: Alec Warner To: Gentoo Dev Content-Type: multipart/alternative; boundary=001a11339e2eabfc9004f07443ba X-Archives-Salt: 35da2032-9171-4bbc-a15b-b9aab42392ca X-Archives-Hash: bb4f3fcc084729676d6783e46cc3b199 --001a11339e2eabfc9004f07443ba Content-Type: text/plain; charset=UTF-8 On Mon, Jan 20, 2014 at 4:22 PM, Patrick Lauer wrote: > On 01/20/2014 10:09 PM, Alan McKinnon wrote: > > On 01/20/14 15:59, Rich Freeman wrote: > >> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman wrote: > >>> #gentoo-qa | @hwoarang: pretty sure diego had the powerzz to > suspend > >>> people > >>> > >>> Whether this has actually happened is something that is questionable; > >> > >> Not that this necessarily needs to make it into the GLEP, and I'm > >> still on the fence regarding whether we really need to make this > >> change at all, but things like access suspensions and other > >> administrative/disciplinary procedures should be documented. I think > >> whether this is a matter of public record or not is open to debate, > >> but I don't like the fact that we can really say for sure when/if this > >> has actually happened. > > > > > > Speaking as someone who had this power in his day job, for QA to be able > > to suspend accounts is a very bad idea indeed. It always ends badly. I > > suspended 20+ accounts in my current job over the years and the number > > of cases where it was the right thing to do is precisely 0. > > I've been in positions where such powers were not granted, it's worse. > > All you can do is send strongly-worded letters and undo, then wait for > the same thing to be tried again, while telling damagement that this > situation is not good. > > > > > It was always a case of ill-advised action taken out of frustration, or > > bypass the training step, or don't try hard enough to reach the > > "infringer" and communicate like grown adults. Yup, I did all three. > > Some people need more direct clues, and since violence in the workplace > is usually disallowed ... > > > Suspending an account is a very serious thing to undertake, the effects > > on the suspended person are vast and this power should never lie with > > the person who is feeling the pain. Instead, there are well established > > channels to the body who can make the decision. If QA has a problem with > > a dev for any reason whatsoever, then QA should make a well-thought out > > case to that other body for decision. Anything else is madness and open > > invitation for it to all go south. > > > It's a serious thing, so it should have some consequences. > > I'm mildly amused how everyone wants strong QA, but as soon as QA tries > to actually *do* something it's bad, and overstepping their boundaries, > and NIMBY. > > Yey, we're allowed to sometimes do revert games, if we're asking nicely > ... and the only way to stop the revert game is for QA to stand down. > We're allowed to send strongly-worded emails, but getting things baked > into policy is too radical. > I think you are framing the argument incorrectly. I'm not suggesting that QA team not have any powers, but that the powers you are asking for are perhaps, not so great. If someone is making tree changes, and they are breaking the tree, and you fix it (using your QA powers to fix it.) Then they revert it. I don't think the proper solution is for QA and a dev to get into a revert war until QA exercises their power to revoke the devs commit access. Simply file a bug and have the developer reprimanded for violating policy. > > And the biggest "flamewar" so far was about cosmetic issues. > Y'know, if I get around to it I'll try to work towards making most of > these warnings fatal, then you can't accidentally add such things. > (And people not using repoman will have some extra fun!) > > Have fun, > > Patrick > > > > --001a11339e2eabfc9004f07443ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 20, 2014 at 4:22 PM, Patrick Lauer <patrick@gentoo.org> wrote:
On 01/20/2014 10:09 PM, Al= an McKinnon wrote:
> On 01/20/14 15:59, Rich Freeman wrote:
>> On Sun, Jan 19, 2014 at 9:54 PM, Tom Wijsman <TomWij@gentoo.org> wrote:
>>> =C2=A0 =C2=A0 #gentoo-qa | @hwoarang: pretty sure diego had th= e powerzz to suspend
>>> =C2=A0 =C2=A0 people
>>>
>>> Whether this has actually happened is something that is questi= onable;
>>
>> Not that this necessarily needs to make it into the GLEP, and I= 9;m
>> still on the fence regarding whether we really need to make this >> change at all, but things like access suspensions and other
>> administrative/disciplinary procedures should be documented. =C2= =A0I think
>> whether this is a matter of public record or not is open to debate= ,
>> but I don't like the fact that we can really say for sure when= /if this
>> has actually happened.
>
>
> Speaking as someone who had this power in his day job, for QA to be ab= le
> to suspend accounts is a very bad idea indeed. It always ends badly. I=
> suspended 20+ accounts in my current job over the years and the number=
> of cases where it was the right thing to do is precisely 0.

I've been in positions where such powers were not granted, it'= ;s worse.

All you can do is send strongly-worded letters and undo, then wait for
the same thing to be tried again, while telling damagement that this
situation is not good.

>
> It was always a case of ill-advised action taken out of frustration, o= r
> bypass the training step, or don't try hard enough to reach the > "infringer" and communicate like grown adults. Yup, I did al= l three.

Some people need more direct clues, and since violence in the workpla= ce
is usually disallowed ...

> Suspending an account is a very serious thing to undertake, the effect= s
> on the suspended person are vast and this power should never lie with<= br> > the person who is feeling the pain. Instead, there are well establishe= d
> channels to the body who can make the decision. If QA has a problem wi= th
> a dev for any reason whatsoever, then QA should make a well-thought ou= t
> case to that other body for decision. Anything else is madness and ope= n
> invitation for it to all go south.
>
It's a serious thing, so it should have some consequences.

I'm mildly amused how everyone wants strong QA, but as soon as QA tries=
to actually *do* something it's bad, and overstepping their boundaries,=
and NIMBY.

Yey, we're allowed to sometimes do revert games, if we're asking ni= cely
... and the only way to stop the revert game is for QA to stand down.
We're allowed to send strongly-worded emails, but getting things baked<= br> into policy is too radical.

I think you= are framing the argument incorrectly. I'm not suggesting that QA team = not have any powers, but that the powers you are asking for are perhaps, no= t so great.

If someone is making tree changes, and they are breakin= g the tree, and you fix it (using your QA powers to fix it.) Then they reve= rt it. I don't think the proper solution is for QA and a dev to get int= o a revert war until QA exercises their power to revoke the devs commit acc= ess.

Simply file a bug and have the developer reprimanded fo= r violating policy.

=C2=A0

And the biggest "flamewar" so far was about cosmetic issues.
Y'know, if I get around to it I'll try to work towards making most = of
these warnings fatal, then you can't accidentally add such things.
(And people not using repoman will have some extra fun!)

Have fun,

Patrick




--001a11339e2eabfc9004f07443ba--