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 5BD39138247 for ; Tue, 21 Jan 2014 22:57:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D3B0CE0D92; Tue, 21 Jan 2014 22:57:24 +0000 (UTC) Received: from albert.telenet-ops.be (albert.telenet-ops.be [195.130.137.90]) by pigeon.gentoo.org (Postfix) with ESMTP id BD690E0D84 for ; Tue, 21 Jan 2014 22:57:23 +0000 (UTC) Received: from TOMWIJ-GENTOO ([94.226.55.127]) by albert.telenet-ops.be with bizsmtp id GmxN1n00i2khLEN06mxNA3; Tue, 21 Jan 2014 23:57:22 +0100 Date: Tue, 21 Jan 2014 23:56:14 +0100 From: Tom Wijsman To: tommy@gentoo.org Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights Message-ID: <20140121235614.5cc6dda1@TOMWIJ-GENTOO> In-Reply-To: <52DEE09A.5020608@gentoo.org> References: <20140119050224.GA7898@laptop.home> <20140120035446.063a31be@TOMWIJ-GENTOO> <52DD2E2A.2020303@gmail.com> <20140121155616.6a8cdf9b@TOMWIJ-GENTOO> <20140121175657.9455.qmail@stuge.se> <20140121191154.10d9bd28@TOMWIJ-GENTOO> <20140121181654.11052.qmail@stuge.se> <20140121201855.4c81826c@TOMWIJ-GENTOO> <52DEE09A.5020608@gentoo.org> X-Mailer: Claws Mail 3.9.0 (GTK+ 2.24.22; x86_64-pc-linux-gnu) 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; boundary="Sig_/ZgBK3VYyDeaB7pNoNdo3iyR"; protocol="application/pgp-signature" X-Archives-Salt: c8d2750d-b6bf-4950-a957-d19f393aa9da X-Archives-Hash: 9a01fb74b45aff688e27c8c11904fd62 --Sig_/ZgBK3VYyDeaB7pNoNdo3iyR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 21 Jan 2014 22:03:22 +0100 Thomas Sachau wrote: > With this in mind, i currently dont see any case where QA would need > the ability to remove the commit access of a dev, so i dont see a > need for this glep update. The case you have enumerated is just one possible case, this is a case where policy is in place; it is however not always the case that there is policy, or perhaps even that policy is unclear. In these other cases the QA team has to take an actual decision instead of "it is policy"; in such cases, the reasoning behind this becomes technical and you get the whole idea we have been discussing here. Besides that, you also have the possibility for bigger breakages to happen; regardless of whether or not they are written down in policy. In some of these cases the roles of QA and ComRel become questionable; cfr. the whole discussion on #gentoo-qa, where I also asked the reverse question as to why QA has the power to suspend people in a technical area like the Portage tree when it is not part of their terrains. And just to make it clear one more time; it is the ability to "temporarily" "suspend" the commit access, as a means to get the developer to contact us where the developer was otherwise unavailable or intended to not communicate or listen to us. It is no way an actual removal or permanent decision; or well, it might be if this is about repeated behavior, but that's a whole different story... --=20 With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : TomWij@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D --Sig_/ZgBK3VYyDeaB7pNoNdo3iyR Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJS3vsSAAoJEJWyH81tNOV9miwIAI2hilmS+X2FJs0XDdUiLwGL h9LsnrAkPi1DepdcrwZmCc33UL6ug75J14Yq7VH8Q1Mnz0ExgPqXLhr9+zvY5hy3 1WsxfrPOFSLtu9CtHaKwjnEidFu+4g+1I4gOfSJqzGSclWixIXd531oaLgnCG1Jd oVQCtjOAdiPJM5ZE2hF17a8NMydCvm4U/pA32dhM8O/T7nDxq+OX3t3f+M7aw86z dmyGQpGYwxA+i8no4pcGZewxdAFFA144iCrs0N93uiXSBB9sGdPsMEzJTUpMASjs RZcC8wa2tgH165snSkK81pc/9V9IFCdiYHk8X4H8h5E94Wx54iXoon33FtrQLRg= =u9VP -----END PGP SIGNATURE----- --Sig_/ZgBK3VYyDeaB7pNoNdo3iyR--