> Did Ingo have the obligation to improve Con's work? Definitely not.Yes, and that's where the inequality is. Unless the maintainer does a really bad job or pisses off Linus, anyone who wants to merge his code into mainline pretty much has to get the blessing of the maintainer. On the other hand, as you just said, the maintainer has no such obligation. I think it's the maintainer's privilege, not right. I don't think it's the code superiority that decided the fate of the two schedulers. When CFS came out, the fate of SD was pretty much already decided. The fact is that Linus trusts Ingo, and as such he wants to merge Ingo's code. Of course I cannot say it's wrong, and Ingo's earned this it through years of hard work, but let's not kid ourselves and deny the obvious fact. I think Con was simply too frustrated after years of rejection. He could have been more diplomatic this time round. But no matter how he'd have done, once Ingo decided to write a new scheduler, the outcome was pretty much already decided. SD (and years of Con's work) inspired CFS. This is a fact. No matter how smart and capable Ingo is, he needs inspiration to keep the good work going. So I wish Ingo could work more closely with others and let them share a bit more credit which would just produce even better work. Hua -
| Ingo Molnar | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
