Hi Andy.
quoted text
> I think it is clear that we differ on what should and should not be
> output by default.  Clever people are able to opt out of the warnings,
> of things they think they dissagree with.  It is the people with little
> experience who need the most guidance and those people who the tool
> should target by default.  You cannot expect someone with no experience
> to know they need to add '--i-need-more-help' whereas _you_ I can expect
> to say '--leave-me-alone' or indeed to make the call that the output is
> plain wrong and _you_ know you should ignore it.

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
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/