* Re: [gentoo-project] [PATCH v3] glep-0048: Provide clear rules for disciplinary actions
@ 2019-04-29 15:27 99% ` Thomas Deutschmann
0 siblings, 0 replies; 1+ results
From: Thomas Deutschmann @ 2019-04-29 15:27 UTC (permalink / raw
To: gentoo-project
[-- Attachment #1.1: Type: text/plain, Size: 3369 bytes --]
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. We don't have a current problem to solve. 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.
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.
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:
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). 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 (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...").
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 618 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2019-04-29 12:07 [gentoo-project] [PATCH v3] glep-0048: Provide clear rules for disciplinary actions Michał Górny
2019-04-29 15:27 99% ` Thomas Deutschmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox