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 E012BFE2 for ; Fri, 14 Jun 2019 13:58:12 +0000 (UTC) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 460A7711 for ; Fri, 14 Jun 2019 13:58:12 +0000 (UTC) Date: Fri, 14 Jun 2019 15:58:07 +0200 From: Greg KH To: Mauro Carvalho Chehab Message-ID: <20190614135807.GA6573@kroah.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190614102424.3fc40f04@coco.lan> Cc: James Bottomley , ksummit-discuss@lists.linuxfoundation.org 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 Fri, Jun 14, 2019 at 10:24:24AM -0300, Mauro Carvalho Chehab wrote: > Em Fri, 14 Jun 2019 13:12:22 +0300 > Laurent Pinchart escreveu: > > > Hi Mauro, > > > > On Thu, Jun 13, 2019 at 10:59:16AM -0300, Mauro Carvalho Chehab wrote: > > > Em Thu, 06 Jun 2019 19:24:35 +0300 James Bottomley escreveu: > > > > > > > [splitting issues to shorten replies] > > > > On Thu, 2019-06-06 at 17:58 +0200, Greg KH wrote: > > > >> On Thu, Jun 06, 2019 at 06:48:36PM +0300, James Bottomley wrote: > > > >>> This is probably best done as two separate topics > > > >>> > > > >>> 1) Pull network: The pull depth is effectively how many pulls your > > > >>> tree does before it goes to Linus, so pull depth 0 is sent straight > > > >>> to Linus, pull depth 1 is sent to a maintainer who sends to Linus > > > >>> and so on. We've previously spent time discussing how increasing > > > >>> the pull depth of the network would reduce the amount of time Linus > > > >>> spends handling pull requests. However, in the areas I play, like > > > >>> security, we seem to be moving in the opposite direction > > > >>> (encouraging people to go from pull depth 1 to pull depth 0). If > > > >>> we're deciding to move to a flat tree model, where everything is > > > >>> depth 0, that's fine, I just think we could do with making a formal > > > >>> decision on it so we don't waste energy encouraging greater tree > > > >>> depth. > > > >> > > > >> That depth "change" was due to the perceived problems that having a > > > >> deeper pull depth was causing. To sort that out, Linus asked for > > > >> things to go directly to him. > > > > > > > > This seems to go beyond problems with one tree and is becoming a trend. > > > > > > > >> It seems like the real issue is the problem with that subsystem > > > >> collection point, and the fact that the depth changed is a sign that > > > >> our model works well (i.e. everyone can be routed around.) > > > > > > > > I'm not really interested in calling out "problem" maintainers, or > > > > indeed having another "my patch collection method is better than yours" > > > > type discussion. What I was fishing for is whether the general > > > > impression that greater tree depth is worth striving for is actually > > > > correct, or we should all give up now and simply accept that the > > > > current flat tree is the best we can do, and, indeed is the model that > > > > works best for Linus. I get the impression this may be the case, but I > > > > think making sure by having an actual discussion among the interested > > > > parties who will be at the kernel summit, would be useful. > > > > > > On media, we came from a "depth 1" model, moving toward a "depth 2" level: > > > > > > patch author -> media/driver maintainer -> subsystem maintainer -> Linus > > > > I'd like to use this opportunity to ask again for pull requests to be > > pulled instead of cherry-picked. > > There are other forums for discussing internal media maintainership, > like the weekly meetings we have and our own mailing lists. You all have weekly meetings? That's crazy... Anyway, I'll reiterate Laurent here, keeping things as a pull instead of cherry-picking does make things a lot easier for contributors. I know I'm guilty of it as well as a maintainer, but that's only until I start trusting the submitter. Once that happens, pulling is _much_ easier as a maintainer instead of individual patches for the usual reason that linux-next has already verified that the sub-tree works properly before I merge it in. Try it, it might make your load be reduced, it has for me. thanks, greg k-h