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

[Greg KH <greg@kroah.com>]

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.

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.)

So, maybe some work on fixing up subsystems that have problems
aggregating things?  Seems like some areas of the kernel do this just
fine, perhaps some workflow for the developers involved needs to be
adjusted?

> 2) Patch Acceptance Consistency: At the moment, we have very different
> acceptance criteria for patches into the various maintainer trees. 
> Some of these differences are due to deeply held stylistic beliefs, but
> some could be more streamlined to give a more consistent experience to
> beginners who end up doing batch fixes which cross trees and end up
> more confused than anything else.  I'm not proposing to try and unify
> our entire submission process, because that would never fly, but I was
> thinking we could get a few sample maintainer trees to give their
> criteria and then see if we could get any streamlining.  For instance,
> SCSI has a fairly weak "match the current driver" style requirement, a
> reasonably strong get someone else to review it requirement and the
> usual good change log and one patch per substantive change requirement.
>  Other subsystems look similar without the review requirement, some
> have very strict stylistic requirements (reverse christmas tree, one
> variable definition per line, etc).  As I said, the goal wouldn't be to
>  beat up on the unusual requirements but to see if we could agree some
> global baselines that would at least make submission more uniform.

I thought Dan's "maintainer document" was going to help resolve things
like this, both putting in writing just what those rules were, as well
as help point out where things might be going too far in one direction
or another in a much easier way, as they could be compared.

thanks,

greg k-h