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 F1F46138247 for ; Tue, 21 Jan 2014 05:29:40 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4E993E0E61; Tue, 21 Jan 2014 05:29:36 +0000 (UTC) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5DF31E0E54 for ; Tue, 21 Jan 2014 05:29:35 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id pa12so1315798veb.19 for ; Mon, 20 Jan 2014 21:29:34 -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=u9AX9WIgjb4PQNkYuX5vzY4KBQ9r3EsvLi8bnKmQoXo=; b=FWRnHfo8QWCodVoyX3KZQkn07YVHS5rbAZuADFwUCKdoHPOLJ5tFJOrvqZJf5gqHZI NofQyKB23v7OJzu2Lcsyu+58EgZQV/gNUPJVLxRUOQeId+vwGALAfbqmiRFHGxkp/OgI xIBgXvPQu8wrDC1zfpyZNUc/t2hkw0ccPFn/RQtjtRBTDTmXU3Ohei0s9ByM5Lq3W02T Q0/TGsL2WOezZnLI186o22GmoXPz9vgLCX4pxwpxDKPKDHOM9caq79cFv/KeuGijaXmI w6PuolluISnlXd3WuXHENi7nccv7GNlNToM+buVfpU9UxADrS5pUEBMumyJ9w25LorBW UGcw== X-Gm-Message-State: ALoCoQm800DCk6R0WAylMGRmR1tuPfwkJLDDRBlrhWGCbElOHeNw/k6o4qvhbwpoY6pdqXMYIfsW 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.66.73 with SMTP id xp9mr15692vcb.27.1390282174706; Mon, 20 Jan 2014 21:29:34 -0800 (PST) Sender: antarus@scriptkitty.com Received: by 10.220.59.71 with HTTP; Mon, 20 Jan 2014 21:29:34 -0800 (PST) X-Originating-IP: [173.8.165.226] In-Reply-To: References: <20140119050224.GA7898@laptop.home> <20140120035446.063a31be@TOMWIJ-GENTOO> <52DD2E2A.2020303@gmail.com> <52DDBDBF.1020206@gentoo.org> Date: Mon, 20 Jan 2014 21:29:34 -0800 X-Google-Sender-Auth: XF4_mh9ebpm3ANy4aiQ4O8nPSf0 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=001a113642e62948ba04f0744be6 X-Archives-Salt: e7139709-a30d-4955-aa41-d4a0ca17dc27 X-Archives-Hash: 513dc8e4a7d8f016f922f89aa145b487 --001a113642e62948ba04f0744be6 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 20, 2014 at 4:46 PM, Rich Freeman wrote: > On Mon, Jan 20, 2014 at 7:22 PM, Patrick Lauer wrote: > > > > 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. > > So, here is how I reconcile this. There are basically two kinds of > problems - technical problems, and people problems. We need to deal > with both. I see QA as being primarily responsible for technical > problems, and it should be staffed to deal with them. I'm fully > supportive of it being a policy-creating body, with the Council being > the place to vet any policies that seem controversial. > > If an ebuild has a deficiency, that's a technical problem - QA should > step in. QA should also educate the maintainer so that they > understand how to avoid the problem in the future. > > Suppose the maintainer refuses to take the problem seriously (whether > they're just lazy, incompetent, or malicious). Now, that is a people > problem, and really shouldn't be QA's responsibility to deal with > beyond pointing it out to Comrel. > > Comrel should deal with people problems, and they should be staffed > accordingly. They need the manpower so that they can deal with them > efficiently. When QA says that a developer is not following a > technical policy, Comrel should defer to them as this is their area of > expertise. If either QA or Comrel gets out of hand there is always > the appeal to Council, so neither body needs to be walking on > eggshells or taking 18 months to decide to do something about a > problem. If QA feels like Comrel isn't taking their complaints > seriously, there is the Council - Comrel should be taking their > concerns seriously. However, QA needs to recognize that people > problems aren't always best solved with the use of command-line > utilities. > > In then end we'll only get where we need to be if we work together, > and avoid the passive-aggressive nonsense. If somebody feels that QA > is out of line by all means put it on the Council agenda. Otherwise, > devs need to do what they can to make the job of QA easier, and not > harder. > > About the only time I really see need for "emergency suspension > powers" is in the situation of some kind of hacking attempt. I'm not > aware of any attack like this ever being mounted, but if it were the > necessary action would involve a lot more than just suspending > somebody's commit rights. Probably the best first action would be to > disable all rsync/etc distribution, lock down cvs entirely, and then > begin cleanup. > > I can only think of one incident, and once we learned of the incident that developer was let go. > If there is some kind of general standing problem of Comrel ignoring > QA by all means let the Council know (assuming you can't just work it > out with them). However, Comrel announced not all that long ago a > general desire to enforce CoC with short bans/etc, and that they were > interested in having a vital QA organization so that they have some > kind of authority to rely on for technical questions. That certainly > sounds like a good direction to me, so I don't want to dwell too much > on the past. > > Bottom line - don't be afraid to do your job, and when something gets > in the way speak up about it! > > Rich > > --001a113642e62948ba04f0744be6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 20, 2014 at 4:46 PM, Rich Freeman <rich0@gentoo.org> = wrote:
On Mon, Jan 20, 2014 at 7:= 22 PM, Patrick Lauer <patrick@gent= oo.org> wrote:
>
> Yey, we're allowed to sometimes do revert games, if we're aski= ng nicely
> ... and the only way to stop the revert game is for QA to stand down.<= br> > We're allowed to send strongly-worded emails, but getting things b= aked
> into policy is too radical.

So, here is how I reconcile this. =C2=A0There are basically two kinds= of
problems - technical problems, and people problems. =C2=A0We need to deal with both. =C2=A0I see QA as being primarily responsible for technical
problems, and it should be staffed to deal with them. =C2=A0I'm fully supportive of it being a policy-creating body, with the Council being
the place to vet any policies that seem controversial.

If an ebuild has a deficiency, that's a technical problem - QA should step in. =C2=A0QA should also educate the maintainer so that they
understand how to avoid the problem in the future.

Suppose the maintainer refuses to take the problem seriously (whether
they're just lazy, incompetent, or malicious). =C2=A0Now, that is a peo= ple
problem, and really shouldn't be QA's responsibility to deal with beyond pointing it out to Comrel.

Comrel should deal with people problems, and they should be staffed
accordingly. =C2=A0They need the manpower so that they can deal with them efficiently. =C2=A0When QA says that a developer is not following a
technical policy, Comrel should defer to them as this is their area of
expertise. =C2=A0If either QA or Comrel gets out of hand there is always the appeal to Council, so neither body needs to be walking on
eggshells or taking 18 months to decide to do something about a
problem. =C2=A0If QA feels like Comrel isn't taking their complaints seriously, there is the Council - Comrel should be taking their
concerns seriously. =C2=A0However, QA needs to recognize that people
problems aren't always best solved with the use of command-line
utilities.

In then end we'll only get where we need to be if we work together,
and avoid the passive-aggressive nonsense. =C2=A0If somebody feels that QA<= br> is out of line by all means put it on the Council agenda. =C2=A0Otherwise,<= br> devs need to do what they can to make the job of QA easier, and not
harder.

About the only time I really see need for "emergency suspension
powers" is in the situation of some kind of hacking attempt. =C2=A0I&#= 39;m not
aware of any attack like this ever being mounted, but if it were the
necessary action would involve a lot more than just suspending
somebody's commit rights. =C2=A0Probably the best first action would be= to
disable all rsync/etc distribution, lock down cvs entirely, and then
begin cleanup.


I can only think of one incident, and = once we learned of the incident that developer was let go.

=C2=A0
If there is some kind of general standing problem of Comrel ignoring
QA by all means let the Council know (assuming you can't just work it out with them). =C2=A0However, Comrel announced not all that long ago a
general desire to enforce CoC with short bans/etc, and that they were
interested in having a vital QA organization so that they have some
kind of authority to rely on for technical questions. =C2=A0That certainly<= br> sounds like a good direction to me, so I don't want to dwell too much on the past.

Bottom line - don't be afraid to do your job, and when something gets in the way speak up about it!

Rich


--001a113642e62948ba04f0744be6--