unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org, 61894@debbugs.gnu.org, guix-maintainers@gnu.org
Subject: [bug#61894] [PATCH RFC] Team approval for patches
Date: Wed, 01 Mar 2023 23:45:27 +0100	[thread overview]
Message-ID: <87r0u86qgo.fsf_-_@gnu.org> (raw)
In-Reply-To: <871qm8wf8e.fsf@cbaines.net> (Christopher Baines's message of "Wed, 01 Mar 2023 17:15:26 +0000")

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

> I guess I'm still a team sceptic, I think the idea is interesting and I
> have added myself as a member of some teams. But the main impact on me
> so far is that I've just been getting some unwanted personal email,
> messages that previously wouldn't have landed in my inbox have been
> doing so.

Same for me (took me a while to understand why I was suddenly Cc’d on
some many patches.  :-))  I’m not sure how to improve on that.

> Regarding this change specifically though, I'm unclear how it would
> impact the things I push for others. I pushed some patches today, would
> this mean that I'd have to look at what team/teams are involved
> (according to /etc/teams.scm.in) for each commit/series, and then either
> continue if I'm a member of that team, or skip it if I'm not?
>
> If I'm going to not be pushing stuff I would have previously pushed
> because I'm not in the relevant teams, maybe I should just add myself to
> every team? I guess this is not a serious question, but I'm more making
> the point that if teams become a formal part of patch review, then some
> formalities over membership of a team is probably a prerequsite.
>
> As a point of clarification, if a patch or series touches files that
> fall within the scope of several teams, am I correct in saying that this
> change would require approval from all teams?

Good questions.

For teams like ‘core’ or ‘home’, there should be no overlap, so it’s
quite easy to see who’s in charge.

Teams related to packages are more likely to overlap, and it’s also an
area where we generally want more flexibility.  The example you
give—pushing patches even though you’re not on the corresponding
team(s)—is something we’d still want to allow most of the time.

There seems to be different requirements depending on teams.  I’d like
more coordination and clearer responsibilities for subsystems (guix/*,
gnu/{services,system,build}/*, etc.) and key packages/tools (Python,
ocaml-build-system, etc.).  For “random packages”, I’m fine with the
status quo.

WDYT?

Thanks,
Ludo’.




  parent reply	other threads:[~2023-03-01 22:46 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 [this message]
2023-03-02 11:04     ` Andreas Enge
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=87r0u86qgo.fsf_-_@gnu.org \
    --to=ludo@gnu.org \
    --cc=61894@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=guix-maintainers@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).