Re: [Ksummit-discuss] [MAINTAINERS SUMMIT] Pull network and Patch Acceptance Consistency

[Greg KH <greg@kroah.com>]

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 <laurent.pinchart@ideasonboard.com> 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