[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1602280009110.22700@cbobk.fhfr.pm>
Date: Sun, 28 Feb 2016 00:14:19 +0100 (CET)
From: Jiri Kosina <jikos@...nel.org>
To: Chen Gang <chengang@...ndsoft.com.cn>
cc: Theodore Ts'o <tytso@....edu>, Jianyu Zhan <nasa4836@...il.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>, rientjes@...gle.com,
LKML <linux-kernel@...r.kernel.org>,
Michal Hocko <mhocko@...e.cz>,
Johannes Weiner <hannes@...xchg.org>, vdavydov@...tuozzo.com,
Dan Williams <dan.j.williams@...el.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
Chen Gang <gang.chen.5i5j@...il.com>
Subject: Re: [PATCH trivial] include/linux/gfp.h: Improve the coding styles
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
Powered by blists - more mailing lists