Hi Andy.The original purpose was to catch the most tivial coding style errors. But then people started to be far too innovative and we now ended up with a checkpatch that try to check for every lillte glory detail. It would be much preferable to have a checkpatch - and that may be an incarnation of the current one or a new one. What it should do would be to catch the trivialities that we see happens in many patch submissions like: a) wrong patch format (-p1, unified diff) b) Whitespace versus tabs c) PascalCasing in new functions d) excessive line length e) C99 comments '//' (not that I see why they are banned) and maybe a few more trivial chacks. This would benefit from a very low false-positive rate and it could then be used as a patch-bot. As it is now where it tries to check for everything and a bit more it generates too much noise so a patch-bot usage is not possible. And users get annoyed by the excessive output. If we then have the same script that in a -pedantic mode generate more noise - fine. But leave the default simple. Sam -
| Linus Torvalds | Linux 2.6.27-rc5 |
| Ingo Molnar | [announce] "kill the Big Kernel Lock (BKL)" tree |
| Christoph Lameter | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH iproute2] Re: HTB accuracy for high speed |
