Reviewing the process for giving people commit rights

[Helio Chissini de Castro]

+1

Só far, simple solution and would reduce a lot work of reviewers.

On Wed, Apr 13, 2022, 04:27 Ingo Klöcker <kloecker at kde.org> wrote:

> On Samstag, 2. April 2022 11:21:11 CEST Kevin Kofler wrote:
> > Nate Graham wrote:
> > > This caused a problem recently in KWin. A new contributor was given
> > > commit rights very soon after he appeared, and then immediately after
> > > that, he inappropriately merged a not-fully-reviewed an un-accepted
> > > merge request
> > > (https://invent.kde.org/plasma/kwin/-/merge_requests/1980). It seems
> > > that he did not have a sense of the cultural norms around committing to
> > > KDE repos, and giving him commit access was probably premature.
> >
> > Well, the question this calls for is why the merge request was still not
> > fully reviewed almost six weeks after submission. I would guess that
> that is
> > what the misunderstanding came from: the submitter most likely assumed
> that
> > the changes were fine given that there were no outstanding comments. (The
> > submitter did try to address those comments that you had in those six
> > weeks.)
> >
> > I should also point out that the complaints in Xaver Hugl's post-merge
> > review were all only formatting/whitespace, choice of comment sign, and
> > brace issues (with no effect on the end user at all),
>
> Several PIM libraries have clang-format pre-commit hooks that prevent
> formatting issues in the first place (and, occasionally, annoy me because
> the
> hooks also complain about formatting issues in unstaged/uncommitted code,
> e.g.
> temporarily commented out code where the commented out code is not
> correctly
> indented).
>
> Formatting is something no reviewer should have to waste brain energy on
> nowadays.
>
> Regards,
> Ingo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20220413/902c7095/attachment.htm>