threads / discuss / 54401

Re: Patchwork now does the right thing with GGG submissions

Subject: Re: Patchwork now does the right thing with GGG submissions

## tl;dr

4 messages between Oct 12, 2020 and Oct 12, 2020.

replies: 3people: 3as markdown or json

Jonathan Nieder· Oct 12, 2020, 19:38 UTC · lore
Konstantin Ryabitsev wrote:
> Just FYI, I made the necessary tweaks to patchwork to make it properly
> assign "From" for gitgitgadget submissions:
>
> https://patchwork.kernel.org/patch/11832689/
\o/ Thanks much for this.

For the curious, any links to the change behind the scenes that made that happens? Does it use Sender[1] or a different field? Does the change live in [2] or [3]?

Sincerely, Jonathan

[1] https://lore.kernel.org/git/xmqqiml4bsra.fsf@gitster-ct.c.googlers.com/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/ [3] https://github.com/getpatchwork/patchwork

Junio C Hamano· Oct 12, 2020, 20:36 UTC · re: Jonathan Nieder · lore
Jonathan Nieder <jrnieder@gmail.com> writes:
Show 15 quoted lines
> Konstantin Ryabitsev wrote:
>
>> Just FYI, I made the necessary tweaks to patchwork to make it properly
>> assign "From" for gitgitgadget submissions:
>>
>> https://patchwork.kernel.org/patch/11832689/
>
> \o/ Thanks much for this.
>
> For the curious, any links to the change behind the scenes that made
> that happens?  Does it use Sender[1] or a different field?  Does the
> change live in [2] or [3]?
>
> Sincerely,
> Jonathan

It is curious that I sometimes see you respond to Konstantin on this list, but the message you are responding to is not found. What is going on?

A question to Konstantin is what is so special about GGG? Did you make patchwork to pay attention to the in-body "From:" and other in-body header lines (in which case it benefits not just GGG but everybody). If you added a support to ignore everything before the scissors that would deserve an extra gold star ;-)

For example, how does
https://lore.kernel.org/git/xmqqy2kwiimi.fsf@gitster.c.googlers.com/
appear in patchwork?
> [1] https://lore.kernel.org/git/xmqqiml4bsra.fsf@gitster-ct.c.googlers.com/
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/mricon/korg-helpers.git/
> [3] https://github.com/getpatchwork/patchwork
Konstantin Ryabitsev· Oct 12, 2020, 21:27 UTC · re: Junio C Hamano · lore
On Mon, Oct 12, 2020 at 01:36:39PM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> >> Just FYI, I made the necessary tweaks to patchwork to make it 
> >> properly
> >> assign "From" for gitgitgadget submissions:
> >>
> >> https://patchwork.kernel.org/patch/11832689/
> >
> > \o/ Thanks much for this.
> >
> > For the curious, any links to the change behind the scenes that made
> > that happens?  Does it use Sender[1] or a different field?  Does the
> > change live in [2] or [3]?
> >
> > Sincerely,
> > Jonathan
> 
> It is curious that I sometimes see you respond to Konstantin on this
> list, but the message you are responding to is not found.  What is
> going on?

I initially didn't send it to git@vger, only to Jonathan. :) I don't mind, though -- I just wasn't sure if this was something others on the git list would care about.

Show 5 quoted lines
> A question to Konstantin is what is so special about GGG?  Did you
> make patchwork to pay attention to the in-body "From:" and other
> in-body header lines (in which case it benefits not just GGG but
> everybody).  If you added a support to ignore everything before the
> scissors that would deserve an extra gold star ;-)

No, this is specifically for GGG mail, as it's a very specific well-understood case. The solution I have in place is to just pay attention to the in-body Form, but once we upgrade to patchwork 2.2.2 tomorrow, we will also start paying attention to the X-Original-From header.

I'm not 100% sure if it's always correct to pay attention to the in-body From -- at least for the purposes of patchwork. Patchwork pays attention to "who submitted the series," not "who authored the commit," so making in-body From always be the "From" in patchwork would be wrong.

For the cases of GGG, we can ignore this difference, as we definitely don't want to pay attention to "who sent the patch" (it's always gitgitgadget@gmail.com). However, GGG can make the situation more correct if it starts adding an X-Original-From that would be the Github name and email of the person submitting the pull request. E.g.:

From: D. Eveloper via GitGitGadget <ggg@gmail.com>   <- DMARC From
X-Original-From: D. Eveloper <github@email.here.com> <- Patchwork From
Subject: [PATCH 1/10] ...
From: A. Nother-Person <foo@example.com>             <- Git From
Show 5 quoted lines
> For example, how does
> 
> https://lore.kernel.org/git/xmqqy2kwiimi.fsf@gitster.c.googlers.com/
> 
> appear in patchwork?

It's a reply to another patch, so patchwork only processes it as a comment. Generally, patchwork doesn't see worrying about this thing as its job -- it just wants to let maintainers track incoming patches and series and download them in a format that is easy to apply using "git am". For that matter, that's how b4 approaches this as well.

-K
Konstantin Ryabitsev· Oct 12, 2020, 21:31 UTC · re: Jonathan Nieder · lore
On Mon, Oct 12, 2020 at 12:38:50PM -0700, Jonathan Nieder wrote:
Show 11 quoted lines
> > Just FYI, I made the necessary tweaks to patchwork to make it 
> > properly
> > assign "From" for gitgitgadget submissions:
> >
> > https://patchwork.kernel.org/patch/11832689/
> 
> \o/ Thanks much for this.
> 
> For the curious, any links to the change behind the scenes that made
> that happens?  Does it use Sender[1] or a different field?  Does the
> change live in [2] or [3]?

See my other email explaining how it's implemented. As to where it lives -- it's implemented as a procmail rule:

:0
* ^From: .*<gitgitgadget@gmail\.com>
{
    :0 bw
    INBODYFROM=| formail -xfrom:
    :0 hfw
    * INBODYFROM ?? .
    | formail -I "From:$INBODYFROM"
}

Currently, we fully blow away the From:, but after the 2.2.2 upgrade we'll be setting it as X-Original-From if we don't find one already present.

It's my goal to start publishing these procmail rules as part of a git repo in the future, so you'll be able to see all rules that are applied to incoming mail before we pass it along for patchwork processing.

Best regards, -K

← back to recent threads