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

Previous Next

Full log

Message #23 received at 61894 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Enge <andreas <at> enge.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: guix-devel <at> gnu.org, Christopher Baines <mail <at> cbaines.net>,
 61894 <at> debbugs.gnu.org, guix-maintainers <at> gnu.org
Subject: Re: bug#61894: [PATCH RFC] Team approval for patches
Date: Thu, 2 Mar 2023 12:04:44 +0100

Hello,

in the current situation I think the suggestion is putting the horse before
the cart. In a first step before adding policy, we should make the teams
functional. While working on core-updates, I have been realising we are
already spread too thin: Some important languages have teams with one or
two members, who would effectively become bottlenecks. Other software has
no team (Qt/KDE). All in all, I also think we have too few committers.
Adding policy might completely stall the project...

If for every trivial update of a Python package we need not only submit a
patch to the bugtracker, wait for QA, get back to the patch, resign it,
push it and close the bug, but additionally wait for one of the two Python
team members to have a look at it (or let an additional week pass),
incentives to participate will tend to zero.

Your suggested policy can help against commits of too bad quality; but I
do not think this is our problem, our problem is rather a lack of fast
progress.

So I think we need to add committers, add committers to teams, encourage
teams to engage in work, and if everything works smoothly, maybe add policy.

Andreas

Previous Next

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