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

[Maxim Cournoyer]

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:

> On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
>> Hi Simon,
>> 
>> Simon Tournier <zimon.toutoune@gmail.com> writes:
>> 
>> > Hi,
>> >
>> > On Tue, 07 Mar 2023 at 11:36, Andreas Enge <andreas@enge.fr> wrote:
>> >
>> >> 1) Every current and potential new package is covered by a team.
>> >> 2) Every team has at least 3 members, better yet 4 or 5.
>> >>    3 members would make it possible that even if one of them is on 
>> >> vacation
>> >>    or otherwise busy a patch could be pushed without this additional one
>> >>    week if the other 2 agree.
>> >
>> > It would help if being committer implies appearing at least in one team,
>> > no?
>> >
>> > Currently in etc/teams.scm.in, I count 26 members and 20 are committers
>> > over the 48 ones.  No blame. :-)
>> 
>> If most committers end up being team members, aren't we back to where we
>> currently stand?  It seems the original motivation here is to add some
>> extra control/guards against undesirable commits landing in the core of
>> Guix.  If a committer that previously landed such commits joined the
>> core team (e.g., myself), it seems to me the situation would be little
>> changed:
>
> My understanding was that it would help people feel more ownership over
> a portion of the code, allowing others to tag them explicitly for code
> review touching their area of expertise and allowing them to perhaps
> "pay less attention" to areas where they are less sure. The second part
> works better when all areas are covered by a team, but in practice I
> feel it was already happening, judging by our large backlog of patches.

I believe that's the original rationale behind teams.  But the change
being discussed here proposes to add a policy to make teams the
governing body of changes that touch their area (gating the patches
applied), which is something else.  That alone sounds like a good idea,
assuming teams are healthy and functional.  But the aim of the proposed
change is to reducing friction between committers, or "pacifying"
collaboration, to quote the original message.  I don't think such policy
will help *much* in that regard, since most of the teams people are the
same people as the committers.  It'll help some in the sense the group
interacting together on merging patches will be smaller, but at the cost
of reduced throughput, I reckon.

On a side note, it would also introduce some kind of hierarchy in the
group, which I dislike.  One of the things that make Guix special is
that it's pretty flat -- everybody can participate at the same level, at
least between committers).  I'd rather we don't try to emulate Debian on
that point.

-- 
Thanks,
Maxim