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

Darren Hart dvhart at infradead.org
Thu Jul 9 20:43:13 UTC 2015


On Thu, Jul 09, 2015 at 01:11:27PM -0700, Josh Triplett wrote:
> On Thu, Jul 09, 2015 at 12:37:18PM -0700, Darren Hart wrote:
> > On Wed, Jul 08, 2015 at 10:45:28PM +0300, Laurent Pinchart wrote:
> > > On Wednesday 08 July 2015 11:40:11 NeilBrown wrote:
> > > > Indeed!  I wonder if we can list the dimensions.
> > > > 
> > > > Variability: as you say, different people want different things, and
> > > >    care to different degrees about them.  'checkpatch' and
> > > >    'CodingStyle' help with some of that (though different people care
> > > >    differently about checkpatch).  Maybe the MAINTAINERS file could
> > > >    list the preferred Subject: line and checkpatch flags for each
> > > >    maintainer.  Then we just need to herd all those wild-cats towards
> > > >    updating their maintainers entry.
> > > 
> > > I've seen maintainers who want to be CC'ed on every patch touching their 
> > > subsystem, and others who prefer patches being sent to the mailing list only. 
> > > That would be easy to express in MAINTAINERS and would already help in two 
> > > fronts. It would lower the amount of noise for maintainers who base their work 
> > > flow on mailing lists. It would also remove the need for submitters to decide 
> > > whether to CC maintainers and prevent patches from falling through cracks when 
> > > the decision is incorrect.
> > 
> > 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...
> > 6) Compiler warnings
> > 7) CodingStyle :-)
> > 8) Use ascii or utf8 character encodings
> > 
> > All of these are distractions from reviewing the code. I'm often on version 3 of
> > a series before I'm actually reviewing content.
> > 
> > I raised this in Dusseldorf with the PREEMPT_RT crowd, and I'll do so here too,
> > although I suspect it will be met with quite a bit of opposition. I believe our
> > tooling and processes are good at helping our top level maintainers scale -
> > which is absolutely critical to the success of Linux - but they inhibit scaling
> > out and attracting new developers, reviewers, etc.
> > 
> > Our most productive maintainers and contributors, in my understanding, often are
> > able to spend most of their time on their upstream Linux kernel work. They have
> > been doing it for a decade or more and have a lot of custom written tools to
> > help make the processes scale for their particular needs. This is great!
> > 
> > However, we have a lot of tribal knowledge regarding how to interact
> > successfully with the development model. So much so that many of our lesser
> > maintainers (like myself) spend a lot of our time as a bridge or proxy to
> > upstream development, which is too opaque and even enigmatic for them to get
> > into.
> [...]
> > I am looking to make some changes in my subsystem. I've requested patchwork to
> > be enabled, and I'll create a for-review branch and solicit help there. I
> > already leverage 0-day, but I think it would be great to have something which
> > parses patches submitted to LKML and tests the 8 items above and more and
> > automatically responds to the submitter. Nobody should have to spend their time
> > on those things.
> > 
> > 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.
> 
> I would love to see this.  I don't think it makes sense for the flow
> from subsystem maintainers to Linus or similar to use these tools;
> anyone capable of saying "please pull" *probably* doesn't need most of
> this.  However, for people who primarily interact with maintainers via
> patch mails, some kind of automated CI bot, integrated with Gerrit or
> github or similar, would filter out a substantial number of painful bits
> before they show up.
> 
> Consider a set of scripts or services that could easily be wired into
> either a Gerrit install or a GitHub hook, so that rather than spending
> time sorting out SMTP and basic patch formatting, people could git push
> to a repository branch they control, get automated feedback on what
> needs fixing, and when all of the mechanical issues are sorted out that
> same service can help them send a properly formatted mail series (with
> cover letter) to the right set of people.
> 
> It would take some work to initially set up, but the result should
> actually save maintainer time by avoiding the need to comment on
> mechanical correctness issues.
> 
> That same bot could fairly easily be wired to a "test" mailing list,
> capturing mailed patch series and running them through the same tests,
> so that people comfortable with the email part of the workflow could
> mail patches to that list to have them automatically checked *before*
> mailing LKML.  And unlike mailing LKML, there would be no stigma
> attached to iterating and sending multiple mails to that list while
> trying to get the details right.
> 
> Bonus if this is also wired into the 0day bot, so that you also find out
> if you introduce a new warning or error.
> 

Pretty sure you said that better than I did :-)

The git submission mechanism makes a lot of sense (that's a bare minimum to
working with Linux) and +1000 on avoiding the stigma of a "mechanical" failure
on LKML.

-- 
Darren Hart
Intel Open Source Technology Center


More information about the Ksummit-discuss mailing list