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

Rodrigo Vivi rodrigo.vivi at intel.com
Fri Feb 16 18:59:50 UTC 2018


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.

> 
> Then you need either create a fall-back mechanism in the model so
> patches that came in before the change will still use data from the
> foreign key to the Person model or create a migration that copies
> current authorship information onto the patches.
> 
> And update how the mboxes are generated to use the name form the Patch:
> https://github.com/dlespiau/patchwork/blob/master/patchwork/views/__init__.py#L218
> 
> There's no need of removing the "Person" concept, as it also serves
> other purposes (search and ownership management).

I agree that that is useful.

> 
> Also write a few tests to make sure it works as expected.

Do you have any example of tests case? And any doc to show
how to setup a local version to test it?

Is there a test version and production version?

> 
> 
> Patches are welcome. Repository has CI set up. I have commit right to
> this project. I can review and accept pull requests. I can also deploy
> the update.

Is Damien still maintaining this? Or should we move to somewhere else?

Is there any plan to contribute back to "main" getpatchwork? Or it will
be a forever fork?

> 
> 
> PS. I have it in my backlog, but there are more pressing matters (e.g.
> Django 1.8 is being EOLed this water) I am working on :-)
>
> -- 
> Cheers,
> Arek
> 
> 

Thanks,
Rodrigo.


More information about the dim-tools mailing list