unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: bokr@bokr.com
To: Andreas Enge <andreas@enge.fr>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
	"Christopher Baines" <mail@cbaines.net>,
	guix-devel@gnu.org, 61894@debbugs.gnu.org,
	guix-maintainers@gnu.org
Subject: Re: bug#61894: [PATCH RFC] Team approval for patches
Date: Thu, 2 Mar 2023 14:57:58 +0100	[thread overview]
Message-ID: <20230302135758.GA40729@LionPure> (raw)
In-Reply-To: <ZACCzGx70IiN3eIc@jurong>

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


  reply	other threads:[~2023-03-02 13:58 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-01 16:13 [bug#61894] [PATCH RFC] Team approval for patches Ludovic Courtès
2023-03-01 17:15 ` Christopher Baines
2023-03-01 17:59   ` Björn Höfling
2023-03-01 18:17     ` Christopher Baines
2023-03-01 19:21   ` Felix Lechner via Guix-patches via
2023-03-01 22:45   ` Ludovic Courtès
2023-03-02 11:04     ` Andreas Enge
2023-03-02 13:57       ` bokr [this message]
2023-03-03  1:08       ` bug#61894: " 宋文武
2023-03-07  1:53     ` [bug#61894] " 宋文武 via Guix-patches via
2023-03-07 10:36       ` bug#61894: " Andreas Enge
2023-03-07 12:22         ` Simon Tournier
2023-03-07 18:29           ` [bug#61894] " Maxim Cournoyer
2023-03-07 22:40             ` Leo Famulari
2023-03-08 18:58               ` bug#61894: " Maxim Cournoyer
2023-03-09  8:48                 ` [bug#61894] " Simon Tournier
2023-03-08  9:12             ` bug#61894: " Efraim Flashner
2023-03-08 17:05               ` Maxim Cournoyer
2023-03-08 23:38                 ` Vagrant Cascadian
2023-03-09  5:12                   ` Maxim Cournoyer
2023-03-09  9:46                 ` Simon Tournier
2023-03-10  4:36                   ` Maxim Cournoyer
2023-03-10 17:22                     ` Ludovic Courtès
2023-03-10 18:22                       ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-03-12  2:33                         ` Maxim Cournoyer
2023-03-12 11:14                           ` Simon Tournier
2023-03-12  3:26                       ` Maxim Cournoyer
2023-03-12 11:52                         ` Andreas Enge
2023-03-13  0:08                           ` Maxim Cournoyer
2023-03-12 12:25                         ` Simon Tournier
2023-03-15 16:08                         ` Ludovic Courtès
2023-03-17 15:46                           ` [bug#61894] " Maxim Cournoyer
2023-03-10 14:19                   ` bug#61894: " Andreas Enge
2023-03-10 17:33                     ` Simon Tournier
2023-03-10 23:19                       ` Andreas Enge
2023-03-11 13:20                         ` Simon Tournier
2023-03-07 15:21         ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2023-03-06 15:48 ` [bug#61894] " Maxim Cournoyer
2023-03-06 21:42   ` Ludovic Courtès
2023-06-02 13:50 ` bug#61894: " Ludovic Courtès
  -- strict thread matches above, loose matches on Subject: below --
2023-03-13 16:30 Peter Polidoro
2023-03-14 15:58 ` Maxim Cournoyer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230302135758.GA40729@LionPure \
    --to=bokr@bokr.com \
    --cc=61894@debbugs.gnu.org \
    --cc=andreas@enge.fr \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@gnu.org \
    --cc=ludo@gnu.org \
    --cc=mail@cbaines.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).