Re: RFE: use patchwork to submit a patch

[Greg KH <gregkh@linuxfoundation.org>]

On Fri, Oct 11, 2019 at 04:02:28PM -0400, Konstantin Ryabitsev wrote:
> 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.

Yes, compamy SMTP servers are a huge problem, which is why we have so
many contributors from gmail accounts :)

But will your "send a patch" tool work for someone behind a corporate
firewall?  If we are needing/wanting corporate contributions that bad,
by providing an end-run around their infrastructure is not going to be
seen as a "good" thing, once those corporate security teams realize what
is going on...

And again, how will the feedback loop look like here?  If joe@sony sends
me a patch, how can they respond to my response of "please fix the
change up to do X instead"?

I don't want this to be a "fire and forget" type of system where
companies submit patches through this interface and never respond.  We
already have enough examples of companies that do that today.  My last
example was a company that send out a 4 patch series, the response was
"great work, but can you resend just the last 2 so we can take them now,
and do X and Y on patches 1 and 2 so we can take them?"  That was a year
ago, with no response, when internally the developer said "I sent it
upstream, but it was rejected!".

</rant>

> (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.)

So if we create yet-another-patch-submission-path, how will that
circumvent those rules?  CAF is crazy, I've been in the middle of that
many times.  I doubt the "well I didn't send it in an email, I used this
tool over here instead." will play well with their lawyers/managers to
keep them from being fired.

It's not our job to solve the "my managers are not letting me send
patches out" problem here.  To solve that requires working with the
company at a totally different level.

> > > 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.

Simple drive-by patches for this is fine, if this type of tool will
help, as long as the feedback loop is there.

> > 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 still recommend at least talking to these developers as we _know_ they
are new to our process, so their feedback for a tool to make it easy for
people like themselves (or themselves 2 months ago), will be valuable.

thanks,

greg k-h