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 064E9138247 for ; Tue, 21 Jan 2014 17:50:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C4A94E0F53; Tue, 21 Jan 2014 17:50:09 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D3D4AE0F03 for ; Tue, 21 Jan 2014 17:50:08 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id x13so10499869ief.9 for ; Tue, 21 Jan 2014 09:50:08 -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=z4cIXYNMeLRlo72hDkf/Y9mnRLnZDvyr2/r6RNCxqWU=; b=pD7SJZTUYi2Ukz6SpgBbDjFV4APEPuX8XkdqyJyc1QwoeK7bsceTiEcBbFYrNoxxtK tTP80S1BzA7yHBBSOr98ZOha6rTnEA2ISi+ZcWmp9dIAb1Fx13aWwEp5qjoteG+GuDX0 UiXCIsQgJ86Rk7dYCoqEc9hmXubsF3r7cvpRmdsJczCsKKcJ5GgeAxbpwjHNH+xIgPhG 3l0aSMAx0KVFsddO4NqLV3QVfj0ejMPpsJ3aBhnjWQ2Zcm1hIY4RFXc/BSTkEWvXUbY4 uHQSj8UjgdKO+VN1SJCu3bRmRJvuKVToTpbjnPZUyhh8meu9Virec1MrxvtAO7jpDkv/ ARuA== 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.192.167 with SMTP id hh7mr19004474igc.3.1390326608242; Tue, 21 Jan 2014 09:50:08 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.73.99 with HTTP; Tue, 21 Jan 2014 09:50:08 -0800 (PST) In-Reply-To: <20140121172601.GA1624@laptop.home> References: <20140119050224.GA7898@laptop.home> <20140120035446.063a31be@TOMWIJ-GENTOO> <52DD2E2A.2020303@gmail.com> <20140121155616.6a8cdf9b@TOMWIJ-GENTOO> <20140121172601.GA1624@laptop.home> Date: Tue, 21 Jan 2014 12:50:08 -0500 X-Google-Sender-Auth: j2CI1s0mniDFmB5pWoA3oujjaSQ 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: 2e863abd-b303-4a25-aaf9-f71e4875c387 X-Archives-Hash: 9899cb4c9a82a43979ac5271ecb5cd29 On Tue, Jan 21, 2014 at 12:26 PM, William Hubbs wrote: > On Tue, Jan 21, 2014 at 10:47:50AM -0500, Rich Freeman wrote: >> 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. > > What about the scenario where qa makes a change, then the dev, in a > civil manor, explains to qa why he prefers his original method and > reverts QA's change without the agreement of QA and without presenting > his case to the council? Now you have another qa violation since GLEP > 48 states that QA's changes must stand until the council says otherwise. > However, assuming the exchanges between qa and the dev are still > respectful, I'm not sure there is a personal issue. It isn't a personal issue, but it is a personnel / human-factors issue. A developer is refusing to follow policy. The CofC is but one policy - all the GLEPs are policy, as is the Devmanual. A developer who refuses to follow policy is subject to action by Comrel. At least, that is how I see the roles of the groups (but I'm open to counter-argument). The other way to do things is to make both groups responsible for what amounts to HR, but then we need to make sure we staff QA accordingly. QA can't then just solve the technical problems and deal with people like you might deal with code, otherwise the Council and/or Comrel really will end up having to deal with a bunch of personal problems. QA stepping in with temporary bans as a band-aid solution to a more serious problem is fine. However, dealing with the inter-personal issues requires a different sort of skillset. A developer who doesn't follow policy is either unable to do so or unwilling to do so. Either problem might be correctable, or perhaps we'll just have to go our separate ways. I think Comrel should be the body that is staffed with the right skills to make that determination. Rich