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

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: guix-maintainers <at> gnu.org, Simon Tournier <zimon.toutoune <at> gmail.com>, Christopher Baines <mail <at> cbaines.net>, 61894 <at> debbugs.gnu.org, 宋文武 <iyzsong <at> envs.net>, Andreas Enge <andreas <at> enge.fr>, guix-devel <at> gnu.org
Subject: [bug#61894] [PATCH RFC] Team approval for patches
Date: Fri, 10 Mar 2023 18:22:07 +0100

Hello Maxim and all!

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

>> 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.
>
> In other words, to give teams the power to gate the changes touching
> their scope.  That's reasonable, if we have functional teams.  I'd argue
> we aren't there yet.

I kinda agree; bootstrapping issue then?

I hope the maintainer team can help make teams “more functional”,
whatever that teams.  It’s really what maintainership is about in Guix;
it’s not about writing code.

> And also:
>> I think it avoids the unavoidable misunderstandings that can arise in
>> a growing group and help pacify day-to-day collaboration.
>
> Again, "pacify" irks me a bit in this sentence, given I consider
> collaboration has and continues to be cordial in our community, unless
> I've been living under a rock.

“Pacify” in the sense that, by being explicit, we avoid
misunderstandings that could turn into unpleasant experiences.

Like you I’m glad collaboration is nice and friendly; yet, over the past
few months I’ve experienced misunderstandings that seemingly broke the
consensus-based process that has always prevailed.

In a way, that’s probably bound to happen as the group grows, and I
think that’s why we must be explicit about what the process is and about
whether one is expressing consent or dissent.

With so many things happening in Guix (yay!), it’s also easy to overlook
a change and realize when it’s too late.  By having a rule that at least
one other person on the team must approve (consent to) a change, we
reduce that risk.

Being on a team, then, is a way to express interest on a topic and to be
“in the loop”.  It is not about asserting power or building a hierarchy;
it’s about formalizing existing relations and processes.

I hope this clarifies my position!

Ludo’.

Previous Next

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