diff mbox series

maint: Tweak comment in mailmap to sound friendlier

Message ID 20230926203946.3303600-2-eblake@redhat.com
State New
Headers show
Series maint: Tweak comment in mailmap to sound friendlier | expand

Commit Message

Eric Blake Sept. 26, 2023, 8:39 p.m. UTC
From: Eric Blake <eblake@redhat.com>

Documenting that we should not add new lines to work around SPF
rewrites sounds foreboding; the intent is instead that new lines here
are okay, but indicate a second problem elsewhere in our build process
that we should also consider fixing at the same time, to keep the
section from growing without bounds.

Mentioning DMARC alongside SPF may also help people grep for this
scenario, as well as documenting the 'git config' workaround that can
be used by submitters to avoid the munging issue in the first place.

Fixes: 3bd2608d ("maint: Add .mailmap entries for patches claiming list authorship")
CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Eric Blake <eblake@redhat.com>
---

I'm sending this email with a temporary 'git config sendemail.from
eblake@redhat.com', to see if the added advice actually adds the extra
line. It did not show up in my editor window, though, so this patch
may need further tweaking to get the instructions right.  Since I
don't normally suffer from SPF/DMARC munging, I may not be the best
person to test the right workaround.  Or maybe 'git config' does not
yet have the right workaround already available as a turnkey solution
we can suggest.

 .mailmap | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

Comments

Peter Maydell Sept. 27, 2023, 9:21 a.m. UTC | #1
On Tue, 26 Sept 2023 at 21:41, <eblake@redhat.com> wrote:
>
> From: Eric Blake <eblake@redhat.com>
>
> Documenting that we should not add new lines to work around SPF
> rewrites sounds foreboding; the intent is instead that new lines here
> are okay, but indicate a second problem elsewhere in our build process
> that we should also consider fixing at the same time, to keep the
> section from growing without bounds.
>
> Mentioning DMARC alongside SPF may also help people grep for this
> scenario, as well as documenting the 'git config' workaround that can
> be used by submitters to avoid the munging issue in the first place.
>
> Fixes: 3bd2608d ("maint: Add .mailmap entries for patches claiming list authorship")
> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
>
> I'm sending this email with a temporary 'git config sendemail.from
> eblake@redhat.com', to see if the added advice actually adds the extra
> line. It did not show up in my editor window, though, so this patch
> may need further tweaking to get the instructions right.  Since I
> don't normally suffer from SPF/DMARC munging, I may not be the best
> person to test the right workaround.  Or maybe 'git config' does not
> yet have the right workaround already available as a turnkey solution
> we can suggest.

Well, the From: line appeared in my copy of the email, so I guess it works.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM
Andrey Drobyshev Sept. 27, 2023, 10:34 a.m. UTC | #2
On 9/26/23 23:39, eblake@redhat.com wrote:
> From: Eric Blake <eblake@redhat.com>
> 
> Documenting that we should not add new lines to work around SPF
> rewrites sounds foreboding; the intent is instead that new lines here
> are okay, but indicate a second problem elsewhere in our build process
> that we should also consider fixing at the same time, to keep the
> section from growing without bounds.
> 
> Mentioning DMARC alongside SPF may also help people grep for this
> scenario, as well as documenting the 'git config' workaround that can
> be used by submitters to avoid the munging issue in the first place.
> 
> Fixes: 3bd2608d ("maint: Add .mailmap entries for patches claiming list authorship")
> CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> Cc: Peter Maydell <peter.maydell@linaro.org>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> 
> I'm sending this email with a temporary 'git config sendemail.from
> eblake@redhat.com', to see if the added advice actually adds the extra
> line. It did not show up in my editor window, though, so this patch
> may need further tweaking to get the instructions right.  Since I
> don't normally suffer from SPF/DMARC munging, I may not be the best
> person to test the right workaround.  Or maybe 'git config' does not
> yet have the right workaround already available as a turnkey solution
> we can suggest.
> 

The only drawback of this approach is that mail clients, as well as
tools like patchew.org now only show your "<email>" in From/Author
field.  You can see it here:

https://patchew.org/search?q=project%3AQEMU+from%3ABlake

In your email there're 2 "From:" fields now:

> Headers...
> From: eblake@redhat.com
> More headers...
> From: Eric Blake <eblake@redhat.com>
> Actual patch

Apparently, mail clients prefer to pay attention on the very first
"From:" entry, while tools like "git am" -- on the last.  If we managed
to make those entries both be in the format "name <email>" -- that'd be
ideal.  However, as I pointed out in another thread, if we set
sendemail.from to "name <email>", the 2nd entry doesn't get added since
they're now identical.  So you figure out the way to get 2 identical
"From:" entries -- please let us know.

Having all that said, it would still be nice to have additional checks
for "qemu-block@nongnu.org" authorship, as Peter mentioned in the
previous thread.

Andrey
Eric Blake Sept. 27, 2023, 2:06 p.m. UTC | #3
On Wed, Sep 27, 2023 at 01:34:40PM +0300, Andrey Drobyshev wrote:
> On 9/26/23 23:39, eblake@redhat.com wrote:
> > From: Eric Blake <eblake@redhat.com>
> > 
> > Documenting that we should not add new lines to work around SPF
> > rewrites sounds foreboding; the intent is instead that new lines here
> > are okay, but indicate a second problem elsewhere in our build process
> > that we should also consider fixing at the same time, to keep the
> > section from growing without bounds.
> > 
> > Mentioning DMARC alongside SPF may also help people grep for this
> > scenario, as well as documenting the 'git config' workaround that can
> > be used by submitters to avoid the munging issue in the first place.
> > 
> > Fixes: 3bd2608d ("maint: Add .mailmap entries for patches claiming list authorship")
> > CC: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
> > Cc: Peter Maydell <peter.maydell@linaro.org>
> > Signed-off-by: Eric Blake <eblake@redhat.com>
> > ---
> > 
> > I'm sending this email with a temporary 'git config sendemail.from
> > eblake@redhat.com', to see if the added advice actually adds the extra
> > line. It did not show up in my editor window, though, so this patch
> > may need further tweaking to get the instructions right.  Since I
> > don't normally suffer from SPF/DMARC munging, I may not be the best
> > person to test the right workaround.  Or maybe 'git config' does not
> > yet have the right workaround already available as a turnkey solution
> > we can suggest.
> > 
> 
> The only drawback of this approach is that mail clients, as well as
> tools like patchew.org now only show your "<email>" in From/Author
> field.  You can see it here:
> 
> https://patchew.org/search?q=project%3AQEMU+from%3ABlake

Indeed.  But I think I know more now, so I'll try something slightly
different in v2.

> 
> In your email there're 2 "From:" fields now:
> 
> > Headers...
> > From: eblake@redhat.com
> > More headers...
> > From: Eric Blake <eblake@redhat.com>
> > Actual patch

Not quite - if you read the raw email, notice the blank line, which
separate true headers from the body.  That is, the headers are:

| From: eblake@redhat.com
| More headers...
| Subject:

while the body starts:

| From: Eric Blake <eblake@redhat.com>
| 
| rest of actual patch

'git am' is already smart enough to prioritize the body's From: line
over mail headers when re-creating authorship for a patch being
imported into a maintainer's tree.  But patchew currently favors the
email headers in its attributions.

> 
> Apparently, mail clients prefer to pay attention on the very first
> "From:" entry, while tools like "git am" -- on the last.  If we managed
> to make those entries both be in the format "name <email>" -- that'd be
> ideal.  However, as I pointed out in another thread, if we set
> sendemail.from to "name <email>", the 2nd entry doesn't get added since
> they're now identical.  So you figure out the way to get 2 identical
> "From:" entries -- please let us know.

My current working theory (to be tested in my upcoming v2 posting) is
that git compares two values: the author attribution (composed from
'git config user.name' and 'git config user.email'), and the sendemail
attribution (directly from 'git config sendemail.from').  If the two
differ, then git format-email produces the one-liner 'From: real
author <real@email>' based on commit authorship info as the first line
in the body of the message; if they are the same (including when
sendemail.from is missing, so git assumes you are sending your own
patch and that your MUA will supply the same name), the body line is
omitted.  Meanwhile, when git feeds a file into sendemail, it omits a
From: header by default (relying on your MUA to supply one - and your
MUA probably picks the same spelling as your authorship), but includes
a From: header (which generally overrides your MUA's default) verbatim
from sendemail.from if that was set, regardless of commit authorship
info.

That would explain whey when you set sendemail.from to list your full
name and email, you didn't get a body From: line.  And when you omit
the real name in sendemail.from, the two definitely differ, so git
includes the body From: (I just demonstrated that when I posted this
v1).  But it may still be possible to force author attribution to be
slightly different to sendemail.from, but still having a name in the
From: line, so that patchew doesn't see a bare email without a name,
all by intentionally spelling things differently.  So my attempt for
my v2 patch, my settings will be:

[user]
        name = Eric Blake
        email = eblake@redhat.com
[sendemail]
        from = "Eric Blake" <eblake@redhat.com>

with the hope that the addition of quotes (a semantic no-op from
email's point of view, but a different spelling from git's point of
view) would be enough to cause git send-email to include a body From:
line.  Fingers crossed while I test it...

> 
> Having all that said, it would still be nice to have additional checks
> for "qemu-block@nongnu.org" authorship, as Peter mentioned in the
> previous thread.

Yes, Peter found the spot, and mentioned his fix in the other thread.
diff mbox series

Patch

diff --git a/.mailmap b/.mailmap
index 64ef9f4de6f..6fb8202715a 100644
--- a/.mailmap
+++ b/.mailmap
@@ -40,7 +40,16 @@  Nick Hudson <hnick@vmware.com> hnick@vmware.com <hnick@vmware.com>
 # for the cvs2svn initialization commit e63c3dc74bf.

 # Next, translate a few commits where mailman rewrote the From: line due
-# to strict SPF, although we prefer to avoid adding more entries like that.
+# to strict SPF and DMARC.  Usually, our build process should be flagging
+# commits like these before maintainer merges; if you find the need to add
+# a line here, please also report a bug against the part of the build
+# process that let the mis-attribution slip through in the first place.
+#
+# If the mailing list munges your emails, consider using something like
+# 'git config --global sendemail.from your.email@example.com'
+# to add an extra From: line in the body of your email that takes
+# precedence over any munged From: in the mail's headers.
+# See https://lists.openembedded.org/g/openembedded-core/message/166515
 Ed Swierk <eswierk@skyportsystems.com> Ed Swierk via Qemu-devel <qemu-devel@nongnu.org>
 Ian McKellar <ianloic@google.com> Ian McKellar via Qemu-devel <qemu-devel@nongnu.org>
 Julia Suvorova <jusual@mail.ru> Julia Suvorova via Qemu-devel <qemu-devel@nongnu.org>