linux-kernel - Re: checkpatch as a tool (was Re: [RFC][PATCH] SCHED

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20090923122256.GA6390@elte.hu>
Date:	Wed, 23 Sep 2009 14:22:56 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Joe Perches <joe@...ches.com>
Cc:	Daniel Walker <dwalker@...o99.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	Jonathan Corbet <corbet@....net>
Subject: Re: checkpatch as a tool (was Re: [RFC][PATCH] SCHED_EDF
	scheduling class)

* Joe Perches <joe@...ches.com> wrote:

> On Tue, 2009-09-22 at 17:51 -0700, Daniel Walker wrote:
> > I'll stop sending those
> > emails if it's actually negative , but I don't think it is..
> 
> Hi Daniel.
> 
> I think it'd be more helpful if instead of merely sending
> a "hah! checkpatch failure!" email you send the submitter
> a gentler nudge and a fixed patch.

He should consider not sending them at all. It's up to maintainers and 
the developers involved with that code whether the small details that 
checkpatch flags are important or not at a given point in the patch 
cycle.

For example i use checkpatch all the time and i think it's a fantastic 
tool, still i dont want another nuisance layer on lkml interfering with 
the patch flow.

If a patch gets so far in the patch cycle that i'm thinking about 
merging it, i might fix the checkpatch failures myself (often they are 
trivial), and i might warn frequent contributors about repeat patterns 
of small uncleanlinesses - or i might bounce the patch back to the 
contributor. I also ignore certain classes of checkpatch warnings.

What Daniel is doing is basically a semi-mandatory checkpatch layer on 
lkml and that's both a distraction and harmful as well. We dont need a 
"checkpatch police" on lkml. We want an open, reasonable, human driven 
patch process with very little buerocracy and no buerocrats.

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