[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Christopher Baines]

I noticed git send-email misbehaving, adding X-Debbugs-Cc headers that I
didn't intend to add. Some patches had X-Debbugs-Cc for myself, which is
irritating to me, and others were worse in that they X-Debbugs-Cc'ed other
people.

* etc/git/gitconfig: Stop affecting sendemail.
---
 etc/git/gitconfig | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/etc/git/gitconfig b/etc/git/gitconfig
index 907ad01804..11b8e40cab 100644
--- a/etc/git/gitconfig
+++ b/etc/git/gitconfig
@@ -11,8 +11,3 @@
 
 [pull]
         rebase = true
-
-[sendemail]
-        to = guix-patches@gnu.org
-        headerCmd = etc/teams.scm cc-members-header-cmd
-        thread = no

base-commit: d54faf155aeeeb2aceb5cc19f141c2b8d0e0720a
prerequisite-patch-id: 012e5db7f524495e0b4c4ee9b652e2aecf03382c
-- 
2.40.1

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Ludovic Courtès]

Hi Chris,

(Cc: Maxim.)

Christopher Baines <mail@cbaines.net> skribis:

> I noticed git send-email misbehaving, adding X-Debbugs-Cc headers that I
> didn't intend to add. Some patches had X-Debbugs-Cc for myself, which is
> irritating to me, and others were worse in that they X-Debbugs-Cc'ed other
> people.
>
> * etc/git/gitconfig: Stop affecting sendemail.

I think it was done on purpose, so that the team responsible for the
code being changed would automatically be notified.

I like the intention, though I understand one might find it a bit
heavy-handed: we end up Cc’ing lots of people (and apparently this
hasn’t resulted in an increase of review work, unfortunately).

So I guess I can sympathize with both arguments in favor and arguments
against this behavior.

Thoughts?

Ludo’.

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Chris,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Chris,
>
> (Cc: Maxim.)
>
> Christopher Baines <mail@cbaines.net> skribis:
>
>> I noticed git send-email misbehaving, adding X-Debbugs-Cc headers that I
>> didn't intend to add. Some patches had X-Debbugs-Cc for myself, which is
>> irritating to me, and others were worse in that they X-Debbugs-Cc'ed other
>> people.
>>
>> * etc/git/gitconfig: Stop affecting sendemail.
>
> I think it was done on purpose, so that the team responsible for the
> code being changed would automatically be notified.

Indeed!  The original idea behind teams was to subscribe to a more
focused scope than the guix-patches list; and commit 1d77fd705b ("doc:
Simplify contributing section by automating git configuration.") made it
ping the teams automatically.  It's documented in info '(guix) Sending a
Patch Series':

   Notifying Teams
   ...............

   If your git checkout has been correctly configured (*note Configuring
   Git::), the ‘git send-email’ command will automatically notify the
   appropriate team members, based on the scope of your changes.  This
   relies on the ‘etc/teams.scm’ script, which can also be invoked
   manually if you do not use the preferred ‘git send-email’ command to
   submit patches.  To list the available actions of the script, you can
   invoke it via the ‘etc/teams.scm help’ command.  For more information
   regarding teams, see *Note Teams::.

> I like the intention, though I understand one might find it a bit
> heavy-handed: we end up Cc’ing lots of people (and apparently this
> hasn’t resulted in an increase of review work, unfortunately).

It did for me in a limited way because I'm only part of the gnome-team
:-).  When Liliana's GNOME patches reach my INBOX I feel compelled to
process them quickly.  I'd otherwise probably easily miss them.

I'd suggest people joining teams only do so if they actually have the
bandwidth to help with the review of the scopes they cover to avoid
feeling overwhelmed.  It's easy to add/remove ourselves to a team.

If you *really* don't want the default configured behavior to happen,
you still can, by adding the '--no-header-cmd' option to your 'git
send-email' invocation, although I'd prefer you use this with a lot of
care, as I want to receive the notifications for the submissions
touching the team I'm subscribed to :-)

If there's something to improve such as not adding a CC to yourself,
that's a good idea and can probably be done in etc/teams.scm.  You can
open an issue for it if you'd like to track its resolution.

Does that clarify things?  If it does and it's acceptable to you, please
close this issue.

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Liliana Marie Prikler]

Am Montag, dem 26.06.2023 um 10:36 -0400 schrieb Maxim Cournoyer:
> > I like the intention, though I understand one might find it a bit
> > heavy-handed: we end up Cc’ing lots of people (and apparently this
> > hasn’t resulted in an increase of review work, unfortunately).
> 
> It did for me in a limited way because I'm only part of the gnome-
> team :-).  When Liliana's GNOME patches reach my INBOX I feel
> compelled to process them quickly.  I'd otherwise probably easily
> miss them.
Funny that you'd mention that because for me, debbugs notifications are
pretty hit or miss.  A lot of them end up filtered by our benevolent
overlords without me having ever read them.

> I'd suggest people joining teams only do so if they actually have the
> bandwidth to help with the review of the scopes they cover to avoid
> feeling overwhelmed.  It's easy to add/remove ourselves to a team.
> 
> If you *really* don't want the default configured behavior to happen,
> you still can, by adding the '--no-header-cmd' option to your 'git
> send-email' invocation, although I'd prefer you use this with a lot
> of care, as I want to receive the notifications for the submissions
> touching the team I'm subscribed to :-)
I feel as though we won't find many members willing to cover a certain
scope if they potentially have to be responsible for all of it.  Like,
despite being a member of the gnome and emacs teams, there are certain
packages within that scope that I'm more familiar with than others.

> If there's something to improve such as not adding a CC to yourself,
> that's a good idea and can probably be done in etc/teams.scm.  You
> can open an issue for it if you'd like to track its resolution.
> 
> Does that clarify things?  If it does and it's acceptable to you,
> please close this issue.
Even with such a hypothetical --exclude-whomever switch added, I'd
argue that it is wrong to magically install this configuration without
any user interaction.  The current setup also causes quite a number of
false positives, like a package rename also causing changes in some
other scope and hence notifying like five different teams all at once.

Cheers

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Montag, dem 26.06.2023 um 10:36 -0400 schrieb Maxim Cournoyer:
>> > I like the intention, though I understand one might find it a bit
>> > heavy-handed: we end up Cc’ing lots of people (and apparently this
>> > hasn’t resulted in an increase of review work, unfortunately).
>> 
>> It did for me in a limited way because I'm only part of the gnome-
>> team :-).  When Liliana's GNOME patches reach my INBOX I feel
>> compelled to process them quickly.  I'd otherwise probably easily
>> miss them.
> Funny that you'd mention that because for me, debbugs notifications are
> pretty hit or miss.  A lot of them end up filtered by our benevolent
> overlords without me having ever read them.

Maybe you are mistaken about what X-Debbugs-CC does; it doesn't cause
someone to be subscribed to a specific issue; it's only a CC alternative
that is a bit nicer in that it will reply with the issue number in the
reply path, which is mostly useful for new issues that haven't gotten a
Debbugs number yet.  So I don't think we should think of it as a
"notification" mechanism, simply a smarter CC for Debbugs.

>> I'd suggest people joining teams only do so if they actually have the
>> bandwidth to help with the review of the scopes they cover to avoid
>> feeling overwhelmed.  It's easy to add/remove ourselves to a team.
>> 
>> If you *really* don't want the default configured behavior to happen,
>> you still can, by adding the '--no-header-cmd' option to your 'git
>> send-email' invocation, although I'd prefer you use this with a lot
>> of care, as I want to receive the notifications for the submissions
>> touching the team I'm subscribed to :-)
> I feel as though we won't find many members willing to cover a certain
> scope if they potentially have to be responsible for all of it.  Like,
> despite being a member of the gnome and emacs teams, there are certain
> packages within that scope that I'm more familiar with than others.

There currently isn't a strong notion of "responsibility" associated
with being in a team (although we could flesh one if people want it, as
Ludo had suggested with the "two team members should gate changes to
their domain by putting their LGTM on it" or similar); it's currently
simply a means to be subscribed to a specific scope of the project, to
be notified on the changes you are most likely to be interested in (and
hopefully comment on/review/commit).

>> If there's something to improve such as not adding a CC to yourself,
>> that's a good idea and can probably be done in etc/teams.scm.  You
>> can open an issue for it if you'd like to track its resolution.
>> 
>> Does that clarify things?  If it does and it's acceptable to you,
>> please close this issue.
> Even with such a hypothetical --exclude-whomever switch added.

It's not hypothetical, it exists and works today (--no-header-cmd).  The
only reason it doesn't appear in 'man git-send-email' is because we
don't build the git doc from source.  It's scheduled to appear in Git
2.41.0 [0]

[0]  https://lore.kernel.org/git/xmqqleh3a3wm.fsf@gitster.g/

> I'd argue that it is wrong to magically install this configuration without
> any user interaction.  The current setup also causes quite a number of
> false positives, like a package rename also causing changes in some
> other scope and hence notifying like five different teams all at once.

I personally prefer the zero-config approach that maximizes the
potential of etc/teams.scm and reduces the documentation burden, but of
course I'm biased :-).  I find the contribution process of Guix already
complicated enough to not want to add more to it, and welcome
automation.

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Liliana Marie Prikler]

Am Dienstag, dem 27.06.2023 um 21:14 -0400 schrieb Maxim Cournoyer:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> > Funny that you'd mention that because for me, debbugs notifications
> > are pretty hit or miss.  A lot of them end up filtered by our
> > benevolent overlords without me having ever read them.
> 
> Maybe you are mistaken about what X-Debbugs-CC does; it doesn't cause
> someone to be subscribed to a specific issue; it's only a CC
> alternative that is a bit nicer in that it will reply with the issue
> number in the reply path, which is mostly useful for new issues that
> haven't gotten a Debbugs number yet.  So I don't think we should
> think of it as a "notification" mechanism, simply a smarter CC for
> Debbugs.
I am not.  Debbugs-CC'd mail simply ends up in the spam folder because
Google sees that

> > 
> > I'd argue that it is wrong to magically install this configuration
> > without any user interaction.  The current setup also causes quite
> > a number of false positives, like a package rename also causing
> > changes in some other scope and hence notifying like five different
> > teams all at once.
> 
> I personally prefer the zero-config approach that maximizes the
> potential of etc/teams.scm and reduces the documentation burden, but
> of course I'm biased :-).  I find the contribution process of Guix
> already complicated enough to not want to add more to it, and welcome
> automation.
There's nothing wrong with automation per se, but you are confusing
automating your own process knowingly with automating someone else's
process without their knowledge or permission.  I'd also argue that
your approach doesn't maximize etc/teams.scm, but rather makes it
exhibit the weirdest behaviours imaginable by applying it blindly.

Cheers

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Dienstag, dem 27.06.2023 um 21:14 -0400 schrieb Maxim Cournoyer:
>> Hi Liliana,
>> 
>> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
>> > Funny that you'd mention that because for me, debbugs notifications
>> > are pretty hit or miss.  A lot of them end up filtered by our
>> > benevolent overlords without me having ever read them.
>> 
>> Maybe you are mistaken about what X-Debbugs-CC does; it doesn't cause
>> someone to be subscribed to a specific issue; it's only a CC
>> alternative that is a bit nicer in that it will reply with the issue
>> number in the reply path, which is mostly useful for new issues that
>> haven't gotten a Debbugs number yet.  So I don't think we should
>> think of it as a "notification" mechanism, simply a smarter CC for
>> Debbugs.
> I am not.  Debbugs-CC'd mail simply ends up in the spam folder because
> Google sees that

OK, odd; I haven't noticed that kind of filtering using gmail.

>> > 
>> > I'd argue that it is wrong to magically install this configuration
>> > without any user interaction.  The current setup also causes quite
>> > a number of false positives, like a package rename also causing
>> > changes in some other scope and hence notifying like five different
>> > teams all at once.
>> 
>> I personally prefer the zero-config approach that maximizes the
>> potential of etc/teams.scm and reduces the documentation burden, but
>> of course I'm biased :-).  I find the contribution process of Guix
>> already complicated enough to not want to add more to it, and welcome
>> automation.
> There's nothing wrong with automation per se, but you are confusing
> automating your own process knowingly with automating someone else's
> process without their knowledge or permission.  I'd also argue that
> your approach doesn't maximize etc/teams.scm, but rather makes it
> exhibit the weirdest behaviours imaginable by applying it blindly.

What is weird?  People opt to be in a team to be notified; the default
git configuration when submitting patches causes the submission to
notify them when appropriate.  I don't understand how that qualifies as
as the "weirdest behaviour imaginable" ?

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Liliana Marie Prikler]

Am Freitag, dem 30.06.2023 um 23:03 -0400 schrieb Maxim Cournoyer:
> > There's nothing wrong with automation per se, but you are confusing
> > automating your own process knowingly with automating someone
> > else's process without their knowledge or permission.  I'd also
> > argue that your approach doesn't maximize etc/teams.scm, but rather
> > makes it exhibit the weirdest behaviours imaginable by applying it
> > blindly.
> 
> What is weird?  People opt to be in a team to be notified; the
> default git configuration when submitting patches causes the
> submission to notify them when appropriate.  I don't understand how
> that qualifies as as the "weirdest behaviour imaginable" ?
It's about the sending end rather than the receiving end, really.  As a
sender, if you have a series that "invades" the territory of several
teams, each will get CC'd exactly on the patches that overlap with
them.  I argue, that this is the worst possible configuration.

For a recent example, Christopher sent a series that just renames ruby
everywhere.  I got 08/24 because gnome-team receives changes to webkit.
As a member of gnome-team I said LGTM, but I really only had that one
mail to go of.  If I don't investigate the full series, Christopher
could have introduced a wrong ruby here; either by accident (typo) or
maliciously, and no you wouldn't catch on from that single mail.

Thus, at the very least, the cover letter ought to go to all teams who
have major stakes in any particular patch.  But here's the second
thing: gnome-team doesn't have major stakes in a minor patch out of
twenty-four.

With the current automation in place, users unknowingly and without
ever intending to alert team attention to where it wouldn't be needed
in a manner that leaves major context clues to be found in the aether.
I don't think this "maximizes" the potential of teams in any way
whatsoever.

Cheers

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Freitag, dem 30.06.2023 um 23:03 -0400 schrieb Maxim Cournoyer:
>> > There's nothing wrong with automation per se, but you are confusing
>> > automating your own process knowingly with automating someone
>> > else's process without their knowledge or permission.  I'd also
>> > argue that your approach doesn't maximize etc/teams.scm, but rather
>> > makes it exhibit the weirdest behaviours imaginable by applying it
>> > blindly.
>> 
>> What is weird?  People opt to be in a team to be notified; the
>> default git configuration when submitting patches causes the
>> submission to notify them when appropriate.  I don't understand how
>> that qualifies as as the "weirdest behaviour imaginable" ?
> It's about the sending end rather than the receiving end, really.  As a
> sender, if you have a series that "invades" the territory of several
> teams, each will get CC'd exactly on the patches that overlap with
> them.  I argue, that this is the worst possible configuration.
>
> For a recent example, Christopher sent a series that just renames ruby
> everywhere.  I got 08/24 because gnome-team receives changes to webkit.
> As a member of gnome-team I said LGTM, but I really only had that one
> mail to go of.  If I don't investigate the full series, Christopher
> could have introduced a wrong ruby here; either by accident (typo) or
> maliciously, and no you wouldn't catch on from that single mail.

Maybe we just need to agree that each patch should have a LGTM unless
the reviewer explicitly mentioned e.g. "LGTM for this patch and the
previous ones".  I believe that's already the way most reviewers
understand it but documenting this explicitly wouldn't hurt.  Then even
if you review a single patch with no context your LGTM can still be
useful for that single patch and not taken erroneously as an overall
badge of approval.

> Thus, at the very least, the cover letter ought to go to all teams who
> have major stakes in any particular patch.  But here's the second
> thing: gnome-team doesn't have major stakes in a minor patch out of
> twenty-four.
>
> With the current automation in place, users unknowingly and without
> ever intending to alert team attention to where it wouldn't be needed
> in a manner that leaves major context clues to be found in the aether.
> I don't think this "maximizes" the potential of teams in any way
> whatsoever.

I think patches touching overlapping scopes will be the edge case rather
than the common one, so I don't see it as a serious issue, especially if
we explicit the LGTM as suggested above.

What do you think?

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Ludovic Courtès]

Hi,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Even with such a hypothetical --exclude-whomever switch added, I'd
> argue that it is wrong to magically install this configuration without
> any user interaction.

Maybe that’s the main grief: that the new config was suddenly installed
without fellow hackers realizing it (I, for one, wondered initially what
magic made ‘git send-email’ Cc: all my friends :-)).

Perhaps one way out is to suggest it in the manual without installing it
automatically?  WDYT, Maxim?

(Independently of that, we’ll have to discuss patch review again.  We
believed one problem was that potential reviewers wouldn’t notice
patches in their area.  That’s arguably no longer the case, yet this
hasn’t had any noticeable effect in terms of review activity.  How
should we approach that?)

Thanks,
Ludo’.

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
>> Even with such a hypothetical --exclude-whomever switch added, I'd
>> argue that it is wrong to magically install this configuration without
>> any user interaction.
>
> Maybe that’s the main grief: that the new config was suddenly installed
> without fellow hackers realizing it (I, for one, wondered initially what
> magic made ‘git send-email’ Cc: all my friends :-)).
>
> Perhaps one way out is to suggest it in the manual without installing it
> automatically?  WDYT, Maxim?

I still think it has more value by being automatically installed, as
that way the pre-push hook that prevents unsigned commit is also
configured automatically, and new contributors would be likely to not
have it configured (by having missed it from the manual).

I see this similar to the .dir-locals.el file that automatically setups
(there's a prompt, but its design forces you into accepting it or being
repeatedly bothered ad aeternam).

If there are concrete issues with it, I think we should a) report them
and b) look into fixing them.

> (Independently of that, we’ll have to discuss patch review again.  We
> believed one problem was that potential reviewers wouldn’t notice
> patches in their area.  That’s arguably no longer the case, yet this
> hasn’t had any noticeable effect in terms of review activity.  How
> should we approach that?)

The teams are still nascent, and it's summer time.  I think we need to
give it some time and encourage more people to join or create new teams
and get familiar with the recently introduced/documented branch-based
updates :-).

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Liliana Marie Prikler]

Am Donnerstag, dem 06.07.2023 um 11:49 -0400 schrieb Maxim Cournoyer:
> Hi Ludo,
> 
> Ludovic Courtès <ludo@gnu.org> writes:
> 
> > Hi,
> > 
> > Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> > 
> > > Even with such a hypothetical --exclude-whomever switch added,
> > > I'd argue that it is wrong to magically install this
> > > configuration without any user interaction.
> > 
> > Maybe that’s the main grief: that the new config was suddenly
> > installed without fellow hackers realizing it (I, for one, wondered
> > initially what magic made ‘git send-email’ Cc: all my friends :-)).
> > 
> > Perhaps one way out is to suggest it in the manual without
> > installing it automatically?  WDYT, Maxim?
> 
> I still think it has more value by being automatically installed, as
> that way the pre-push hook that prevents unsigned commit is also
> configured automatically, and new contributors would be likely to not
> have it configured (by having missed it from the manual).
> 
> I see this similar to the .dir-locals.el file that automatically
> setups (there's a prompt, but its design forces you into accepting it
> or being repeatedly bothered ad aeternam).
There is also a way of enforcing a "no", though.  And in particular,
the version-controlled .dir-locals.el has only been really supported
since the introduction of .dir-locals-2.el, which allows local changes.

> If there are concrete issues with it, I think we should a) report
> them and b) look into fixing them.
Such as the concrete issue that it changes our workflow without asking?
Mind you, that I'm only not affected because I've been format-patching
manually for a long time at this point.

Cheers

> 

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

>> If there are concrete issues with it, I think we should a) report
>> them and b) look into fixing them.
> Such as the concrete issue that it changes our workflow without
> asking?

The suggestion to notify team members was only recently introduced in
8fed83 (doc: contributing: Expand "Sending a Patch Series".)  1d77fd
("doc: Simplify contributing section by automating git configuration.")
made it happen transparently by default.  You can still use 'git
send-email --no-header-cmd' if you really must disable the new behavior.

> Mind you, that I'm only not affected because I've been format-patching
> manually for a long time at this point.

Not that the pre-configured header-cmd ("etc/teams.scm
cc-members-header-cmd") gets used when you invoke 'git send-email'; it
doesn't matter if the patches were 'git patch-format'd manually before
or not.

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Ludovic Courtès]

Hello!

It just occurred to me that we might have a reasonable tradeoff at hand:
instead of adding Cc: or X-Debbugs-Cc: headers, we could add, say,
X-Guix-Team: headers.  That way, team members would be free to filter
incoming messages however they want.

How does that sound?

Of course if team members don’t pay attention to that header, we’re back
to square one, but hopefully that won’t be the case.

Ludo’.

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Liliana Marie Prikler]

Am Montag, dem 10.07.2023 um 23:21 +0200 schrieb Ludovic Courtès:
> Hello!
> 
> It just occurred to me that we might have a reasonable tradeoff at
> hand: instead of adding Cc: or X-Debbugs-Cc: headers, we could add,
> say, X-Guix-Team: headers.  That way, team members would be free to
> filter incoming messages however they want.
> 
> How does that sound?
> 
> Of course if team members don’t pay attention to that header, we’re
> back to square one, but hopefully that won’t be the case.
But how would that header work in practice?  Assuming the mails aren't
automatically forwarded, we would need another interface, e.g. mumi to
handle it.  Plus, the issue of tagging a single patch in a series would
still apply, would it not?

Cheers

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Ludovic Courtès]

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Montag, dem 10.07.2023 um 23:21 +0200 schrieb Ludovic Courtès:
>> Hello!
>> 
>> It just occurred to me that we might have a reasonable tradeoff at
>> hand: instead of adding Cc: or X-Debbugs-Cc: headers, we could add,
>> say, X-Guix-Team: headers.  That way, team members would be free to
>> filter incoming messages however they want.
>> 
>> How does that sound?
>> 
>> Of course if team members don’t pay attention to that header, we’re
>> back to square one, but hopefully that won’t be the case.
> But how would that header work in practice?  Assuming the mails aren't
> automatically forwarded, we would need another interface, e.g. mumi to
> handle it.  Plus, the issue of tagging a single patch in a series would
> still apply, would it not?

Hi!  The header in itself wouldn’t have any effect: it’s up to
recipients to configure their email client to filter messages as they
see fit.  So in that sense it’d be less intrusive.

Mumi could also display a tag based on this and let people select only
issues relevant to a specific team.  That would be an improvement over
what we have.

Thoughts?

Ludo’.

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Liliana Marie Prikler]

Am Freitag, dem 14.07.2023 um 15:21 +0200 schrieb Ludovic Courtès:
> Hi!  The header in itself wouldn’t have any effect: it’s up to
> recipients to configure their email client to filter messages as they
> see fit.  So in that sense it’d be less intrusive.
IMHO, it'd be as intrusive as before on the sending end, but less
visible; we still get the same false positives, but we'd be displaying
them somewhere instead of sending out mails.  That would be less
annoying on the receiving end, but mumi's search already isn't that
great and I don't think automatic subpar tagging would improve it.

> Thoughts?

I think what we really need here is not a dumb tool that just stamps a
bunch of patches in some way, but one that is aware of the context of a
series.  Does a significant number of patches touch files associated
with some team?  Flag it.  Are there any packages that cause a high
number of rebuilds?  Mention the X-team branch.  I also think the tool
ought to explain what it does (perhaps offering a flag to skip
explanations for expert users) and be accompanied with proper
documentation for a manual workflow on which it is based.

Cheers

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
>> Am Montag, dem 10.07.2023 um 23:21 +0200 schrieb Ludovic Courtès:
>>> Hello!
>>> 
>>> It just occurred to me that we might have a reasonable tradeoff at
>>> hand: instead of adding Cc: or X-Debbugs-Cc: headers, we could add,
>>> say, X-Guix-Team: headers.  That way, team members would be free to
>>> filter incoming messages however they want.
>>> 
>>> How does that sound?
>>> 
>>> Of course if team members don’t pay attention to that header, we’re
>>> back to square one, but hopefully that won’t be the case.
>> But how would that header work in practice?  Assuming the mails aren't
>> automatically forwarded, we would need another interface, e.g. mumi to
>> handle it.  Plus, the issue of tagging a single patch in a series would
>> still apply, would it not?
>
> Hi!  The header in itself wouldn’t have any effect: it’s up to
> recipients to configure their email client to filter messages as they
> see fit.  So in that sense it’d be less intrusive.

It could perhaps be used *in addition* to the X-Debbugs-CC headers, but
I don't see it as a replacement, because e.g. for a single patch send
directly to guix-patches@gnu.org, X-Debbugs-CC does the nice thing of
retrieving the bug ID and adding its corresponding email into the
forwarded mail, so that users see which bug the mail was attached to.

> Mumi could also display a tag based on this and let people select only
> issues relevant to a specific team.  That would be an improvement over
> what we have.
>
> Thoughts?

I am still not convinced something deserves to be changed here; the
problems reported so far, unless I'm missing something, were:

1. It's weird that send-email cause people to be CC'd itself
2. It can be confusing when a larger series touches multiple teams

I think 1. mostly results from the initial surprise that send-email now
behaves that way, but I don't see how it's a bad behavior to reach out
to team members automatically.  The process being automated should yield
the same result as if a user called the etc/teams.scm script and placed
the --add-header arguments themselves.

2. Is more of an edge case.  I think if we have a policy of adding a
LGTM *per patch* or 'LGTM for whole the series' it'd solve the immediate
concern.  Having a X-Guix-Team as proposed by Ludo *also* added could
provide a bit more context in doubt.

I'd be interested to hear back from Chris, which originally opened
issue, in light of the above.

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

[...]

> I think what we really need here is not a dumb tool that just stamps a
> bunch of patches in some way, but one that is aware of the context of a
> series.  Does a significant number of patches touch files associated
> with some team?  Flag it.  Are there any packages that cause a high
> number of rebuilds?  Mention the X-team branch.  I also think the tool
> ought to explain what it does (perhaps offering a flag to skip
> explanations for expert users) and be accompanied with proper
> documentation for a manual workflow on which it is based.

We already have such a tool: 'mumi send-email'.  It also makes use of
the etc/teams.scm script, so of the tagging is of bad quality, we should
fix it there.

-- 
Thanks,
Maxim

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Christopher Baines]

[-- Attachment #1: Type: text/plain, Size: 1975 bytes --]


Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

>> Mumi could also display a tag based on this and let people select only
>> issues relevant to a specific team.  That would be an improvement over
>> what we have.
>>
>> Thoughts?
>
> I am still not convinced something deserves to be changed here; the
> problems reported so far, unless I'm missing something, were:
>
> 1. It's weird that send-email cause people to be CC'd itself
> 2. It can be confusing when a larger series touches multiple teams
>
> I think 1. mostly results from the initial surprise that send-email now
> behaves that way, but I don't see how it's a bad behavior to reach out
> to team members automatically.  The process being automated should yield
> the same result as if a user called the etc/teams.scm script and placed
> the --add-header arguments themselves.
>
> 2. Is more of an edge case.  I think if we have a policy of adding a
> LGTM *per patch* or 'LGTM for whole the series' it'd solve the immediate
> concern.  Having a X-Guix-Team as proposed by Ludo *also* added could
> provide a bit more context in doubt.
>
> I'd be interested to hear back from Chris, which originally opened
> issue, in light of the above.

On the 2nd point above, I've also felt the effects of the other side,
where it's irritating that mail that used to be on mailing lists has
moved in to my inbox. I can still automatically file away the initial
email, but then people typically CC me directly when replying.

I'm obviously OK with this when people directly want my input or if I'm
already involved in the conversation, but this CC thing has extended
that to most/any patch submissions that are detected overlapping with
teams I'm in.

Maybe this is just because of the email address I used for teams. I've
now gone and changed this from mail@cbaines.net to guix@cbaines.net,
which comes to the same place, but I'll hopefully be able to use the
different address to separate out the emails appropriately.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]

[bug#64151] [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi Chris,

Christopher Baines <mail@cbaines.net> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>>> Mumi could also display a tag based on this and let people select only
>>> issues relevant to a specific team.  That would be an improvement over
>>> what we have.
>>>
>>> Thoughts?
>>
>> I am still not convinced something deserves to be changed here; the
>> problems reported so far, unless I'm missing something, were:
>>
>> 1. It's weird that send-email cause people to be CC'd itself
>> 2. It can be confusing when a larger series touches multiple teams
>>
>> I think 1. mostly results from the initial surprise that send-email now
>> behaves that way, but I don't see how it's a bad behavior to reach out
>> to team members automatically.  The process being automated should yield
>> the same result as if a user called the etc/teams.scm script and placed
>> the --add-header arguments themselves.
>>
>> 2. Is more of an edge case.  I think if we have a policy of adding a
>> LGTM *per patch* or 'LGTM for whole the series' it'd solve the immediate
>> concern.  Having a X-Guix-Team as proposed by Ludo *also* added could
>> provide a bit more context in doubt.
>>
>> I'd be interested to hear back from Chris, which originally opened
>> issue, in light of the above.
>
> On the 2nd point above, I've also felt the effects of the other side,
> where it's irritating that mail that used to be on mailing lists has
> moved in to my inbox. I can still automatically file away the initial
> email, but then people typically CC me directly when replying.
>
> I'm obviously OK with this when people directly want my input or if I'm
> already involved in the conversation, but this CC thing has extended
> that to most/any patch submissions that are detected overlapping with
> teams I'm in.

Notifying team members of a patch touching their scope is the intended
behavior of the teams mechanism.

> Maybe this is just because of the email address I used for teams. I've
> now gone and changed this from mail@cbaines.net to guix@cbaines.net,
> which comes to the same place, but I'll hopefully be able to use the
> different address to separate out the emails appropriately.

Of course this behavior now being automated, if you are part of many
teams, the amount of emails reaching your inbox may be higher than it
used to be.  If the flux is too large for you to process, I'd recommend
you review and perhaps trim your current teams subscription.  One of the
expected side-effect of notifying team members with etc/teams.scm is
that it should improve reviews.  Keeping our team scopes more focus (and
encouraging active participation of new team members) should help reduce
the load in the long run.

-- 
Thanks,
Maxim

bug#64151: [PATCH] etc: Stop making sendemail behave strangely.

[Maxim Cournoyer]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

[...]

>> I'm obviously OK with this when people directly want my input or if I'm
>> already involved in the conversation, but this CC thing has extended
>> that to most/any patch submissions that are detected overlapping with
>> teams I'm in.
>
> Notifying team members of a patch touching their scope is the intended
> behavior of the teams mechanism.
>
>> Maybe this is just because of the email address I used for teams. I've
>> now gone and changed this from mail@cbaines.net to guix@cbaines.net,
>> which comes to the same place, but I'll hopefully be able to use the
>> different address to separate out the emails appropriately.
>
> Of course this behavior now being automated, if you are part of many
> teams, the amount of emails reaching your inbox may be higher than it
> used to be.  If the flux is too large for you to process, I'd recommend
> you review and perhaps trim your current teams subscription.  One of the
> expected side-effect of notifying team members with etc/teams.scm is
> that it should improve reviews.  Keeping our team scopes more focus (and
> encouraging active participation of new team members) should help reduce
> the load in the long run.

Are you OK with closing this issue?

-- 
Thanks,
Maxim