RFE: use patchwork to submit a patch

[Konstantin Ryabitsev]

On Fri, Oct 11, 2019 at 10:57:02AM +0200, Greg KH wrote:
>So other than that minor thing, sounds interesting.  It's hard to
>determine just how difficult the whole "set up git and send a patch out"
>process is for people these days given the _huge_ numbers of new
>contributions we keep getting, and the numerous good tutorials we have
>created that spell out exactly how to do this.
>
>So you might be "solving" a problem that we don't really have.  It's
>hard to tell :(

It is interesting that there are split views on this. The main reason 
why I was thinking about it was because the topic came up a few times 
already. For example, in a conversation last year on ksummit-discuss:

https://lore.kernel.org/ksummit-discuss/ECADFF3FD767C149AD96A924E7EA6EAF7C1EAA24@USCULXMSG01.am.sony.com/

Tim Bird mentioned that Sony developers couldn't send/receive patches 
because their corporate mail server rewrote all links to go through some 
kind of security appliance verification. If you read that thread, what 
we are discussing now is what I suggested we did then -- a web tool that 
could take corporate SMTP servers out of the equation.

(This is the same reason I generally disagree with Eric Wong about 
preserving SMTP as the primary transmission protocol -- I've heard lots 
of complaints both from kernel developers and especially from people 
trying to contribute to CAF about corporate policies actually making it 
impossible to submit patches -- and no, using a different mail server is 
not a possibility for them because it can be a firing offense under 
their IT AUP rules.)

>> I know this is a pretty big RFE, and I would like to hear your thoughts
>> about this. If there is general agreement that this is doable/good idea, I
>> may be able to come up with funding for this development as part of the
>> overall tooling improvement proposal.
>
>The workflow seems sane, and matches what most people do today, with the
>exception that it "solves" the git send-email issue, right?  Is that our
>biggest barrier?

Well, I can't really speak from my extensive experience as a kernel 
developer, but I *have* submitted patches to Documentation/* before.  
This happens infrequently enough that I basically have to relearn the 
whole process from scratch, and it *is* a lot of steps. I can't fault 
people who are only familiar with the GitHub way of doing things when
they complain that this process is a challenge for them.

Not everyone submitting changes to the kernel are going to be highly 
skilled and comfortable with the terminal and command-line tools. They 
may be submitting a documentation fix, or it can be a driver developer 
who never leaves Visual Studio submitting a small bugfix so their driver 
works better in Linux.

>I would recommend interviewing some of the recent kernel mentor project
>and outreachy applicants first, to try to determine exactly what their
>problems, if any, were with our development process.  If they say that
>this type of tool/workflow would have saved them hours of time and
>energy, then that's a great indication that we should try to do this.

I don't disagree and Shuah's comments are very valuable here. However, I 
would argue that these folks don't necessarily represent the target 
audience for this tool. They may be newbies, but they join these 
initiatives with the goal of spending significant time with the kernel 
and its code, so they don't mind the effort of learning the proper way 
of submitting patches.

I'm thinking of someone who needs to submit an occasional contribution 
once every six months and to whom this document is both long and 
daunting: 
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html.

-K