lkml.org 
[lkml]   [2007]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ck] Re: Linus 2.6.23-rc1


On Sat, 28 Jul 2007, jos poortvliet wrote:
>
> <sarcasm>

Actually, the tag you were looking for was "<clueless>"

> http://osnews.com/permalink.php?news_id=18350&comment_id=259044
>
> Now I wonder. Apparently, one person complaining about SD was reason to keep
> it out http://osnews.com/permalink.php?news_id=18350&comment_id=258997
>
> Will this first post stop CFS from entering the kernel?

You seem to be not understanding the argument.

It wasn't about "one person complaining". Of *course* people will
complain. That always happens, and sometimes with totally bogus complaints
(the most common being "I'm not used to it").

The problem was the reaction to complaints.

Ingo got lots of complaints too. He was very responsive to them (which is
not something surprising - he's been doing this a long time), and while
some of the tangents he went off on were definitely bogus (the whole
renicing thing), they were still useful as part of the discussion.

And Ingo got other - totally unrelated - developers involved too, ie the
group fairness logic came from Vatsa. And he ended up supporting not just
scheduler people, but also talking to the block layer people ahout the
scheduler timer usage as a fast clock for block requests etc.

And you have to realize that to me, as the top-level maintainer and one
who seldom actually does big coding things, but just ends up making sure
that people work with others, and fix the problems that crop up, *that*
kind of behaviour is much much MUCH more important than the code itself.

Can you see that?

Can you see how big of a difference those whole approaches make?

> Now I'll try to be a bit more constructive. I hope your benevolent
> dictatorship allows self reflection.

Nobody is very good at self-reflection, I'm afraid.

> Sure, the difference in behaviour (not in code) between SD and CFS is small,
> and for me it doesn't matter. I'm fine with CFS in the kernel, it's a huge
> improvement over the previous one. But why, while there was a seemingly good
> alternative, did THAT one stay in that long? And this argument goes for more
> code 'out there', btw.

Actually, nobody pushed SD to me, and neither Con nor anybody else tried
to get me to merge it until some time in March of this year, I think.

Do you think I go trolling for code to merge? No. I actually _require_
that people send it to me, and that I also get the feeling that people are
asking for it!

In other words, my job is not to "merge code" (even though I sometimes
describe it that way), my job is actually largely to "say no". You
shouldn't see me as the person who goes out and tries to get everything
together - quite the reverse. My job is to say "too late for the merge
window", or "too experimental", or "you need to show numbers" or "are
there going to be any _users_ for this"?

> Some things get into the kernel, other don't. Some get in too soon, others
> too late. Sure. But shouldn't we try to improve this process, instead of
> saying 'it is what it is, get over it'?

Umm. The absolute *last* thing we want to do is to merge earlier. In fact,
one of our biggest problems is that people send half-cooked stuff to me
(and even more so, to Andrew).

So in this case, if you've been on the CK mailing list, ask yourself: why
wasn't parts of it pushed up to the standard kernel? Asking "why didn't
Linus take it earlier" is exactly the wrong thing to do, since nobody even
_asked_ me to. I never _ever_ got a patch saying "please merge this".

Seriously.

(Btw, on that note: please don't send me patches saying "please merge
this". I want more than just that. I want an explanation, and I want it to
be in many small pieces, and I want to feel like it got tested and is
likely to be an obvious improvement).

So now look at what happened to CFS:

- Ingo pushed it, and has been a maintainer of the area and shown himself
over years to be able to work with others and react to reports of
problems.

- It was fairly obviously an improvement over the previous status quo
(although I expect that there will be regressions - almost nothing is
ever a _pure_ improvement, if it's in any way non-trivial)

- Even so, I asked for (and got) a series of independent patches.

Compare this to SD for a while. Ponder.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-07-28 20:31    [from the cache]
©2003-2011 Jasper Spaans