GNU bug report logs -
#61894
[PATCH RFC] Team approval for patches
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Wed, 1 Mar 2023 16:14:02 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #56 received at 61894 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Mar 07, 2023 at 01:29:51PM -0500, Maxim Cournoyer wrote:
> Hi Simon,
>
> Simon Tournier <zimon.toutoune <at> gmail.com> writes:
>
> > 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. :-)
>
> 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.
> 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
> submitter.
>
> 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
> volunteers.
>
> 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.).
>
> --
> Maxim
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 2 years and 44 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.