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/ecadff3fd767c149ad96a924e7ea6eaf7c1ea...@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
_______________________________________________
Patchwork mailing list
Patchwork@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/patchwork
