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

[Fengguang Wu <fengguang.wu@intel.com>]

On Wed, Aug 05, 2015 at 12:48:58AM -0700, Darren Hart wrote:
> 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.

Yes because we test so many git trees, there are isolations since
very early time.  The kbuild scripts run inside chroot and behind
firewall. There is dedicated git mirror server to fetch code from
outside which does not actually run the code.

Thanks,
Fengguang