[PATCH 1/2] dim: Workaround Outlook + Patchwork mess.

[Jani Nikula]

On Mon, 21 May 2018, Arkadiusz Hiler <arkadiusz.hiler at intel.com> wrote:
> On Fri, May 18, 2018 at 04:36:03PM -0700, Lucas De Marchi wrote:
>> On Mon, Feb 19, 2018 at 12:42 AM, Arkadiusz Hiler
>> <arkadiusz.hiler at intel.com> wrote:
>> > On Fri, Feb 16, 2018 at 10:59:50AM -0800, Rodrigo Vivi wrote:
>> >> On Fri, Feb 16, 2018 at 10:52:11AM +0200, Arkadiusz Hiler wrote:
>> >> > On Thu, Feb 15, 2018 at 11:14:09AM -0800, Rodrigo Vivi wrote:
>> >> > > Patchwork has a own identity that doesn't respect the author configuration.
>> >> > > It automatically changes the author to whatever it was last seen on
>> >> > > the public mailing list.
>> >> > >
>> >> > > In case the response came from an outlook server the author identity
>> >> > > inside patchwork will get changed to Last, First.
>> >> > >
>> >> > > We have authors that respond emails to public mailing list using
>> >> > > Intel emails. Even non outlook users can end up having this trouble
>> >> > > because the Evolution can be setup with EWS, for instance.
>> >> > >
>> >> > > Since we could never fix patchwork for real to respect users
>> >> > > choice we can workaround it here when applying the patch.
>> >> >
>> >> > This statement is not true. It's not quite trivial, but definitely possible.
>> >>
>> >> I'm sorry for the way I wrote it. I didn't mean to do any critic.
>> >> I'd be glad in re-phrase that to:
>> >>
>> >> Since the solution on patchwork to respect user's name of choice
>> >> is not trivial, we can, for now, workaround this here when applying the patch.
>> >>
>> >> >
>> >> > This models needs additional field for email address:
>> >> > https://github.com/dlespiau/patchwork/blob/master/patchwork/models.py#L308
>> >> >
>> >> > This part of code needs to save the raw author information using the
>> >> > newly added field:
>> >> > https://github.com/dlespiau/patchwork/blob/master/patchwork/bin/parsemail.py#L759
>> >> > (now it's just updating the name in the association)
>> >>
>> >> It's the first time that I ever look to this code so please bare with me.
>> >> But is it possible here to differentiate from mail mail and patch mail?
>> >> On this case we could only save the name from the patch mail and never from mail mail.
>> >>
>> >> This would solve the issue since smtp itself used by git send-email doesn't change
>> >> any address. Only the EWS does.
>> >
>> > That's one way to solve this, but it would still be just a half of a
>> > solution.
>> >
>> > There are still edge cases that can bite us in the future - legal change
>> > of the name, someone who has a typo in the gitconfig just on one of the
>> > machines - that ends up propagating to other patches (I've seen this
>> > happening!).
>> 
>> I think we may be over complicating this. The only place in which this
>> bites us is when downloading the patch from patchwork. For that
>> download I don't want any mapping to any identity from Patchwork. I
>> want to have whatever the user set on their patch. Because if that's
>> wrong we can point the person to fix on their end. If he changed his
>> name, married, had a typo, etc, they are all things this person should
>> rather had be changed on their config, because when they are
>> committing directly to the git tree, that's the name that is going to
>> be used. Not anything patchwork decided to map to.
>> 
>> 
>> There are people in the kernel community who use e.g. "Foo (company)
>> foo at foo.org" and change the company to differentiate contributions
>> from companies that are sponsoring him (hint git log --author="Steven
>> Rostedt" to see one use case). Mangling whatever the person set on
>> *that* specific patch based on what was used for other patches or
>> replies is just wrong IMO.  So I don't think it's just an
>> outlook/exchange problem.
>> 
>> >
>> > That's why I am strongly in favor of keeping "From" with each of the
>> > patches - it matches intuitive understanding of patch being self
>> > contained.
>> 
>> We could do that for the patchwork interface, but just deliver
>> whatever was received in the "patch email" when someone downloads the
>> mbox.
>> 
>> Lucas De Marchi
>
> Patchwork does not store the vanilla email contents. This means that
> there are quite a few changes to be made to the database schema and data
> retrieval paths.
>
> If we store and spit out the vanilla emails then you say goodbye to auto
> r-b and ack in the mboxes - I am not sure that's the change most people
> here would like to see.
>
> Storing original contents of the From header is much easier and maintain
> most of the current behavior.
>
> This is just a bit of over thinking :-)
>
> Mostly it was dancing around the initial design shortcomings without
> having to do a full blown rework with downtime and data migration.
>
> But hey, if the maintainers can agree that they just want the vanilla
> mbox, I can deliver.

I want the author of the patch be set to the vanilla From: mail header,
optionally overridden with the vanilla From: tag in the first lines of
patch email commit message as put there by git.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center