[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: Tue, 07 Mar 2023 13:29:51 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)

Hi Simon,

Simon Tournier <> writes:

> Hi,
> On Tue, 07 Mar 2023 at 11:36, Andreas Enge <> 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/, 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

1. Our pool of reviewers would likely continue to be spread too thin.

2. The 2 weeks time window would quickly slip, even with a team looking
at a more focused backlog, or the reviews would only be of the kind "I
think that's not what we want" without more time or energy to offer the
kind of concrete insights that can be turned into action for the

3. The team member might be tempted to take their chance and merge their
change with little to no feedback, or feedback they perceived
insufficient or not actionable enough to justify keeping their
submission in limbo for longer.

I think the main problem we have is social, not organizational.  There's
little incentive to jump into the laborious review process compared to
hack on something we like in our free time.  We need to promote and
value review work more, without making it feel like a compulsory chore.
That's a great challenge to solve for a project that's driven by

I'll venture a suggestion to explore: adding enticements to review (some
playful guidelines such as "while waiting for your 2 weeks review
period, please try to review twice as many other submissions that have
been patiently waiting on the patches tracker :-)", or some stats
crunched and advertised periodically to guix-devel or even our to our
blog about our top reviewers, etc.).


reply via email to

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