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

Previous Next

Full log

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

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Andreas Enge <andreas <at> enge.fr>, 宋文武 <iyzsong <at> envs.net>
Cc: guix-devel <at> gnu.org, Ludovic Courtès <ludo <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: Tue, 07 Mar 2023 13:22:05 +0100

Hi,

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

Somehow, we have a bootstrap problem – bootstrap is everywhere. ;-)

From my understanding, Ludo’s proposal is about some structure of how
“teams“ would work and that structure would help in constituting
“teams”.  One way for bootstrapping.

From my understanding, the other approach somehow proposed between the
lines in this thread would be to first constitute “teams” and then
document how they work.  The other way for bootstrapping.

While I am not convinced by Ludo’s patch, I think the approach to
document first how we would like the “teams” would work is better for
bootstrapping them.

Cheers,
simon

Previous Next

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