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 70850B1D for ; Fri, 10 Jul 2015 15:54:07 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.9]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 25BA6140 for ; Fri, 10 Jul 2015 15:54:07 +0000 (UTC) Date: Fri, 10 Jul 2015 08:54:03 -0700 From: Darren Hart To: Jason Cooper Message-ID: <20150710155403.GJ111846@vmdeb7> References: <201507080121.41463.PeterHuewe@gmx.de> <559C73DF.2030008@roeck-us.net> <20150708114011.3a1f1861@noble> <2879113.fraeuJIr2M@avalon> <20150709193718.GD9169@vmdeb7> <1436481109.3324.219.camel@infradead.org> <20150710123233.GQ23515@io.lakedaemon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150710123233.GQ23515@io.lakedaemon.net> Cc: ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Jul 10, 2015 at 12:32:34PM +0000, Jason Cooper wrote: > What we're also looking at here is adjusting the wetware / software > boundary. The goal of checkpatch is the same: offload maintainer brain > time onto automated software. But it's a double-edged sword. Now we > see checkpatch-only patches. Was it a net-gain for maintainer relief? > Or simply a shift in the type of annoyances? > > I don't know. The lesson learned from checkpatch and other tools > shouldn't be lost on any effort we try today. That's not to say we > shouldn't try. Rather, we should try new processes and tooling, *and* > establish sane goals for the same. "After 1 year of autotest@vger, > we'll poll the maintainers and ask if they noticed a difference." This > implies some sort of tag system so maintainers can trivially tell when a > patch has cleared autotest@vger. Maybe: > > Autotest-passed: https://autotest.kernel.org/2015/07/10/ > > Depending on the proposed system, the goal can be more quantifiable, if > needed. I was going to suggest pretty much the same thing. > > > Josh suggests that we should provide a service that people could push > > code to and 'get automated feedback on what needs fixing'... but isn't > > that what checkpatch was for? OK, a local tool can't cross-compile it > > for you on every platform we support, but it can do a lot of stuff > > short of that. > > > > I do like the idea of a 'test' mailing list which receives patches and > > checks them for corruption though. > > Agree. And in sensible cases, it can suggest a fix. e.g. "Missing > S-o-b, please read the DCO [link]. If you agree, add your S-o-b to the > end of the commit message. 'git commit -s ...' will add this for you." > I presume this would go back to the list and the submitter. I can see arguments for and against including anyone else on Cc from the original patch. What did you have in mind? > wrt recruitment, It would be advisable for a few maintainers who are > interested to be subscribed to autotest@vger to keep an eye on things > and intervene if necessary. > > thx, > > Jason. > -- Darren Hart Intel Open Source Technology Center