From: Sam Ravnborg <sam@ravnborg.org>
To: Andy Whitcroft <apw@shadowen.org>
Cc: Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Randy Dunlap <rdunlap@xenotime.net>,
Joel Schopp <jschopp@austin.ibm.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] update checkpatch.pl to version 0.10
Date: Fri, 28 Sep 2007 18:51:55 +0200 [thread overview]
Message-ID: <20070928165155.GA8760@uranus.ravnborg.org> (raw)
In-Reply-To: <20070928100024.GB18163@shadowen.org>
Hi Andy.
> 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
next prev parent reply other threads:[~2007-09-28 16:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 15:00 [PATCH] update checkpatch.pl to version 0.10 Andy Whitcroft
2007-09-28 8:40 ` Ingo Molnar
2007-09-28 9:01 ` Andrew Morton
2007-09-28 9:22 ` Andy Whitcroft
2007-09-28 9:39 ` Ingo Molnar
2007-09-28 10:00 ` Andy Whitcroft
2007-09-28 10:46 ` Christian Borntraeger
2007-09-28 11:03 ` WANG Cong
2007-09-28 14:19 ` Jan Engelhardt
2007-09-28 16:57 ` Randy Dunlap
2007-09-28 10:49 ` Ingo Molnar
2007-09-28 13:21 ` Andy Whitcroft
2007-09-28 13:37 ` Pekka Enberg
2007-09-28 14:02 ` Andy Whitcroft
2007-09-28 15:50 ` Joel Schopp
2007-09-28 17:26 ` Randy Dunlap
2007-09-28 17:46 ` Andrew Morton
2007-09-29 9:22 ` Andy Whitcroft
2007-10-05 5:56 ` Ingo Molnar
2007-09-28 16:51 ` Sam Ravnborg [this message]
2007-09-28 9:44 ` Ingo Molnar
2007-09-28 9:52 ` Andy Whitcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070928165155.GA8760@uranus.ravnborg.org \
--to=sam@ravnborg.org \
--cc=akpm@linux-foundation.org \
--cc=apw@shadowen.org \
--cc=jschopp@austin.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rdunlap@xenotime.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox