From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E37401003 for ; Fri, 21 Sep 2018 17:16:44 +0000 (UTC) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0C05A784 for ; Fri, 21 Sep 2018 17:16:43 +0000 (UTC) Received: by mail-lj1-f177.google.com with SMTP id v26-v6so12320710ljj.3 for ; Fri, 21 Sep 2018 10:16:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180921140809.18ba8eae@coco.lan> References: <20180917115916.37fd5388@coco.lan> <2174637.IVJC5EhCEq@avalon> <20180918160236.GK2471@sirena.org.uk> <20180918163231.GB10134@agluck-desk> <20180921140809.18ba8eae@coco.lan> From: Olof Johansson Date: Fri, 21 Sep 2018 18:16:40 +0100 Message-ID: To: Mauro Carvalho Chehab Content-Type: text/plain; charset="UTF-8" Cc: tim.bird@sony.com, ksummit Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] community management/subsystem governance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Sep 21, 2018 at 6:08 PM, Mauro Carvalho Chehab wrote: > Em Fri, 21 Sep 2018 17:46:13 +0100 > Olof Johansson escreveu: > >> On Tue, Sep 18, 2018 at 6:18 PM, Linus Torvalds >> 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 >> > wrote: >> >> On Tue, Sep 18, 2018 at 9:33 AM Luck, Tony 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