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

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





  reply	other threads:[~2023-03-02 11:05 UTC|newest]

Thread overview: 40+ 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 [this message]
2023-03-02 13:57       ` bug#61894: " bokr
2023-03-03  1:08       ` 宋文武
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

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=ZACCzGx70IiN3eIc@jurong \
    --to=andreas@enge.fr \
    --cc=61894@debbugs.gnu.org \
    --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).