Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

[Tim Bird <tim.bird@sonymobile.com>]

On 07/17/2015 10:37 AM, Steven Rostedt wrote:
> As I know a few maintainers that like the "reverse-xmas-tree" order,
> perhaps we could add that to CodingStyle in a section of:
> 
> --- Some Maintainer's prefer these styles ---
> 
>  These are some extra styles that maintainers prefer. Some are strict
>  about these, others may not care. It doesn't hurt to add them.
> 
> Because things like reverse x-mas tree order isn't something people are
> against doing. But some may not care if you do or don't. So listing
> all the things that a few maintainers share, may be good.

OK - I had never even heard of reverse christmas-tree order before this 
discussion, so I did some research.  For those unfamiliar, it is
sorting things by line length (most commonly include file lines 
and variable declaration lines), from longest to shortest.  This
has the effect of somewhat randomizing these items relative to
each other, which reduces the probability of patch conflicts.

I think everyone has looked at where to put a new include statement,
or local variable declaration, and wondered where the best spot is.
The reverse-christmas-tree order rule provides a definitive answer
for this question, as well as decreases the chance of patch conflicts.
What's not to love?

Well, I think this is exactly the wrong solution to the problem
this rule is trying to solve.  First, this adds one more rule
(which only a few maintainers appear to care about) to the already
lengthy "death-by-a-thousand-cuts" patch submission process which
we've been discussing in this thread.  It's a trivial rule that's
easy to follow, and it reduces patch conflicts, which are a very
real maintainer burden to resolve.  But still it adds to the submission
process incrementally.

Also, it doesn't actually solve all patch conflicts on these lines -
it just decreases the probability of them.  And it does so in a way
that sacrifices human logic and readability to make the code easier
for tools to process.  Isn't this exactly backwards?

I've long thought that patch or wiggle should be able to ignore
context lines for include statements.  It might be possible with
some work to handle the variable declaration case as well.
I'll either work on this myself, or (this is more my style ;-) )
propose funding a project through the Linux Foundation to work on this.

I'm very interested in this topic of reducing the process of
submitting patches and easing maintainer load through automation.
Part of this would be to determine what things maintainers actually
spend their time responding to, that can be addressed through
automation.  I believe this discussion has been very helpful to 
highlight some issues that at least some maintainers have. But maybe a
brainstorming session at the summit would give more areas to
consider working on.
 -- Tim