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 3EDFFA55 for ; Mon, 17 Jun 2019 14:26:48 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C30C2C3 for ; Mon, 17 Jun 2019 14:26:47 +0000 (UTC) Date: Mon, 17 Jun 2019 16:26:45 +0200 Message-ID: From: Takashi Iwai To: Mauro Carvalho Chehab In-Reply-To: <20190617103115.670bf968@coco.lan> References: <1559836116.15946.27.camel@HansenPartnership.com> <20190606155846.GA31044@kroah.com> <1559838275.3144.6.camel@HansenPartnership.com> <20190613105916.66d03adf@coco.lan> <20190614101222.GA4797@pendragon.ideasonboard.com> <20190614102424.3fc40f04@coco.lan> <20190614135807.GA6573@kroah.com> <20190614121137.02b8a6dc@coco.lan> <1560525785.27102.16.camel@HansenPartnership.com> <20190614124305.65eb8dbd@coco.lan> <1560527386.27102.23.camel@HansenPartnership.com> <20190614130456.6c339c01@coco.lan> <1560528994.27102.34.camel@HansenPartnership.com> <20190614144836.0a71ebe5@coco.lan> <20190617103115.670bf968@coco.lan> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: James Bottomley , media-submaintainers@linuxtv.org, ksummit Subject: Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 17 Jun 2019 15:31:15 +0200, Mauro Carvalho Chehab wrote: > > Em Mon, 17 Jun 2019 09:01:06 +0200 > Geert Uytterhoeven escreveu: > > > Hi Mauro, > > > > On Fri, Jun 14, 2019 at 7:48 PM Mauro Carvalho Chehab > > wrote: > > > Em Fri, 14 Jun 2019 09:16:34 -0700 > > > James Bottomley escreveu: > > > > On Fri, 2019-06-14 at 13:04 -0300, Mauro Carvalho Chehab wrote: > > > > > Em Fri, 14 Jun 2019 08:49:46 -0700 > > > > > James Bottomley escreveu: > > > > > > Actually, this leads me to the patch acceptance criteria: Is there > > > > > > value in requiring reviews? We try to do this in SCSI (usually > > > > > > only one review), but if all reviewers add a > > > > > > > > > > > > Reviewed-by: > > > > > > > > > > > > tag, which is accumulated in the tree, your pull machinery can > > > > > > detect it on all commits in the pull and give you an automated > > > > > > decision about whether to accept the pull or not. If you require > > > > > > two with one from a list of designated reviewers, it can do that as > > > > > > well (with a bit more complexity in the pull hook script). > > > > > > > > > > > > So here's the question: If I help you script this, would you be > > > > > > willing to accept pull requests in the media tree with this check > > > > > > in place? I'm happy to do this because it's an interesting > > > > > > experiment to see if we can have automation offload work currently > > > > > > done by humans. > > > > > > > > > > We could experiment something like that, provided that people will be > > > > > aware that it can be undone if something gets wrong. > > > > > > > > > > Yet, as we discussed at the Media Summit, we currently have an > > > > > issue: our infrastructure lack resources for such kind of > > > > > automation. > > > > > > > > This one doesn't require an automation infrastructure: the script runs > > > > as a local pull hook on the machine you accept the pull request from > > > > (presumably your laptop?) > > > > > > No, I run it on a 40-core HP server that it is below my desk. I turn it on > > > only when doing patch review (to save power, and because it produces a lot > > > of heat at the small room I work). > > > > > > Right now, I use a script with converts a pull request into a quilt tree. > > > Then, for each patch there, after a manual review, I run: > > > > I think this process can be improved/optimized: > > > > > - checkpatch --strict > > > > Should have been done by your (trusted) submaintainer that sent you > > the pull request. > > Things are getting better with time, but I still catch issues - with > seems to indicate that people sometimes forget to run it. > > On a recent case, I received a few pull requests lacking the SOB from > the patch author. But you can simply refuse pulling in such a fatal-error case, instead of fixing in your side. And in a trivial error case, you can apply the fix after pulling, too. A push-back stops the flow, but at the same time, it'd help subsystem maintainers learning something, so it's not always bad. thanks, Takashi