Re: RFE: use patchwork to submit a patch

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Steven,

On Tue, Oct 15, 2019 at 12:47:49PM -0400, Steven Rostedt wrote:
> On Tue, 15 Oct 2019 19:37:04 +0300 Laurent Pinchart wrote:
> 
> > But how far could we push this reasoning ? I've worked for a company
> > whose corporate policy was that all source code had to be stored in SVN,
> > not exception. I didn't reach the community to move kernel development
> > away from git. I've also worked with people whose corporate policy was
> > that they had to do Linux kernel development on Windows, without using
> > any virtual machine. There are all kind of crazy corporate policies, and
> > if we don't push the pain it inflicts on all of us back to the people
> > who enact those crazy policies, we'll always lose.
> 
> I understand your sentiment. But most of your examples are one-off
> "crazy corporate policies". The "sucky email server" and "you must use
> this sucky email server" is rather standard. Not saying that we don't
> want to pressure them to change, but I'm hearing from people (like Dave
> Miller), that new developers are moving away from email for
> development.

I think that's two different issues though, which certainly overlap (but
I'm not sure to what extent). I'm also not sure if we can say that new
developers are moving away from e-mail, or simply start development with
a different, non e-mail-based process. It makes a bit of a difference,
because some new developers may not have any issue with e-mail, they may
just not have considered it. This of course doesn't mean that nobody has
issues with e-mail, that nobody is moving away from e-mail, or that
nobody would have trouble moving to e-mail.

> I thought part of this thread was talking about having other ways
> besides email to submit a patch. Something that can help people
> correctly send a patch (at least their formatting) by making sure they
> fill out the proper fields and have a tool that helps them do so. I
> brought up the corporate email servers just as an example of having
> this help out there too.

I'm very biased here, but for me a CLI tool that asks me questions and
generates the patch series (or directly sends it) would be easier to
use than a web UI. That's because I would stay on the CLI that I'm
already using for git. This of course assumes a working git-send-email
configuration, which we all no is not a given. I thus wonder if it
wouldn't be better to have a CLI helper to create the patches, and
provide some sort of https-to-smtp service (possibly in the form of
pushing a tag with a message for instance). There are many options
possible to work around broken e-mail workflows, so instead of focussing
on a web UI because it was the first idea that was proposed, let's make
sure we consider other ones. And maybe we'll decide that a web UI is the
best option.

> I plan on continuing to develop mostly in email (I still send my patch
> series via quilt!). But I'm not going to enforce everyone to continue
> to use email if we can come up with a better way. I also want to make
> sure that whatever we do come up with will still support email.

Hypothetically speaking, if there was a service that allowed sending a
patch series through a git push with a tag containing a cover letter in
its message, and that service would send out e-mails to mailing lists
(with the option to self-host it if you want), would you consider using
it ?

-- 
Regards,

Laurent Pinchart