From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E09D7138334 for ; Fri, 12 Apr 2019 16:26:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 93BA0E08EF; Fri, 12 Apr 2019 16:26:04 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 4B79AE08ED for ; Fri, 12 Apr 2019 16:26:04 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 3404A340E77; Fri, 12 Apr 2019 16:26:01 +0000 (UTC) Message-ID: <22bf7f73eadd0504bc55df189778bde21d076042.camel@gentoo.org> Subject: Re: [gentoo-project] [PATCH] glep-0048: Provide clear rules for disciplinary actions From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Cc: qa Date: Fri, 12 Apr 2019 18:25:57 +0200 In-Reply-To: References: <20190412144043.5010-1-mgorny@gentoo.org> Organization: Gentoo Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-JsapI2DWg0diLZQUaiVL" User-Agent: Evolution 3.30.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 X-Archives-Salt: 91bd722c-153e-4978-aa5c-c5561f0a10c2 X-Archives-Hash: 233b2b8c5b7bb029c44bcc5007cab010 --=-JsapI2DWg0diLZQUaiVL Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2019-04-12 at 11:30 -0400, Alec Warner wrote: > Just as a frame, I'm not on QA. >=20 > On Fri, Apr 12, 2019 at 10:40 AM Micha=C5=82 G=C3=B3rny wrote: >=20 > > Update the wording of GLEP 48 to provide clear information on what kind > > of disciplinary actions QA can issue, and in what circumstances they ca= n > > be exercised. Remove the unclear reference to ComRel that is either > > meaningless or violation of scope. > >=20 >=20 > Is there a particular driver for this change? E.g. have you been > dissatisfied with the current procedure, or perhaps Comrel is not acting = on > your referrals? Yes, I am dissatisfied. I am especially dissatisfied by the absurd bureaucracy and unclear jurisdiction. I've seen QA claiming we don't have authority and sending me to ComRel, and being sent back to QA because 'it's QA business'. Furthermore, even if we can get this bureaucracy to work, we end up with absurd delays because of two teams taking vote on the same issue in series. Do you really think it's good to ban someone *now* because he did something two weeks earlier? > In general I perceive the QA organization as an educational / enabling > organization (it trains people and writes tools) and not as a > punishment-based organization (where it shames people for their mistakes > and removes commit access from people who make too many.) This isn't to s= ay > there isn't room for removing access for committers who routinely make > mistakes, I just think it ends up supporting this underlying narrative > about the project that (and I'm framing this here) "Gentoo should be > smaller and only composed of elite committers who understand all the > complex stuff required to not break things." This type of change was > previously discussed on the project list. I think you're insulting QA's competence here. The goal is not to ban people for making mistakes. The goal is to be able to actually act when all less invasive measures fail. > > According to the old wording, QA could request 're-evaluating commit > > rights' from ComRel. This is very unclear, and has been a source of > > confusion more than once. Firstly, it is unclear whether ComRel merely > > serves as a body executing the QA team's decision, or whether it is > > supposed to make independent judgment (which would be outside its > > scope). Secondly, it suggests that the only disciplinary action > > possible would be 're-evaluating commits rights' which sounds like > > an euphemism for removing commit access permanently. > >=20 > > The new wording aims to make things clear, and make QA disciplinary > > actions independent of ComRel. Explanation for the individual points > > follow. > >=20 > > Firstly, it aims to clearly define the domain of QA actions, and set > > a better distinction between QA and ComRel. In this context, QA > > is concerned whenever the developer's action technically affects Gentoo= , > > which includes breaking user systems, Infrastructure tooling, other > > packages, etc. ComRel on the other hand is concerned in actions having > > social consequences rather than technical. > >=20 >=20 > Previous QA teams would often take unilateral action against individual > developers, often for problems that were poorly or under-documented[0]. T= he > infrastructure teams in the past had similar issues (e.g. removing commit > access of individual developers on a whim) and part of the reason that > Comrel is slower to act is to prevent this type of activity. Hence my > question above: Is Comrel not doing the right thing here? Why do we need = to > delegate this ability directly with the QA team? This sounds like we're creating unjustified bureaucracy just because we had some social problem with some people in the past. Why do you presume that ComRel will never abuse its power, and at the same time presume QA will kick people 'on a whim'? I'm not sure if I'm supposed to answer the same question twice. The point is, in my opinion the current procedure is unjustified and there is a simpler procedure that should work here. > > Thirdly, it removes the unnecessary involvement of ComRel, QA violation= s > > being outside of their scope of interest. Each case of QA violations > > is analyzed by QA team individually, and QA team exercises disciplinary > > actions independently. At the same time, appeal path via Council is > > defined. > >=20 >=20 > I see the QA organization as having one primary mission "making sure that > Gentoo users can install and use Gentoo packages". I see the team > supporting that in four key areas: > - Education: this is content like the devmanual. > - Prevention: Tools like repoman (to prevent bad commits from being > committed) or a CI branch (to prevent users from seeing bad commits.) > - Mitigation: The CI branch again here, helps us quickly find bad commit= s, > and mitigates any bad commit because only the passing CI branch is made > available to users, so bad commits are lower impact. > - Punishment: If people don't use the tools, or consistently don't take > feedback, we should probably not trust them to commit. >=20 > I find punishment the least effective thing QA can do; the QA organizatio= n > is an *enabling* organization that enables people to be effective. Removi= ng > commit access is not really enabling anyone and unlike focusing on the > other three areas (whose impact is multiplied by the number of > contributors) removing commit access only affects 1 person at a time. >=20 I agree. However, there are valid cases when the three first areas just don't solve the problem. We can educate, we can put a lot of effort into making things more 'fool-proof' but in the end, it doesn't stop developers from breaking stuff. Or turns Gentoo into a unmaintainable mess where every developer suffers because of few making mistakes. The point is, that if a developer keeps breaking stuff and doesn't listen to reminders to be more careful, there is a point when QA should be able to issue a ban to make the developer realize he can't go on like this. --=20 Best regards, Micha=C5=82 G=C3=B3rny --=-JsapI2DWg0diLZQUaiVL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQKTBAABCgB9FiEEXr8g+Zb7PCLMb8pAur8dX/jIEQoFAlywvBVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDVF QkYyMEY5OTZGQjNDMjJDQzZGQ0E0MEJBQkYxRDVGRjhDODExMEEACgkQur8dX/jI EQpc8A/+PD1EbDJIHtLwT1UHVVsxIi/abQNMsp0dOXNrlfrBEw1TokAMj/6iIEsB Z7F3ctSWaMo3V0sb2aNrPZ+oGb6cBtjDgCTJ9W4JZEIBbQwA8SXd7PReEoR7Dri3 Iiglh1/ywNw0ULZ0WgOi43Tu04RmJR5/bzWnd71MV/h2lVoRQDuSWLyoexCcmhs+ QIjAeyx4LezRCRHBFS6YRCwRyD6AlGadH5KzhKp18kETRTLp4geIgCZsfZXTqKu2 8ciWUcTyugVW0sudnoxCTLwFHkSy2EFJydqejjXyQQsF+Xk+IowgXWeXA+gMXvIh y6moJaB4woTxCooZgAFygxp+mI7l8oxwyPfrmLU5yaiblJUbfwrvvqT1a1+sXJGG k6Eqh4vMg0bGBI8br4u1H8noGOSqpuzFod/R4R7V8VyBOIOGRatTctKiK463FZjW 7QYL9OKgSOiwOYSq4sM09o+5kaH0b3IuFxkUp+KURUbHKwtgHUJn72lMCLnLpxZW I7JvdThwsB9oe4HbukXQooCtuP9RYHpYAGwS67hxhDut1drj0vggS6/5isCy7j18 h9M6qu6KN3YZM4QfiqCH3HDm6xaFHgH+b5fgM6Q2O8Ci1E2YCZt74Il1HxDmGIbu 9kz6nkHbeu2IyUxEGRhJki2jd9/YfAhRCp2VGeA4gWNsyictVoc= =Ae9Y -----END PGP SIGNATURE----- --=-JsapI2DWg0diLZQUaiVL--