| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA256 |
| 3 |
|
| 4 |
|
| 5 |
On 29.04.2019 18:27, Thomas Deutschmann wrote: |
| 6 |
> On 2019-04-29 14:07, Michał Górny wrote: >> +* If a particular developer persistently causes QA violations |
| 7 |
(actions that >> + negatively impact the behavior of Gentoo systems, |
| 8 |
work of other developers >> + or infrastructure facilities), the QA team |
| 9 |
may issue a temporary revocation >> + of developer's commit access |
| 10 |
(ban), up to 30 days. In case of repeated >> + offenses, the QA team may |
| 11 |
request that ComRel re-evaluates the commit access. >> + All the |
| 12 |
evidence of the violation, as well as ban length will be evaluated >> + |
| 13 |
and voted on by the QA team for each case individually. > My opinion |
| 14 |
here: > > 1) The whole requested GLEP change is wrong. It doesn't take |
| 15 |
into > account that from my perspective, disciplinary actions should be |
| 16 |
last > resort. Suggestions are welcome. |
| 17 |
|
| 18 |
> We don't have a current problem to solve. I would ask you to refrain from such a vague statement. I expect any |
| 19 |
council member to be |
| 20 |
aware of historical references that lead to the consequences. As a |
| 21 |
member of both ComRel and QA (including leading roles for some terms), |
| 22 |
I can state that there is the problem. The more we ignore it the |
| 23 |
worse it becomes. Even more, I do not expect a council member to state |
| 24 |
something like that just because they think it does not exist. |
| 25 |
Especially when the whole team claims the opposite. |
| 26 |
> I acknowledge that in > the past there was a problem that a requested ban wasn't executed in |
| 27 |
> time. I am fine with updating GLEP to indicate that QA has the power |
| 28 |
to > do that so it becomes clear that whoever has to execute the ban has |
| 29 |
to > follow if that was the reason why the ban wasn't executed in |
| 30 |
time... > nothing more. This is irrelevant to the initial changes idea. |
| 31 |
|
| 32 |
> 2) QA project is only responsible for gentoo.git. That's it. Abusing QA > project to protect Gentoo infrastructure or any other project is |
| 33 |
wrong. > Also, "impacting the work of other developers" is not QA's > |
| 34 |
responsibility and due to the fact that you cannot really define that > |
| 35 |
sentences, it could be abused to construct a case against any developer, |
| 36 |
> QA team wants to get rid of for no real reasons. True, and if a |
| 37 |
developer made a malicious commit that led to the rsync |
| 38 |
breakage is about QA. |
| 39 |
Otherwise we do not care about overlays, if you want to hear this. |
| 40 |
|
| 41 |
> 3) 30 days is too long. Like said, Gentoo should never be about > disciplinary actions but it looks like some current QA members want |
| 42 |
to > change that. I am against that change: People asked us to define |
| 43 |
the maximum, so we did. |
| 44 |
> If someone is ignoring Gentoo's QA requirements (and not QA project > rules, remember: QA project is working *for* Gentoo and not > |
| 45 |
*against*...) QA project should communicate with that developer. I > |
| 46 |
assume that no developer will violate Gentoo's QA requirements on > |
| 47 |
purpose. If the developer won't fix/stop violating QA requirements > |
| 48 |
(=don't be cooperative with Gentoo) QA project would issue the first ban |
| 49 |
> (7d). This only works in theory, not in practice. |
| 50 |
|
| 51 |
> If developer retains his/her hostile behavior when he/she regains > commit access, maybe there will be a second ban (this time for 14d). |
| 52 |
If > developer still doesn't change behavior and keeps violating rules |
| 53 |
the > complete Gentoo project agreed on, ComRel has to take action (and |
| 54 |
will > probably have to kick developer out of Gentoo assuming the |
| 55 |
developer is > still not cooperating with Gentoo). > > For me the |
| 56 |
important difference is: Gentoo is not 'real life'. I.e. in > life you |
| 57 |
cannot always chose the people you have to deal with. So we > have laws |
| 58 |
and policy to be prepared against people we cannot avoid. But > assuming |
| 59 |
that everyone in Gentoo is sharing the same goals (for Gentoo) > and has |
| 60 |
accepted CoC, a situation like this shouldn't be normal. > Therefore we |
| 61 |
don't need to give a project like QA the absolute power to > protect us |
| 62 |
just in case of an emergency Again, QA has had this power for ages, |
| 63 |
nothing changed so far. I told |
| 64 |
you this at least twice. |
| 65 |
Our goal is to document powers and make it clear, so people stop asking |
| 66 |
us something like |
| 67 |
"why does it work this way??? This is undocumented!" |
| 68 |
|
| 69 |
> (we don't really have real > emergencies, and if I for example would just start to |
| 70 |
delete/manipulate > all ebuilds in Gentoo repository I am very sure I |
| 71 |
would be stopped in > time and nobody would say "Damn! We can't stop |
| 72 |
him, we first need a GLEP > allowing us to..."). > > -----BEGIN PGP |
| 73 |
SIGNATURE----- |
| 74 |
|
| 75 |
iQEzBAEBCAAdFiEEWmyBGnI+Eihw6dN8HICQJIqVl8cFAlzII1EACgkQHICQJIqV |
| 76 |
l8deowf/SDVY+rGiPuntqTgh4YzEdNC6PFCedqGUdT+pqbW11V4+bL6nMWTKL8FJ |
| 77 |
CmwHlPddwmcjm7vciINZeDjxAR+Zu0Ijy0S5I9TnOH1rjPmUIYpAMZbuepPzVE/8 |
| 78 |
IGTLKTCDaxkskbCAY6GP5Jdy9skq3WTT+7fhhKe1tBnp+XDQ62y9eO+WZCruMkNy |
| 79 |
o506ldmxlcaeXWj+lQcvhA2TN0kLjvF13AFxxnWNsHjloOafu+Qn9kVXF58hHC5p |
| 80 |
LF5LwyReidpy1xHZodoRIVYyJNieREBxRSgw/PB6K1Bw8vA4P0wtJowhjYCU+kZo |
| 81 |
/vU4ZWuXwCt12SHaaniBEJJNOqhCwQ== |
| 82 |
=4C4c |
| 83 |
-----END PGP SIGNATURE----- |
Archives