[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ABA0AA6.3010408@redhat.com>
Date: Wed, 23 Sep 2009 14:46:46 +0300
From: Avi Kivity <avi@...hat.com>
To: Daniel Walker <dwalker@...o99.com>
CC: Jonathan Corbet <corbet@....net>, Raistlin <raistlin@...ux.it>,
Peter Zijlstra <peterz@...radead.org>, claudio@...dence.eu.com,
michael@...dence.eu.com, mingo@...e.hu,
linux-kernel@...r.kernel.org, tglx@...utronix.de,
johan.eker@...csson.com, p.faure@...tech.ch,
Fabio Checconi <fabio@...dalf.sssup.it>,
Dhaval Giani <dhaval.giani@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Tommaso Cucinotta <tommaso.cucinotta@...up.it>
Subject: Re: [RFC][PATCH] SCHED_EDF scheduling class
On 09/23/2009 03:40 AM, Daniel Walker wrote:
> I am trying to make the kernel (or community) better, but my motivation
> is purely my own (as it often is with people on this list) ..
>
> I don't see the effects your indicating, discouraging contributions .. I
> think if anything I'm helping people to get to a place where they can
> contribute in a comfortable way without worrying about things like
> checkpatch .. I think the problem most submitters have on this list is
> that no one tells them they are doing something wrong so they don't
> correct it. I clearly recall submitting my first several patches
> copy-and-pasted which got either ignored , or caused a maintainer lots
> of pain .. Had I been told earlier that it was a problem I would have
> corrected it immediately (and been happy to have been notified about
> it)..
>
>
Look at the context. Here we have a new scheduling class introduced out
of the blue. The discussion should be around whether it makes sense; if
it does, whether the design is good or not; if it is, whether the code
is maintainable or not, if that passes, whether there are bugs in the
code or not. Until we've decided that Linux needs this scheduling class
and that this patchset is well designed and written, spelling errors are
just a nuisance and distract people from the important issues.
> discouraging contributions is more something that happens when you get
> the responses I got earlier in this thread..
>
That's probably intentional. Whitespace fixes have their place but not
at this stage in a patch's lifecycle.
--
error compiling committee.c: too many arguments to function
--
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/
Powered by blists - more mailing lists