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

Previous Next

Package: guix-patches;

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


View this message in rfc822 format

From: bokr <at> bokr.com
To: Andreas Enge <andreas <at> enge.fr>
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: [bug#61894] [PATCH RFC] Team approval for patches
Date: Thu, 2 Mar 2023 14:57:58 +0100
Hi,
tl;dr:
    If you want to expand the list of committers rapidly,
    would it make sense to have a sand-box repo for new committers
    which trusted committers could channel cherry-picks from?

    Pick your bugaboo, but I consider plausible that some
    volunteering committers are there on paid job assignment
    serving some agenda which you can't easily discover.

    Well, that can be good and normal with FLOSS-enlightened emplayers,
    but one can imagine not-so-benevolent assignments...
    (pick your concept of benevolence :)

On +2023-03-02 12:04:44 +0100, Andreas Enge wrote:
> 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
> 
> 
--
Regards,
Bengt Richter




This bug report was last modified 2 years and 45 days ago.

Previous Next


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