(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?
> 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.
Does anyone else?
From 1584259533694640943@xxx Thu Nov 16 21:27:07 +0000 2017
X-GM-THRID: 1584246136620373906
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread
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