Reviewing the process for giving people commit rights

[Volker Krause]

On Freitag, 1. April 2022 17:36:50 CEST Nicolas Fella wrote:
> To summarize: I don't see a need to change how applications are
> reviewed, but perhaps there are steps we can integrate into the
> application process to communicate better the social etiquette that
> comes with commit access.

I agree.

The current process has worked with very very few issues for decades, and is a 
defining part of our community. Substantially changing that for a single 
prematurely merged MR seems hard to justify (and it's not like we wouldn't 
occasionally have cases of longer term contributors prematurely merging MRs 
either).

Yes, Gitlab makes it easier to contribute without commit access. However, 
commit access isn't only needed for the merge button, it also enables 
collaborating with others on work branches in the main repository.

For an occasional drive-by contributor that is usually not needed, but looking 
at the Gitlab activity of the contributor we are talking about here, it's not 
what I see there. That's a two month continued involvement in kwin, including 
working non-trivial changes in longer-lived branches.

It of course doesn't hurt to occasionally reiterate the expectations and 
responsibilities, to (new) contributors and sponsors alike, but I don't see a 
failure or the process here.

Regards,
Volker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20220402/a1392f30/attachment.sig>