GNU bug report logs - #61894
[PATCH RFC] Team approval for patches

Previous Next

Full log

View this message in rfc822 format

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <guix-devel <at> gnu.org>, 61894 <at> debbugs.gnu.org, guix-maintainers <at> gnu.org
Subject: [bug#61894] [PATCH RFC] Team approval for patches
Date: Mon, 06 Mar 2023 10:48:10 -0500

Hi Ludovic,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Hello Guix!
>
> The project has been steadily gaining new contributors, which is great,
> and I think we need to adjust our processes accordingly.
>
> Currently teams are described mostly as pools of people who can mentor
> contributors in a particular area and who can review patches in that
> area.  My proposal is to give teams formal approval power over changes
> to code in their area.
>
> This is sorta happening already, but informally: if a non-committer
> sends a patch, someone from the team eventually “approves” it by pushing
> it.  Within a team, the situation is different: people usually discuss
> changes, and the submitter (also committer) eventually pushes them;
> sometimes, the submitter pushes changes without getting approval (or
> feedback) from others on the team.
>
> With the proposed policy, members of a team would also have to review
> and approve each other’s work.  Formal approval means getting an
> explicit “LGTM” (or similar) from at least one other team member.
>
> This is similar to the review thresholds found on GitLab & co., where
> project admins can specify a minimum number of approvals required before
> a change is marked as ready.  I think it avoids the unavoidable
> misunderstandings that can arise in a growing group and help pacify
> day-to-day collaboration.
>
> Below is a suggested change.
>
> What do people think?
>
> Ludo’.

It sounds reasonable and a good change "on paper", but in practice I
think it may be too soon to formalize teams that way.  Teams are a
nascent concept which hasn't reached a point we can rely on it, in my
opinion.  We are still ironing out kinks in the tools [0] :-).  I'd
prefer we stay as nimble/agile as we can and maximize the potential of
our large committers pool for now, at the expense of sometimes having to
retroactively discussing/fixing up or reverting some change that wasn't
up to par, that could have possibly been caught by a more focused team.

[0] https://issues.guix.gnu.org/58813

-- 
Thanks,
Maxim

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.