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

Darren Hart dvhart at infradead.org
Fri Jul 10 16:58:08 UTC 2015


On Fri, Jul 10, 2015 at 09:34:51AM -0700, Josh Triplett wrote:
> On Fri, Jul 10, 2015 at 11:44:09AM -0400, Steven Rostedt wrote:
> > On Thu, 9 Jul 2015 12:37:18 -0700
> > Darren Hart <dvhart at infradead.org> wrote:
> > 
> > > I've come to believe that this is one of many side effects of our dependency on
> > > a completely free form mechanism for the management of our patches, a mechanism
> > > which is becoming harder and harder to setup "correctly" with modern tooling
> > > (since the industry is killing "real email").
> > > 
> > > 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...
> > 
> > Ug, don't emphasize checkpatch. I see people making patches uglier due
> > to it. I have an old version of checkpatch that I sometimes run, but
> > the new version, IMHO, has more noise than signal.
> 
> If we could get some of the worst offenders turned *off*, like line
> length limits, many of its most basic checks are quite useful.
> 
> > > 6) Compiler warnings
> > > 7) CodingStyle :-)
> > > 8) Use ascii or utf8 character encodings
> > > 
> > 
> > 
> > > Looking forward a bit, I would love to see some tooling in place for people to
> > > submit patches either via a web form (which eliminates all the email tooling for
> > > submitting patches - which is where the formatting is especially critical) or
> > > through one of the more managed git systems, like gerrit, etc.
> > 
> > You mean like a web page that has a bunch of entries (like submitting a
> > paper to a LF conference), and you need to fill out.
> > 
> > Subject:  
> > 
> >  Fill out a one line top of this patch
> > 
> > Problem or enhancement :
> > 
> >  Why did you write this patch? Was there a problem you discovered, or
> >  is this a new feature you want to add.
> > 
> > Why this patch is needed:
> > 
> >  Why is this patch needed. If you fixed the problem, describe what you
> >  did and why you did it this way. If it is a feature, explain why this
> >  feature is needed, use cases for this feature, and how to use this new
> >  feature. If this adds a new user space interface, make sure you
> >  provide a man page (separate)
> > 
> > Patch file to upload:
> > 
> > 
> > Captcha:  We don't want bots doing this
> > 
> > 
> > Then this web server could run get_maintainers.pl and email the
> > appropriate people with a generated formatted patch. It could also
> > allow versioning. Today, people seem to be use to filling out web
> > forms. Obviously, this isn't a requirement to use, but could be used by
> > people that don't already know the Linux process.
> > 
> > It could be a bit smarter than get maintainers, as it could possibly
> > detect typo and whitespace patches and then send it off to the trivial
> > maintainer only.
> 
> I think it would make sense for such a bot to be driven by git pushes,
> rather than solely by a web form.  A web form, if any, would just handle
> automatic submission of a specified git series to the test address.

Keep in mind first-timers. They may just have a patch they want to submit. That
is where the most value is to be had in automation in my opinion. I agree we
should also support a git url and branch, and ultimately more automation on git
pushes would be great, but I think that's secondary to the impact on
recruitment. However, that may vary by maintainer and where their burden lies
from their submitters.

-- 
Darren Hart
Intel Open Source Technology Center


More information about the Ksummit-discuss mailing list