Re: [RFC][PATCH] SCHED_EDF scheduling class

[Daniel Walker <dwalker@fifo99.com>]

On Wed, 2009-09-23 at 17:58 +0300, Avi Kivity wrote:
> On 09/23/2009 05:50 PM, Daniel Walker wrote:
> > On Wed, 2009-09-23 at 14:25 +0200, Ingo Molnar wrote:
> >    
> >> * Avi Kivity<avi@redhat.com>  wrote:
> >>
> >>      
> >>>> 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.
> >>>        
> >> Exactly. What might make sense is to scan linux-next for new commits
> >> that show serious cleanliness trouble - and send fix patches to the
> >> parties involved. That's a real effort and brings the code forward.
> >>      
> > Often times when a patch is at youngest that when you want to catch
> > these issues .. This EDF patch will likely get submitted more than
> > twice. If you catch all the minor problems first you will not be dealing
> > with them later when it comes time to include the code.
> >    
> 
> Not true, you want to address the major issues first.  What's the point 
> of fixing whitespace if the whole approach is rejected? if it has to 
> undergo a rewrite? (not an opinion on EDF btw, just as an example)

I'm not sure why your fixated on whitespace , but thinking about it more
I don't think it matters .. If you fix whitespace or major issues first,
it doesn't matter .. All the issues have to eventually get fixed .. Not
to mentioned that LKML is not something you could remotely control in
that way.

> > In this case the author is not totally aware of how to submit this
> > code.. I don't think it's at all inappropriate to comment on that. His
> > next submission will likely be much cleaner and nicer. It may even speed
> > up the inclusion process since he'll be more easily able to submit the
> > code (with practice and comments from us).
> >    
> 
> Give people some credit.

What do you mean?

Daniel