patch style checks

[Andy Whitcroft]

Andrew Morton wrote:
> On Thu, 26 Apr 2007 02:32:06 +0200 Arnd Bergmann <arnd@xxxxxxxx> wrote:
> 
>> On Thursday 26 April 2007, Andrew Morton wrote:
>>> It would be neat if someone could create and maintain a new
>>> scripts/spot-common-mistakes.  Feed it a unified diff and it would complain
>>> about newly-added code (and only newly-added code) which has busted
>>> whitespace, adds new semaphores, adds new kernel_thread calls, etc, etc.
>> http://patchstylecheck.googlecode.com/svn/trunk/patchstylecheckemail.pl
>> Might serve as a starting point for this. It doesn't have any semantic
>> checks right now, but I guess they can be added.
>>
> 
> 	print "Your patch is now worthy to be reviewed by a real person\n";
> 
> heh.  Yes, that looks like an ideal starting point.
> 
> Methinks it should do `exit 1' if anything was detected.

[Joel in case you'd not spotted this discussion, your
patchstylecheckemail script was found ...  Also this has produced a
little patch series improving the tool.  Where would you like that sent?]

As an experiment I took the -mm git repo and applied a modified versions
of the patchstylecheckemail.pl to all the of the commits reported
between 2.6.21-rc7 and 2.6.21-rc7-mm2.  The git version of -mm links
directly back to the real incoming git trees and so we get the
individual commits there also.

2.6.21-rc7-mm2 appears to contian some 4313 commits in total!!!  Of
these some 886 failed the style check; over 20%.  Obviously some of
these will be false positives, or actually better as they are than made
compliant.  I did have a quick look over a sample of the errors and bad
use of space at the start and end of line, plus overlength lines, and
the lack of spaces round operators seem to be the predominant errors
therein.

As these are coming from the git commits, we could consider sending an
email to those authors.  However, as we are only considering patches in
isolation we cannot see if they got fixed later for instance.

In an ideal world we would do the same sort of analysis on the files as
the appear in the HEAD of the tree.  Any lines in error then would be
attributed to an author and that author told to fix their mess.  Hmmm,
not so hard me thinks.

-apw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/