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

Arkadiusz Hiler arkadiusz.hiler at intel.com
Mon May 21 06:10:07 UTC 2018


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.

-- 
Cheers,
Arek


More information about the dim-tools mailing list