Messages in this thread | | | Date | Wed, 23 Sep 2009 14:22:56 +0200 | From | Ingo Molnar <> | Subject | Re: 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
| |