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 D344C138247 for ; Tue, 21 Jan 2014 17:26:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 5D210E0E30; Tue, 21 Jan 2014 17:26:08 +0000 (UTC) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 19045E0CEB for ; Tue, 21 Jan 2014 17:26:06 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id gq1so6990120obb.7 for ; Tue, 21 Jan 2014 09:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=EapIgoOn8zd9nY3goTBvs5iw8gG8t7ffrSHm4OHXS08=; b=bbx8qwzIXisE/pmFW9IoyUmzZcONb76o4GVEwiXLHGmLGBELF8c2O+v3zhU1Vm6WKy pmMzSK/R/tWKpeNVGQSRENxF35j/I397I3+45zGzN0wIIrW2ODStk1MIbxt3UerMAkZI b1rywWgjnZvaF12Rvwu9xGyCvoXJK5mtQW7K+LyYZZVn2caJyqF1/iqTz62IviP+VUuL EKep0HZivv7/8b8YF/4z+JynqF6wzgSzLM7JnS9jP5Ts7F2zjMJwWLCvrpKERxHfWjPN N1YVnosViLlUTfwqRb+H8MMDFNs101m8gfNTvRiLcPHR9/F0Q8WQTrZTN4fNDoBcz7y1 Qjow== X-Received: by 10.60.46.167 with SMTP id w7mr2104553oem.70.1390325166241; Tue, 21 Jan 2014 09:26:06 -0800 (PST) Received: from laptop (cpe-76-187-91-128.tx.res.rr.com. [76.187.91.128]) by mx.google.com with ESMTPSA id fz6sm8518267obb.3.2014.01.21.09.26.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jan 2014 09:26:04 -0800 (PST) Sender: William Hubbs Received: by laptop (sSMTP sendmail emulation); Tue, 21 Jan 2014 11:26:01 -0600 Date: Tue, 21 Jan 2014 11:26:01 -0600 From: William Hubbs To: gentoo-dev@lists.gentoo.org Cc: Rich Freeman Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights Message-ID: <20140121172601.GA1624@laptop.home> Mail-Followup-To: gentoo-dev@lists.gentoo.org, Rich Freeman References: <20140119050224.GA7898@laptop.home> <20140120035446.063a31be@TOMWIJ-GENTOO> <52DD2E2A.2020303@gmail.com> <20140121155616.6a8cdf9b@TOMWIJ-GENTOO> 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 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 9b3d38dd-45cb-4a77-b5d6-4682dc4700ad X-Archives-Hash: ed27aa8a99a70dcd1e51dad851f3409f --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. Well, I guess that's the big question isn't it -- what is personal vs technical? I think we can all agree that if qa changes an ebuild and a dev comes back with "You stupid *** leave my *** ebuild alone." and reverts qa's change, that is personal and goes straight to Comrel because it is now a CoC violation as well. 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. wrt the commit rights issue: QA is asking for the ability to *suspend* not *revoke* commit rights. This was explained well by Tom; it is a temporary measure to get a dev's attention if nothing else works. I agree that it is strong. However, if qa gets out of hand with it, the council can always step in and take care of the matter. Thoughts? William --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlLerakACgkQblQW9DDEZTgdAACfT4PRzn8dsLCRn8ndtilZhmj3 APAAn1p8im/V3yovdsDpJ/R3F6aNzZ8p =QXib -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm--