[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