From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 09462A04 for ; Thu, 9 Jul 2015 20:19:28 +0000 (UTC) Received: from slow1-d.mail.gandi.net (slow1-d.mail.gandi.net [217.70.178.86]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 2AF00147 for ; Thu, 9 Jul 2015 20:19:27 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by slow1-d.mail.gandi.net (Postfix) with ESMTP id A9E6747A27C for ; Thu, 9 Jul 2015 22:11:33 +0200 (CEST) Date: Thu, 9 Jul 2015 13:11:27 -0700 From: josh@joshtriplett.org To: Darren Hart Message-ID: <20150709201127.GA3426@cloud> References: <201507080121.41463.PeterHuewe@gmx.de> <559C73DF.2030008@roeck-us.net> <20150708114011.3a1f1861@noble> <2879113.fraeuJIr2M@avalon> <20150709193718.GD9169@vmdeb7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150709193718.GD9169@vmdeb7> Cc: ksummit-discuss@lists.linuxfoundation.org, Jason Cooper Subject: Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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. - Josh Triplett