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 EB640138247 for ; Tue, 21 Jan 2014 00:46:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B4E4E0DD0; Tue, 21 Jan 2014 00:46:37 +0000 (UTC) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 7E5A2E0DA1 for ; Tue, 21 Jan 2014 00:46:36 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id tq11so7323082ieb.14 for ; Mon, 20 Jan 2014 16:46:35 -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=KQ1RI9p/WKrJjIKjLBq6jwpmV0CmD7ahuCn1hahiYhQ=; b=eIOzvuDWEgOH+IynIHXQ2JPhPzW5zMp71j6OS23Syr/90J1LRAQQBJg3sk4/I88T+8 TlmcaEADmvxezr4igQzIjre61sWulHKhkxF+/d9tQUaRbxWlhOxAaWO66mzRCpyM26rP sTeA5g9d429H1bfR9GABdfCsmYpoZefY0SWfX/bRjyccbMbgM402PPjpkrIN/mln4GVZ PL4taCH4FGvE70C47B9VrIIXh6tfyHpGAgLD/gkm37gkt3CYtVXLa+kZjRB6BO2Ymagf x8ci3eZPfF5bslq2tY6tBUJQAbm0VOvfCgTYY32tD2Qq0rJkYcFfm85XAYPHx4cSON9d HsWQ== 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.50.45.33 with SMTP id j1mr15141810igm.32.1390265195782; Mon, 20 Jan 2014 16:46:35 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.73.99 with HTTP; Mon, 20 Jan 2014 16:46:35 -0800 (PST) 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 19:46:35 -0500 X-Google-Sender-Auth: yNCM1UKWCW5KEZcyzJeMwgg30Qo 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: 1c44f1f2-ccb9-4950-ac56-c8f2756e7456 X-Archives-Hash: 4d4ed29877c943d384dd9379cf0d1f98 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. 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