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

[Darren Hart <dvhart@infradead.org>]

On Mon, Aug 03, 2015 at 08:38:05PM +0800, Fengguang Wu wrote:
> On Thu, Jul 09, 2015 at 01:11:27PM -0700, josh@joshtriplett.org 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.
> 
> Sure, if someone is to setup the web form or test mailing list or
> both, 0day can happily run all supported tests on them, including
> checkpatch.pl etc. that we normally don't run for the regular git
> pushes.

Fengguang,

Do we have sufficient isolation/security in place to test any patch from anyone
on a mailing list? I believe someone else raised this concern previously, but
it's been a while and I don't remember who it was.

-- 
Darren Hart
Intel Open Source Technology Center