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 for > 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, qux) where qux position is not really important.