[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug#61894] [PATCH RFC] Team approval for patches

From: Maxim Cournoyer
Subject: Re: [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 <> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]