From: Graeme Russ <graeme.russ@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Policy for checkpatch usage?
Date: Fri, 22 Apr 2011 10:43:27 +1000 [thread overview]
Message-ID: <4DB0CF2F.2020701@gmail.com> (raw)
In-Reply-To: <20110421111036.2abb4255@schlenkerla.am.freescale.net>
On 22/04/11 02:10, Scott Wood wrote:
> On Thu, 21 Apr 2011 16:29:17 +0200
> Detlev Zundel <dzu@denx.de> wrote:
>
>> Hi Scott,
>>
>>> I vote for "checkpatch is a tool that can help you find some style problems,
>>> but is imperfect, and the things it complains about are of varying
>>> importance". If you insist on zero warnings, what's the difference between
>>> a warning and an error? And will there then be a U-Boot-specific coding
>>> style document to match? Will anyone that wants to submit a patch that
>>> checkpatch erroneously complains about have to first submit a patch for
>>> checkpatch (first learning Perl if need be)?
>>
>> So you would agree to this text:
>>
>> Checkpatch is a tool that can help you find some style problems, but is
>> imperfect, and the things it complains about are of varying importance.
>> So use common sense in interpreting the results. Warnings that clearly
>> only make sense in the Linux kernel can be ignored.
>
> Yes.
>
> That said, if someone wants to maintain a U-Boot version, that'd be great.
So, if someone maintains a U-Boot fork of checkpatch, keeps it up-to-date
with the Linux version, and pushes patches back up to Linux (to keep them
is sync as much as practicable possible) would we agree that that would be
the most favoured solution?
I'm looking at checkpatch now (and its change history) - If I think I can
take it on, I will send out a call for U-Boot specific checkpatch features
Regards,
Graeme
next prev parent reply other threads:[~2011-04-22 0:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-20 9:24 [U-Boot] Policy for checkpatch usage? Detlev Zundel
2011-04-20 10:15 ` Graeme Russ
2011-04-20 12:43 ` Graeme Russ
2011-04-20 13:40 ` Detlev Zundel
2011-04-20 13:38 ` Detlev Zundel
2011-04-20 16:51 ` Scott Wood
2011-04-21 0:09 ` Graeme Russ
2011-04-21 5:18 ` Wolfgang Denk
2011-04-21 14:24 ` Detlev Zundel
2011-04-21 14:29 ` Detlev Zundel
2011-04-21 14:49 ` Eric Cooper
2011-04-21 14:56 ` Fabian Cenedese
2011-04-21 15:04 ` Eric Cooper
2011-04-21 15:37 ` Detlev Zundel
2011-04-21 15:19 ` Detlev Zundel
2011-04-21 15:46 ` Detlev Zundel
2011-04-23 15:29 ` Andreas Pretzsch
2011-04-27 9:07 ` Detlev Zundel
2011-04-21 16:10 ` Scott Wood
2011-04-22 0:43 ` Graeme Russ [this message]
2011-04-22 6:18 ` Albert ARIBAUD
2011-04-22 10:56 ` Graeme Russ
2011-04-22 8:54 ` Wolfgang Denk
2011-04-22 10:52 ` Graeme Russ
2011-04-22 12:46 ` Wolfgang Denk
2011-04-25 5:37 ` Graeme Russ
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=4DB0CF2F.2020701@gmail.com \
--to=graeme.russ@gmail.com \
--cc=u-boot@lists.denx.de \
/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