lkml.org 
[lkml]   [2009]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: checkpatch as a tool (was Re: [RFC][PATCH] SCHED_EDF scheduling class)

* 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


\
 
 \ /
  Last update: 2009-09-23 14:25    [W:0.089 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site