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