[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#61894] [PATCH RFC] Team approval for patches
From: |
Maxim Cournoyer |
Subject: |
[bug#61894] [PATCH RFC] Team approval for patches |
Date: |
Mon, 06 Mar 2023 10:48:10 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi Ludovic,
Ludovic Courtès <ludo@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
- [bug#61894] [PATCH RFC] Team approval for patches, (continued)
- [bug#61894] [PATCH RFC] Team approval for patches, Andreas Enge, 2023/03/10
- [bug#61894] [PATCH RFC] Team approval for patches, Simon Tournier, 2023/03/10
- [bug#61894] [PATCH RFC] Team approval for patches, Andreas Enge, 2023/03/10
- [bug#61894] [PATCH RFC] Team approval for patches, Simon Tournier, 2023/03/11
- [bug#61894] [PATCH RFC] Team approval for patches, Felix Lechner, 2023/03/07
[bug#61894] [PATCH RFC] Team approval for patches, Felix Lechner, 2023/03/01
[bug#61894] [PATCH RFC] Team approval for patches,
Maxim Cournoyer <=