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 99A56138334 for ; Tue, 30 Apr 2019 10:28:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 48D69E0A00; Tue, 30 Apr 2019 10:28:36 +0000 (UTC) Received: from smtp.gentoo.org (dev.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 C534BE09F6 for ; Tue, 30 Apr 2019 10:28:35 +0000 (UTC) Received: from [192.168.1.209] (109-161-83-125.pppoe.yaroslavl.ru [109.161.83.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zlogene) by smtp.gentoo.org (Postfix) with ESMTPSA id 20352342ED6 for ; Tue, 30 Apr 2019 10:28:33 +0000 (UTC) Subject: Re: [gentoo-project] [PATCH v3] glep-0048: Provide clear rules for disciplinary actions To: gentoo-project@lists.gentoo.org References: <20190429120749.7835-1-mgorny@gentoo.org> From: Mikle Kolyada Openpgp: preference=signencrypt Message-ID: Date: Tue, 30 Apr 2019 13:28:33 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 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 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A8BCF7B47C8D8CDB640F3328" Content-Language: en-US X-Archives-Salt: 97423a07-28bf-4969-8188-3686cd44c1a9 X-Archives-Hash: ada399892595ce301189a8f107a164ea This is a multi-part message in MIME format. --------------A8BCF7B47C8D8CDB640F3328 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 29.04.2019 18:27, Thomas Deutschmann wrote: > On 2019-04-29 14:07, Micha=C5=82 G=C3=B3rny wrote: >> +* If a particula= r developer persistently causes QA violations (actions that >> + negatively impact the behavior of Gentoo systems, work of other developers >> + or infrastructure facilities), the QA team may issue a temporary revocation >> + of developer's commit access (ban), up to 30 days. In case of repeated >> + offenses, the QA team may request that ComRel re-evaluates the commit access. >> + All the evidence of the violation, as well as ban length will be evaluated >> + and voted on by the QA team for each case individually. > My opinion here: > > 1) The whole requested GLEP change is wrong. It doesn't take into > account that from my perspective, disciplinary actions should be last > resort. Suggestions are welcome. > We don't have a current problem to solve. I would ask you to refrain fr= om such a vague statement. I expect any council member to be aware of historical references that lead to the consequences. As a member of both ComRel and QA (including leading roles for some terms), I can state that there is the problem. The more we ignore it the worse it becomes. Even more, I do not expect a council member to state something like that just because they think it does not exist. Especially when the whole team claims the opposite. > I acknowledge that in > the past there was a problem that a requested b= an wasn't executed in > time. I am fine with updating GLEP to indicate that QA has the power to > do that so it becomes clear that whoever has to execute the ban has to > follow if that was the reason why the ban wasn't executed in time... > nothing more. This is irrelevant to the initial changes idea. > 2) QA project is only responsible for gentoo.git. That's it. Abusing QA= > project to protect Gentoo infrastructure or any other project is wrong. > Also, "impacting the work of other developers" is not QA's > responsibility and due to the fact that you cannot really define that > sentences, it could be abused to construct a case against any developer, > QA team wants to get rid of for no real reasons. True, and if a developer made a malicious commit that led to the rsync breakage is about QA. Otherwise we do not care about overlays, if you want to hear this. > 3) 30 days is too long. Like said, Gentoo should never be about > disci= plinary actions but it looks like some current QA members want to > change that. I am against that change: People asked us to define the maximum, so we did. > If someone is ignoring Gentoo's QA requirements (and not QA project > r= ules, remember: QA project is working *for* Gentoo and not > *against*...) QA project should communicate with that developer. I > assume that no developer will violate Gentoo's QA requirements on > purpose. If the developer won't fix/stop violating QA requirements > (=3Ddon't be cooperative with Gentoo) QA project would issue the first ba= n > (7d). This only works in theory, not in practice. > If developer retains his/her hostile behavior when he/she regains > com= mit access, maybe there will be a second ban (this time for 14d). If > developer still doesn't change behavior and keeps violating rules the > complete Gentoo project agreed on, ComRel has to take action (and will > probably have to kick developer out of Gentoo assuming the developer is > still not cooperating with Gentoo). > > For me the important difference is: Gentoo is not 'real life'. I.e. in > life you cannot always chose the people you have to deal with. So we > have laws and policy to be prepared against people we cannot avoid. But > assuming that everyone in Gentoo is sharing the same goals (for Gentoo) > and has accepted CoC, a situation like this shouldn't be normal. > Therefore we don't need to give a project like QA the absolute power to > protect us just in case of an emergency Again, QA has had this power for ages, nothing changed so far. I told you this at least twice. Our goal is to document powers and make it clear, so people stop asking us something like "why does it work this way??? This is undocumented!" > (we don't really have real > emergencies, and if I for example would j= ust start to delete/manipulate > all ebuilds in Gentoo repository I am very sure I would be stopped in > time and nobody would say "Damn! We can't stop him, we first need a GLEP > allowing us to..."). > > -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEWmyBGnI+Eihw6dN8HICQJIqVl8cFAlzII1EACgkQHICQJIqV l8deowf/SDVY+rGiPuntqTgh4YzEdNC6PFCedqGUdT+pqbW11V4+bL6nMWTKL8FJ CmwHlPddwmcjm7vciINZeDjxAR+Zu0Ijy0S5I9TnOH1rjPmUIYpAMZbuepPzVE/8 IGTLKTCDaxkskbCAY6GP5Jdy9skq3WTT+7fhhKe1tBnp+XDQ62y9eO+WZCruMkNy o506ldmxlcaeXWj+lQcvhA2TN0kLjvF13AFxxnWNsHjloOafu+Qn9kVXF58hHC5p LF5LwyReidpy1xHZodoRIVYyJNieREBxRSgw/PB6K1Bw8vA4P0wtJowhjYCU+kZo /vU4ZWuXwCt12SHaaniBEJJNOqhCwQ=3D=3D =3D4C4c -----END PGP SIGNATURE----- --------------A8BCF7B47C8D8CDB640F3328 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 29.04.2019 18:27, Thomas Deutschmann wrote:
> On 2019-04-29 14:07, Michał Górny wrote: >> +* If a particular developer persistently causes QA violations (actions that >> + negatively impact the behavior of Gentoo systems, work of other developers >> + or infrastructure facilities), the QA team may issue a temporary revocation >> + of developer's commit access (ban), up to 30 days. In case of repeated >> + offenses, the QA team may request that ComRel re-evaluates the commit access. >> + All the evidence of the violation, as well as ban length will be evaluated >> + and voted on by the QA team for each case individually. > My opinion here: > > 1) The whole requested GLEP change is wrong. It doesn't take into > account that from my perspective, disciplinary actions should be last > resort. Suggestions are welcome.

> We don't have a current problem to solve. I would ask you to refrain from such a vague statement. I expect any
council member to be
aware of historical references that lead to the consequences. As a
member of both ComRel and QA (including leading roles for some terms),
I can state that there is the problem. The more we ignore it the
worse it becomes. Even more, I do not expect a council member to state
something like that just because they think it does not exist.
Especially when the whole team claims the opposite.
> I acknowledge that in > the past there was a problem that a requested ban wasn't executed in > time. I am fine with updating GLEP to indicate that QA has the power to > do that so it becomes clear that whoever has to execute the ban has to > follow if that was the reason why the ban wasn't executed in time... > nothing more. This is irrelevant to the initial changes idea.

> 2) QA project is only responsible for gentoo.git. That's it. Abusing QA > project to protect Gentoo infrastructure or any other project is wrong. > Also, "impacting the work of other developers" is not QA's > responsibility and due to the fact that you cannot really define that > sentences, it could be abused to construct a case against any developer, > QA team wants to get rid of for no real reasons. True, and if a developer made a malicious commit that led to the rsync
breakage is about QA.
Otherwise we do not care about overlays, if you want to hear this.

> 3) 30 days is too long. Like said, Gentoo should never be about > disciplinary actions but it looks like some current QA members want to > change that. I am against that change: People asked us to define the maximum, so we did.
> If someone is ignoring Gentoo's QA requirements (and not QA project > rules, remember: QA project is working *for* Gentoo and not > *against*...) QA project should communicate with that developer. I > assume that no developer will violate Gentoo's QA requirements on > purpose. If the developer won't fix/stop violating QA requirements > (=don't be cooperative with Gentoo) QA project would issue the first ban > (7d). This only works in theory, not in practice.

> If developer retains his/her hostile behavior when he/she regains > commit access, maybe there will be a second ban (this time for 14d). If > developer still doesn't change behavior and keeps violating rules the > complete Gentoo project agreed on, ComRel has to take action (and will > probably have to kick developer out of Gentoo assuming the developer is > still not cooperating with Gentoo). > > For me the important difference is: Gentoo is not 'real life'. I.e. in > life you cannot always chose the people you have to deal with. So we > have laws and policy to be prepared against people we cannot avoid. But > assuming that everyone in Gentoo is sharing the same goals (for Gentoo) > and has accepted CoC, a situation like this shouldn't be normal. > Therefore we don't need to give a project like QA the absolute power to > protect us just in case of an emergency Again, QA has had this power for ages, nothing changed so far. I told
you this at least twice.
Our goal is to document powers and make it clear, so people stop asking
us something like
"why does it work this way??? This is undocumented!"

> (we don't really have real > emergencies, and if I for example would just start to delete/manipulate > all ebuilds in Gentoo repository I am very sure I would be stopped in > time and nobody would say "Damn! We can't stop him, we first need a GLEP > allowing us to..."). > > -----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEWmyBGnI+Eihw6dN8HICQJIqVl8cFAlzII1EACgkQHICQJIqV
l8deowf/SDVY+rGiPuntqTgh4YzEdNC6PFCedqGUdT+pqbW11V4+bL6nMWTKL8FJ
CmwHlPddwmcjm7vciINZeDjxAR+Zu0Ijy0S5I9TnOH1rjPmUIYpAMZbuepPzVE/8
IGTLKTCDaxkskbCAY6GP5Jdy9skq3WTT+7fhhKe1tBnp+XDQ62y9eO+WZCruMkNy
o506ldmxlcaeXWj+lQcvhA2TN0kLjvF13AFxxnWNsHjloOafu+Qn9kVXF58hHC5p
LF5LwyReidpy1xHZodoRIVYyJNieREBxRSgw/PB6K1Bw8vA4P0wtJowhjYCU+kZo
/vU4ZWuXwCt12SHaaniBEJJNOqhCwQ==
=4C4c
-----END PGP SIGNATURE-----

--------------A8BCF7B47C8D8CDB640F3328--