On Sat, 28 Jul 2007, jos poortvliet wrote:Actually, the tag you were looking for was "<clueless>" 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? Nobody is very good at self-reflection, I'm afraid. 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"? 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 -
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Tejun Heo | [PATCH 2/5] sysfs: simplify sysfs_rename_dir() |
| Andi Kleen | [PATCH x86] [0/16] Various i386/x86-64 changes |
| Dave Hansen | Re: [RFC/PATCH] Documentation of kernel messages |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Thomas Gleixner | Re: [BUG] New Kernel Bugs |
