[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160922144648.10efc7ac@endymion>
Date: Thu, 22 Sep 2016 14:46:48 +0200
From: Jean Delvare <jdelvare@...e.de>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: Joe Perches <joe@...ches.com>, Julia Lawall <julia.lawall@...6.fr>,
Al Viro <viro@...IV.linux.org.uk>,
Ilya Dryomov <idryomov@...il.com>,
Andy Whitcroft <apw@...onical.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jonathan Corbet <corbet@....net>,
Ceph Development <ceph-devel@...r.kernel.org>,
Alex Elder <elder@...nel.org>, Sage Weil <sage@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
kernel-janitors@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
linux-doc@...r.kernel.org
Subject: Re: "CodingStyle: Clarify and complete chapter 7" in docs-next
Hi Jani,
On Thu, 22 Sep 2016 13:43:42 +0300, Jani Nikula wrote:
> On Thu, 22 Sep 2016, Jean Delvare <jdelvare@...e.de> wrote:
> > You need to think in terms of actual use cases. Who uses checkpatch and
> > why? I think there are 3 groups of users:
> > * Beginners. They won't run the script by themselves, instead they will
> > submit a patch which infringes a lot of coding style rules, and the
> > maintainer will point them to checkpatch and ask for a resubmission
> > which makes checkpatch happy. Being beginners, they can only rely on
> > the script itself to only report things which need to be fixed, by
> > default.
> > * Experienced developers. Who simply want to make sure they did not
> > overlook anything before they post their work for review. They have
> > the knowledge to decide if they want to ignore some of the warnings.
> > * People with too much spare time, looking for anything they could
> > "contribute" to the kernel. They will use --subjective and piss off
> > every maintainer they can find.
> >
> > Sadly there's not much we can do about the third category, short of
> > killing option --subjective altogether.
>
> You could make checkpatch have different defaults for patches and files,
> to encourage better style in new code, but to discourage finding
> problems in existing code.
Fixing old code isn't wrong per se. It's good actually. But only if
done the right way by the right person. I don't think it makes any
sense to use this task as an introduction to kernel development for
newcomers. It doesn't teach them anything about the kernel, really.
--
Jean Delvare
SUSE L3 Support
Powered by blists - more mailing lists