Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles

[Jiri Kosina]

On Sat, 27 Feb 2016, Chen Gang wrote:

> > Mel, as an MM developer, has already NACK'ed the patch, which means
> > you should not send the patch to **any** upstream maintainer for
> > inclusion.
> 
> I don't think I "should not ...". I only care about correctness and
> contribution, I don't care about any members ideas and their thinking.
> When we have different ideas or thinking, we need discuss.

If by "discuss" you mean "30+ email thread about where to put a line 
break", please drop me from CC next time this discussion is going to 
happen. Thanks.

> For common shared header files, for me, we should really take more care
> about the coding styles.
> 
>  - If the common shared header files don't care about the coding styles,
>    I guess any body files will have much more excuses for "do not care
>    about coding styles".
> 
>  - That means our kernel whole source files need not care about coding
>    styles at all!!
> 
>  - It is really really VERY BAD!!
> 
> If someone only dislike me to send the related patches, I suggest: Let
> another member(s) "run checkpatch -file" on the whole "./include" sub-
> directory, and fix all coding styles issues.

Which is exactly what you shouldn't do.

The ultimate goal of the Linux kernel is not 100% strict complicance to 
the CodingStyle document no matter what. The ultimate goal is to have a 
kernel that is under control. By polluting git blame, you are taking on 
aspect of the "under control" away.

Common sense needs to be used; horribly terrible coding style needs to be 
fixed, sure. Is 82-characters long line horribly terrible coding style? 
No, it's not.

Thanks,

-- 
Jiri Kosina
SUSE Labs