Re: checkpatch as a tool (was Re: [RFC][PATCH] SCHED_EDF scheduling class)

[Ingo Molnar <mingo@elte.hu>]

* Joe Perches <joe@perches.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