Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1510854208.3063.33.camel@oracle.com>
Subject: Re: [PATCH 1/7] checkpatch: Implement new --ignore-cfg parameter
From:   Knut Omang <knut.omang@oracle.com>
To:     Joe Perches <joe@perches.com>, linux-kernel@vger.kernel.org
Cc:     Andy Whitcroft <apw@canonical.com>,
        Andrew Morton <akpm@linux-foundation.org>
Date:   Thu, 16 Nov 2017 18:43:28 +0100
In-Reply-To: <1510852186.31559.37.camel@perches.com>
References: <cover.3dd1d0c1f15a7a7c418f20ebafc9719afc1c2704.1510840787.git-series.knut.omang@oracle.com>
         <280c16fb1b8a645f0c62cea03f440fd0661af898.1510840787.git-series.knut.omang@oracle.com>
         <1510852186.31559.37.camel@perches.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, 2017-11-16 at 09:09 -0800, Joe Perches wrote:
> (adding Andrew Morton)
> 
> On Thu, 2017-11-16 at 18:01 +0100, Knut Omang wrote:
> > This parameter is intended to be used in a subsequent commit to kbuild to allow
> > a convenient way to run checkpatch from make.
> 
> _why_ is this useful?

The cover letter and the following documentation patch hopefully makes it 
clearer. 

I realize the cc: list on the cover letter was a little too narrow, sorry about that!

> > By accepting comments and multiple lines of commands, the idea is that the
> > maintainer or someone else with good knowledge of the code can maintain a file
> > per directory and group the different commands into commented sections that can
> > serve both as documentation of the current checkpatch status, a way to define
> > the line of tolerance (and gradually tighten it as fixes comes in) and as
> > documentation of TODOs and dont's if there are well justified exceptions.
> 
> checkpatch can be run any time over individual files
> so I don't find this compelling.

The problem with that in general is the noise level.
What this patch set gives is in short:

* a way to filter out the noise to focus on one type of error at the time
* the means to automate prevention of reoccurrence of some types of checkpatch 
  errors that have been removed from a file, even when that file has
  100s of checkpatch issues of other types.

> Does anyone else?

I did subject the set to a couple of internal reviews with positive feedback. 
We have also had automated checkin regression testing going with 
a similar system for some time.  I was just going to improve upon that system
when I realized that we should really make it available for the broader community.

I hope this helps,

thanks,
Knut

From 1584881854229943357@xxx Thu Nov 23 18:18:38 +0000 2017
X-GM-THRID: 1584366039367167465
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread