On Thu, 2019-09-12 at 07:17 -0700, Dan Williams wrote:
Ok, good to confirm that we do not yet have an objective standard
coding style. This means it's not yet something process documentation
can better standardize for contributors and will be subject to ongoing
taste debates. Lets reclaim the time to talk about objective items
that *can* clarified across maintainers.
No, let's not and just clarify whether or not whitespace
style patches are acceptable patch submissions.
Coding style fragmentation is not otherwise acceptable to me.
nvdimm mandating 2 tab indentation when nvdimm itself is not
at all consistent in that regard is also whitespace noise.
As for libnvdimm at this point I'd rather start with objective
checkpatch error cleanups and defer the personal taste items.
Fine by me.
I do want to avoid documenting per-subsystem coding styles.
How about adding something to MAINTAINERS like:
A: Accepting patches by newbies or CodingStyle strict
and checkpatch could be changed turn off a bunch of
whitespace rules on a subsystem basis when run with
-f for files or without -f for a patch.
Most of this comes down to whitespace like
a = b + c
where it hardly matters if the CodingStyle mandated
space around + is used or
foo = bar(baz,
where qux position is not really important.