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

[josh@joshtriplett.org]

On Fri, Jul 17, 2015 at 03:43:26PM -0400, Steven Rostedt wrote:
> On Fri, 17 Jul 2015 12:02:23 -0700
> josh@joshtriplett.org wrote:
> > > --- 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.
> > 
> > A world of *no*.  If your style is not universal, and you can't get a
> > general consensus among kernel maintainers that it should be a
> > requirement across the entire kernel, then *no*.  We should not have
> > per-subsystem formatting rules.
> >
> 
> Um, we have it today, and we'll have it tomorrow. Sorry, but the Linux
> kernel is not run by management. It's a huge community effort with
> some of the brightest minds in the world working on it. Each subsystem
> of the kernel is a project in itself. We're lucky we have the consensus
> that we have.

Documenting it is giving up and saying it's OK for this to happen,
rather than continuing to address issues as we discover them.  At the
moment, there's one well-known one (the comment item mentioned below),
and it exists mostly as an extension of the standard rule "match the
surrounding code rather than rewriting it".  That isn't carte blanche
for intentionally having a gratuitously different style in different
files.

> > > /*
> > >  * What is the question?
> > >  * To add a space at the top of a comment?
> > >  */
> > > 
> > > /* Or not to add a space at the top of a comment?
> > >  * That is the question!
> > >  */
> > 
> > While I'm not going to advocate that we mass-fix existing code in a
> > subsystem for consistent formatting, this is *exactly* the kind of thing
> > that we do not need any more of; one such idiosyncrasy is one too many.
> 
> Then there's no issue here. Each maintainer is free to tell people to
> x-mas tree their variables or not.

And other maintainers can and should tell them to cut it out.  I'm not
suggesting this problem should be solved by top-down management, but by
community consensus.

> Look, kernel development is complex
> and if your biggest hangup of getting a patch into the kernel is that
> the maintainer requires you to modify some whitespace on rearrange your
> variables, then you probably should get out of kernel development and
> enter a field of bike shed exterior design.

If your biggest hangup as a maintainer is that people send you patches
that don't have variables sorted in some particular order, perhaps you
should get out of kernel development and get into bike shed colorimetry
consulting.  We have enough problems getting quality patches by the
metrics that *actually* correlate to quality.  And as others have
pointed out in this thread, many people produce patches across numerous
subsystems.

- Josh Triplett