[Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance

[Olof Johansson]

On Fri, Sep 21, 2018 at 6:08 PM, Mauro Carvalho Chehab
<mchehab at kernel.org> wrote:
> Em Fri, 21 Sep 2018 17:46:13 +0100
> Olof Johansson <olof at lixom.net> escreveu:
>
>> On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds
>> <torvalds at linux-foundation.org> wrote:
>> > [ Still very much on break, but reading ksuummit-discuss and answering
>> > this one ]
>> >
>> > On Tue, Sep 18, 2018 at 9:35 AM Dmitry Torokhov
>> > <dmitry.torokhov at gmail.com> wrote:
>> >> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony <tony.luck at intel.com> wrote:
>> >> >
>> >> > Or, shock, horror, tell one-time contributors that it is OK to
>> >> > put the patch in an attachment to the e-mail.  Outlook doesn't
>> >> > (usually) mess with the contents of attachments.
>> >>
>> >> And then have maintainer having hard time trying to comment on said
>> >> patch in the attachment. I'd rather not.
>> >
>> > I actually think that *this* could be easily handled by trivial
>> > tooling that doesn't have to be set up over and over again inside
>> > companies or teaching people.
>> >
>> > In fact, doesn't patchwork already do exactly that?
>> >
>> > I have to say, there are real technical advantages to using
>> > attachments for patches, particularly when you have odd combinations
>> > of locales. It's gotten to be less of an issue over time and we're
>> > still almost entirely US-ASCII with the occasional UTF-8, but we do
>> > still have the occasional problem. Using attachments at least detaches
>> > the email charset from the user locale, and from random other MUA
>> > issues.
>> >
>> > But yes, the "comment on individual parts of the patch" part is very
>> > important too.
>> >
>> > The main problem with having something that rewrites things is that it
>> > breaks DKIM etc, so you can't just have a pure email gateway. It
>> > almost needs to be something at a higher semantic level like patchwork
>> > (that could still send out rewritten emails).
>> >
>> > In many cases, you might want that anyway (ie wouldn't it be lovely
>> > when the patch is also checked for "does it build" and looks up the
>> > maintainers based on what paths it touches etc etc).
>> >
>> > So a sane email / web-interface kind of gateway that allows people to
>> > work the way they prefer.
>> >
>> > But I guess "trivial" is completely the wrong word to use.
>>
>> We're already starting to use some bots that sit on the mailing lists
>> and monitor incoming material.
>>
>> This could be solved with something as simple as a bot that takes the
>> patch-as-attachment, does a few useful things like runs checkpatch and
>> makes sure it applies cleanly (maybe report what trees it applies
>> cleanly to, such as current mainline and next), and then inlines the
>> whole patch. All as a reply-all to the sender + original recipients.
>>
>> That way, anyone looking to do an inline review can do it on the bot
>> version, and the originator will still receive the feedback, etc. It'd
>> also solve the DKIM-related aspects, if I'm not mistaken.
>>
>> People who get distracted by the bot emails can easily choose to filter it.
>
> Seems to work.
>
> Still, there are some issues with that. Depending on the email client,
> it may not recognize the patch as is, and use a wrong mime-type.
> If the mail server doesn't recognize the mime-type, or considers it
> evil, it may reject the e-mail, and the bot will get nothing.
> Not sure what's the current status of e-mailers and patches, but on
> my past experiences on another company (lots of years ago), usually
> webmail solutions are worse[1], and don't properly tag certain types
> of attachments.
>
> [1] I know places where only a corporate webmail solution is allowed
> by default, and using any other solution would require an special
> security approval. Not sure if is worth to consider such scenario,
> though.

All of these sound like solvable problems to me, by having the bot be
lenient about what it accepts. It might get a bit messy and might need
tuning over time, but that's fine.

> Another problem is that bots will receive the same e-mail twice
> (the original one and the inlined one). We may start having
> multiple kernel-test robots reply for such emails, with is not
> a good thing. So, if done this way, it is probably worth to add
> some meta-tags to avoid the new e-mail with the same patch
> to be parsed again by (other) robots.

With only a couple of active bots, making them filter each other would
be a trivial initial approach.


-Olof