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

[Jason Cooper]

On Thu, Jul 09, 2015 at 07:07:06PM -0700, Darren Hart wrote:
> On Fri, Jul 10, 2015 at 01:35:59AM +0100, Mark Brown wrote:
> > On Thu, Jul 09, 2015 at 11:31:49PM +0100, David Woodhouse wrote:
> > > On Thu, 2015-07-09 at 12:37 -0700, Darren Hart wrote:
> > 
> > > > I spend a highly disproportionate amount of my time, relative to measurable
> > > > quality impact to the kernel, going over the nuances of submitting patches.
> > 
> > > > 1) Must have a complete commit message
> > > > 2) DCO goes above the ---
> > > > 3) Include a patch changelog, do so below ---
> > > > 4) Cc maintainers :-)
> > > > 5) Checkpatch... checkpatch... checkpatch...
> > > > 6) Compiler warnings
> > > > 7) CodingStyle :-)
> > > > 8) Use ascii or utf8 character encodings
> > 
> > As far as I can tell for most of the bits of this that are tooling and
> > create practical problems git send-email will avoid most of the issue
> > and people do seem to have mostly adopted that, but perhaps that's a
> > result of me seeing a different submitter base to you.  I very rarely
> 
> I was going to make the same comment - we all deal with a different group. I
> admittedly see a number of first time contributors looking to improve their
> particular laptop, rather than veteran sub-system developers (I also get people
> picking up major platform drivers and doing a great job).
> 
> > see anything that's serious enough to cause a practical problem except
> > for CC issues that doesn't also come along with other substantial code
> > quality problems.
> > 
> > Patch changelogs are the biggest thing I can see there that feels like a
> > tooling problem to me since git send-email doesn't do anything at all,
> > though it's not an issue I'm personally that concerned about (I do
> > appreciate having them but I can often barely remember what issues I
> > raised in the first place).
> 
> As far as recruitment goes, I think we're talking about barriers to first-timers
> and such - and git-send-email is one of those things. Eventually, a developer
> spends enough time to make setting that all up worthwhile, but honestly, there
> are A LOT of ways to embarass yourself with git-send-email. So much so that I've
> written wrappers to it to protect people from it for the yocto project - and
> even myself for my kernel work.

git send-email --kernel *.patch ?

--kernel would go through each patch and auto-fills Cc based on MAINTAINERS.
Amongst a few other things.  Shallow threading, check/edit cover letter
and so forth.

Or, we put a wrapper in ./scripts to accomplish the same.

> Is that a good assumption? Are we talking about first-timers - or are we talking
> about getting current participants to do more review?

Yes, this is about recruitment, so focused on first-timers.  Reviewers
start out as first timers.

Getting current devs to do more review falls on co-maintainer/reviewer
rotation to avoid burn-out.  I think folks would be more likely to
increase their role if they knew it wasn't a full-time commitment until
you burn out.

thx,

Jason.