[Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

[Darren Hart]

On Fri, Jul 10, 2015 at 05:13:48PM -0700, Greg KH wrote:
> On Fri, Jul 10, 2015 at 05:00:34PM -0700, Darren Hart wrote:
> > On Fri, Jul 10, 2015 at 03:23:51PM -0700, Greg KH wrote:
> > > On Fri, Jul 10, 2015 at 09:07:14AM -0700, Darren Hart wrote:
> > > > On Fri, Jul 10, 2015 at 05:36:41PM +0300, Dan Carpenter wrote:
> > > > > Or you could just create a generic form letter like Greg does.
> > > > > 
> > > > 
> > > > OK, so this is precisely the kind of individually developed special purpose
> > > > wizardry that I think hinders recruitment. Rather than having every maintainer
> > > > reinvent this wheel in a subtly different a personal way (which gets back to the
> > > > issues raised about subtly different expectations per maintainer), it makes a
> > > > lot of sense to me to create a common infrastructure that we can all use.
> > > 
> > > Ok, feel free to use my "form letter" that I've created over the years
> > > and expand on it for more common problems if I've missed anything.  I
> > > just dump it into a response to the patch (3 keystrokes), and cut away
> > > anything that isn't relevant to this specific patch.  Seems to work
> > > pretty well in cutting down on me having to type the same thing all the
> > > time.
> > 
> > Do you have something that automates the scanning for basic errors and builds
> > and reports to you - or do you manually pull every patch out of your email
> > client and run those tests yourself to find that the patch-bot needs to be
> > deployed?
> 
> Almost all of the issues I list in that response I find just by looking
> at the patch, they jump out instantly.  The ones for when the build is
> broken or the patch doesn't apply get found when I do my "apply this
> mbox of patches" work, which I usually do in chunks of 5 patches at a
> time.
> 
> So no, I don't have anything automated, so yes almost all of these could
> be found by a tool.  Oh look, we have that tool, which no one uses,
> checkpatch.pl.
> 
> Ok, checkpatch will not catch the issue where your email client is
> messed up, or when you send a series of patches with no numbering on
> them, but that's way down the list of errors that I see by quantity.
> And I think I review more "first timer" patches than anyone else in the
> community.  If people actually ran checkpatch it would resolve almost
> all of the issues I see.
> 
> > That's the kind of thing that it seems like could be automated and
> > improve the quality level of patches that make it to the maintainers.
> 
> All of these are the "simple" issues that really don't take long to
> resolve.  We have it documented in great detail on how to set up an
> email client, how to format the patch, and how to get everything right
> on the kernelnewbies.org site.  I also teach a class on this, one hour
> max is all it takes, unless you are at a company with a broken email
> system.  And then all bets are off, you better just install a Linux
> email server in the corner to resolve your email issues, just like all
> the major companies did (IBM, Intel, Microsoft, etc.)

OK, all good points. It looks as though I can step up my own tooling some to
make the email-to-compilation step faster so I don't spend as much time on
patches with compiler warnings, that don't apply, etc. Dan C. said something
similar.

The "one hour class" thing makes it sound like it takes "one hour" - but I find
I have to revisit this stuff fairly regularly, and those hours add up.

> I applaud your attempt here, and don't want to stop you from working on
> it, but I think the real issue is having people actually look for the
> documentation and tools we already have created to do this.  If you make
> yet-another-tool, how are you going to advertise it any better than the
> existing tools/documentation are?

That's definitely the key. Right now, people go through *some* process to
discover how to send their first patch to LKML - somehow they often manage to do
that without discovering (or choosing to use) checkpatch.pl or run some
reasonable set of build tests. In order for something like what is being
proposed here, the new tool would have to have to be:

1) Easier to find
2) Easier to use
3) Presented as a path to patch submission
   (not an extra tool to run beforehand)

The idea being that the patch submission process would include some automated
vetting, which catches trivial stuff for first-timers, but which also catches
more complex things by integrating with 0-day or similar. I wouldn't mind not
seeing a patch until after 0-day automatically provided feedback from all the
static analyzers and config fuzz build testing if that could be seemlessly
injected into the patch submission process.

I have people ask me about web based revision control tooling for Linux and
other projects fairly regularly. I do believe that if we made it available,
many first-timers would find it to be a much lower barrier to entry.

Of course, the output has to adhere to the current process such that it
doesn't impact the scalability of our top maintainers like you and Linus.

-- 
Darren Hart
Intel Open Source Technology Center