Hi,
On Sat, 28 Jul 2007, Linus Torvalds wrote:
> We've had people go with a splash before. Quite frankly, the current
> scheduler situation looks very much like the CML2 situation. Anybody
> remember that? The developer there also got rejected, the improvement was
> made differently (and much more in line with existing practices and
> maintainership), and life went on. Eric Raymond, however, left with a
> splash.
Since I was directly involved I'd like to point out a key difference.
http://lkml.org/lkml/2002/2/21/57 was the very first start of Kconfig and
initially I didn't plan on writing a new config system. At the beginning
there was only the converter, which I did to address the issue that Eric
created a complete new and different config database, so the converter was
meant to create a more acceptable transition path. What happened next is
that I haven't got a single response from Eric, so I continued hacking on
it until was complete.
The key difference is now that Eric refused the offered help, while Con
was refused the help he needed to get his work integrated.
When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had
already pretty much lost. I have no doubt that Ingo can quickly transform
an idea into working code and I would've been very surprised if he
wouldn't be able to turn it into something technically superior. When Ingo
figured out how to implement fair scheduling in a better way, he didn't
use this idea to help Con to improve his work. He decided instead to
work against Con and started his own rewrite, this is of course his right
to do, but then he should also accept the responsibility that Con felt his
years of work ripped apart and in vain and we have now lost a developer
who tried to address things from a different perspective.
bye, Roman
Roman Zippel wrote:
> When Ingo posted his rewrite http://lkml.org/lkml/2007/4/13/180, Con had
> already pretty much lost. I have no doubt that Ingo can quickly transform
> an idea into working code and I would've been very surprised if he
> wouldn't be able to turn it into something technically superior. When Ingo
> figured out how to implement fair scheduling in a better way, he didn't
> use this idea to help Con to improve his work. He decided instead to
> work against Con and started his own rewrite, this is of course his right
> to do, but then he should also accept the responsibility that Con felt his
> years of work ripped apart and in vain and we have now lost a developer
> who tried to address things from a different perspective.
When Ingo wrote something that went head-on with what Con wrote, it was his
prerogative to do so. There's no speaking here of rights to do or not to
do since as matter of evidence, in the open source world, that which is
superior (i.e. code, function, not person) has the right to exist and the
inferior to die away. Did Ingo have the obligation to improve Con's work?
Definitely not. Did Con have a right to get Ingo's improvements or
suggestions? Definitely not. There are no such rights in this open source
development framework (TM).
What Ingo did, I think, was what he wanted and he has the right to do that.
I believe that Ingo does not have an obligation to be responsible
for what Con felt. You feel what you feel because you choose to feel that
way. Let us remember that "Happiness is a choice, not a state."
And let's just look at the attitudes on how both Ingo and Con reacted to
the issues regarding their respective schedulers. I won't list them here
now since they're all there in the archives.
Since attitude also plays a big part in getting your code in mainline, I
think we would know the reason why one got chosen for the other.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
> Did Ingo have the obligation to improve Con's work? Definitely not.
> Did Con have a right to get Ingo's improvements or
> suggestions? 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.
> There are no such rights in this open source
> development framework (TM).
>
> What Ingo did, I think, was what he wanted and he has the right to do
> that.
I think it's the maintainer's privilege, not right.
> in the open source world, that which is superior (i.e. code, function,
> not person) has the right to exist and the inferior to die away.
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
On Tue, 2007-07-31 at 23:16 -0700, Hua Zhong wrote:
> > Did Ingo have the obligation to improve Con's work? Definitely not.
> > Did Con have a right to get Ingo's improvements or
> > suggestions? 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 a lot of people are missing some key things here:
It does not matter who's code gets merged.
The CFS-SD competition was a GOOD THING. Both sides were in heavy, fast
improvement mode, and competed on all fronts and borrowed heavily from
eachother in terms of ideas that worked, and innovated to stay ahead.
The end result is that both were good schedulers, and Linux won by
getting the fruit of this competition. Think of it as a mini-evolution
of scheduler ideas compressed into a short time period.
Now compare this to a single patch without competition/the need to
survive in the habitat, say the first SD or the first CFS patch....
whatever your poison is. If there had been no competition element, we
would have ended up with either one of those, and it would have been not
nearly as good as they both ended up as in the end.
Who wrote the code is not relevant in the large picture, the fact that
the problem at hand (2.6 scheduler behavior) got solved is.
I wish people would focus less on who wrote the actual code that got
merged in the end, and more on the problem that got solved.... People
who care about the desktop should be happy that the scheduler improved a
lot due to the competition where the two new schedulers were hair-close
in most aspects. Again.. think about the problem being solved. Not who
wrote the code or which of the competitive patches got merged in the
end.
Let me repeat the key message:
It does not matter who's code gets merged.
It does not matter who's code gets merged.
It does not matter who's code gets merged.
It does not matter who's code gets merged.
What matters is that the problem gets solved and that the Linux kernel
innovates forward.
I've had several cases myself where I spent quite some time solving a
problem, just to get some random remark from someone smart on lkml
saying "if you had done <this simple thing> you would have had <this
simple and superior solution>". Was I pissed off that my patch didn't
get merged but that this better approach got picked? NO! The problem
that I needed to solve got solved in a really good way. Mission
accomplished.
(and merging the code that is cleaning up/smallest is a reasonable one
to pick for someone like Linus, likewise for the "which is likely to be
maintained best" arguments)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Hua Zhong wrote:
> 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 agree with you here. It's not simply code superiority that matters but a
balance of attitude and the code's corroboration with numbers. Both had
numbers to show but I think that one's attitude was preferred over the other.
> 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.
I don't see where credit was lacking. As far as I've observed, SD's author
was given acknowledgment on what he did and even got praise.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
Arjan van de Ven wrote:
> Let me repeat the key message:
>
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
>
> What matters is that the problem gets solved and that the Linux kernel
> innovates forward.
This, I think, is what really really matters in the end.
> I've had several cases myself where I spent quite some time solving a
> problem, just to get some random remark from someone smart on lkml
> saying "if you had done <this simple thing> you would have had <this
> simple and superior solution>". Was I pissed off that my patch didn't
> get merged but that this better approach got picked? NO! The problem
> that I needed to solve got solved in a really good way. Mission
> accomplished.
>
> (and merging the code that is cleaning up/smallest is a reasonable one
> to pick for someone like Linus, likewise for the "which is likely to be
> maintained best" arguments)
Very rational. I would now have to contend that CFS didn't lose and
neither did SD. Linux won.
Thank you very much.
Best Regards,
Carlo
--
Carlo Florendo
Softare Engineer/Network Co-Administrator
Astra Philippines Inc.
UP-Ayala Technopark, UP Campus Diliman
1101 Quezon City, Philippines
http://www.astra.ph
--
The Astra Group of Companies
5-3-11 Sekido, Tama City
Tokyo 206-0011, Japan
http://www.astra.co.jp
On 8/1/07, Arjan van de Ven <[email protected]> wrote:
> Let me repeat the key message:
>
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
> It does not matter who's code gets merged.
>
> What matters is that the problem gets solved and that the Linux kernel
> innovates forward.
And, from a standpoint of ONGOING, long-term innovation: what matters
is that brilliant, new ideas get rewarded one way or another. Because
if you don't, the people with the 'different' ideas walk away, you end
up with only those who 'fit' the culture, and there goes innovation.
That's why I tried to get involved in this discussion. It doesn't
matter who's code gets merged. But it does matter that people get
scared away. It took the kernel folks a few years, but they managed to
get someone kicked out who's not 'in-crowd', who clearly has a
different view, and who has the intent and motivation to write and
maintain code.
And that's bad.
I've quoted this before: Reward Brilliant Failures, Punish Mediocre Successes.
Of course that's 'overdone', but it conveys a point: If you focus too
much on exploiting current code, instead of fundamentally exploring
new ideas you go down in the long run. There has to be a balance. And
in some area's of the kernel, there seems to be a good balance - new
ideas come in, code is being re-factored. But in scheduling and VM, I
wonder if there's enough exploration...
I hear 'We don't do politics' a lot in the kernel community.
Well, what are politics? Managing the way code gets into the kernel?
That's important for sure, right? And what about thinking about the
hacker culture? Nobody would object to preserving and securing that.
But those are not just technical matters. Yet they require thought. If
the kernel culture doesn't work, the code won't work. There is a
delicate balance, and a key part of what Linus has been doing is
preserving it. I think he must not ignore that there is always room
for improvement, and moments like these (where a big 'fight' is going
on, and there is a clear sense of urgency about the matter) are the
perfect times for a good discussion, and possible change.
Use it.
Love,
Jos
* Disclaimer:
- I'm no kernel hacker
- actually I help at the KDE project in the area of marketing...
- yet, i have followed Con and his stuff for years
- and I do research in the area of promoting innovation in
organisations at a Dutch research institute, which is why I so
annoyingly think I might have something to say.
> has to get the blessing of the maintainer. On the other hand,
> as you just said, the maintainer has no such obligation.
Umm nope. As a maintainer if you feed Linus stuff you wrote that he
thinks is a bad idea it will not go in, and you'll get an explanation of
why.
The process isn't perfect (eg removing half-vanished maintainers isnt
handled well) but it isn't as you claim.
On Wed, 2007-08-01 at 10:14 +0200, [email protected] wrote:
> On 8/1/07, Arjan van de Ven <[email protected]> wrote:
> > Let me repeat the key message:
> >
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> >
> > What matters is that the problem gets solved and that the Linux kernel
> > innovates forward.
>
> And, from a standpoint of ONGOING, long-term innovation: what matters
> is that brilliant, new ideas get rewarded one way or another.
and in this case, the reward is that the idea got used and credit was
given....
> Because
> if you don't, the people with the 'different' ideas walk away, you end
> up with only those who 'fit' the culture, and there goes innovation.
yet at the same time if people walk away just because their code didn't
get used, even though their problem got solved, should we merge "worse"
code just to prevent that ? That's almost blackmail, and also just
stupid.
(not suggesting that SD in this case was better or worse, just trying to
make a general point)
> That's why I tried to get involved in this discussion. It doesn't
> matter who's code gets merged. But it does matter that people get
> scared away. It took the kernel folks a few years, but they managed to
> get someone kicked out who's not 'in-crowd', who clearly has a
> different view, and who has the intent and motivation to write and
> maintain code.
And he did manage to get some of his code in, just not all. He also
managed to get people interested in his problem so much that a healthy
stint of competition happened and his problem got solved. If people walk
away because they don't 100% always get things done EXACTLY their way..
well so be it.
> Of course that's 'overdone', but it conveys a point: If you focus too
> much on exploiting current code, instead of fundamentally exploring
> new ideas you go down in the long run.
here's the thing. Fair scheduling DID get explored. deeply so.
now, getting people interested in your problem (and that is needed to
get them to pay attention to it) is a sales job, no ifs and buts there.
You need to convince them that 1) the problem is real, 2) the problem is
relevant. If you also have a proposed solution you also need to convince
them that 3) the solution solves the problem and 4) that it's the right
way to solve the problem. That isn't politics, it's part of how the
ecosystem works; people are not stupid, but you need to convince them
about your problem and solution. And that "default a bit skeptical and
overworked" approach is the foundation of the process; the same way as
you need to pass a code review before people will merge your code.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
> > And, from a standpoint of ONGOING, long-term innovation: what matters
> > is that brilliant, new ideas get rewarded one way or another.
>
> and in this case, the reward is that the idea got used and credit was
> given....
You mean, when Ingo announced CFS he mentioned Con's name?
I really doubt that is the best reward for a developer.
> > Because if you don't, the people with the 'different' ideas walk away,
> > you end up with only those who 'fit' the culture, and there goes
innovation.
>
> yet at the same time if people walk away just because their code didn't
> get used, even though their problem got solved, should we merge "worse"
> code just to prevent that ? That's almost blackmail, and also just
> stupid.
>
> (not suggesting that SD in this case was better or worse, just trying
> to make a general point)
If it is a general point, sure, but it's hardly 1/10 of what happened
here. And note I don't agree with Con's decision either - I wish he'd
be back, but the reason I jumped in was to show some understanding, as
I see some comments in the thread that were not doing so.
When you said "it does not matter whose code got merged", I have to
disagree. Sure, for the Linux community as a whole, for Linux itself,
it may not matter, but for the individuals involved, it does. And I
think benefits of individuals are as important as benefits of the
community (or the nation).
Con has been working on scheduler (fair or not) for years, and nothing
got merged. Yet CFS got merged in a blink despite the fact that the
competition just began to show. Have we given SD a fair chance? No.
Ingo has a unique position that nobody else could challenge. Note I
have said that he earned it through hard work and talent, so that's
not the problem. The problem is how he could have handled it better,
not "grab the food right under other's nose" blatantly.
I don't think merging CFS was a wrong decision. The problem was how
this decision was made. And I think Linus made some rather unfair
comments about Con's personality, and I don't think deeply that
was the reason he merged Ingo's code.
Hua
On Wed, 2007-08-01 at 11:40 -0700, Hua Zhong wrote:
> > > And, from a standpoint of ONGOING, long-term innovation: what matters
> > > is that brilliant, new ideas get rewarded one way or another.
> >
> > and in this case, the reward is that the idea got used and credit was
> > given....
>
> You mean, when Ingo announced CFS he mentioned Con's name?
and put his name in the code too
> When you said "it does not matter whose code got merged", I have to
> disagree. Sure, for the Linux community as a whole, for Linux itself,
> it may not matter, but for the individuals involved, it does. And I
> think benefits of individuals are as important as benefits of the
> community (or the nation).
I agree it's a nice ego boost to see your code merged.
But... do you care more about your ego boost or about your problem
getting solved? I really want to change this if you say "ego for code
merging"... "ego boost for getting linux improved and being involved in
solving an important problem" is a lot better type of ego boost..
No developer can or should expect that most, or even half of his code to
be merged. Even Linus doesn't get half the code he writes into linux :)
Con did get a whole bunch of stuff merged over the years, and for the
rest he mostly got the problem solved. That's pretty successful....
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
On Wed, Aug 01, 2007 at 12:05:01AM -0700, Arjan van de Ven wrote:
> I've had several cases myself where I spent quite some time solving a
> problem, just to get some random remark from someone smart on lkml
> saying "if you had done <this simple thing> you would have had <this
> simple and superior solution>". Was I pissed off that my patch didn't
> get merged but that this better approach got picked? NO! The problem
> that I needed to solve got solved in a really good way. Mission
> accomplished.
Hey to me it even happened I had this nice and safe pte-highmem patch
but the buggy highpte was merged instead, go figure. Con got lucky.
Arjan van de Ven <[email protected]> writes:
> [...]
> It does not matter [whose] code gets merged.
> What matters is that the problem gets solved and that the Linux kernel
> innovates forward.
> [...]
This attitude has risks over the long term, if outsiders with fresh
ideas are discouraged. Risking becoming known to defer too much to
established maintainers, those fresh ideas may stop coming to linux.
- FChE
On Thu, 2007-08-02 at 16:03 -0400, Frank Ch. Eigler wrote:
> Arjan van de Ven <[email protected]> writes:
>
> > [...]
> > It does not matter [whose] code gets merged.
> > What matters is that the problem gets solved and that the Linux kernel
> > innovates forward.
> > [...]
>
> This attitude has risks over the long term, if outsiders with fresh
> ideas are discouraged. Risking becoming known to defer too much to
> established maintainers, those fresh ideas may stop coming to linux.
My concern is that only "get my line of code merged" is seen as "the
ultimate thing". It's more than that. Linux is about collaboration,
where it matters more that people work together to solve a problem, far
far more than who actually types the lines in on the keyboard. Working
on the problem should be seen (and recognized) as the right thing. Who
writes the code is secundary to that.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Hi -
> My concern is that only "get my line of code merged" is seen as "the
> ultimate thing". It's more than that. Linux is about collaboration [...]
Unfortunately, this spirit of collaboration sometimes gets lost in
practice when feedback is asymmetric, obnoxious, or absent.
- FChE
On Thursday 02 August 2007 13:03, Frank Ch. Eigler wrote:
> Arjan van de Ven <[email protected]> writes:
> > [...]
> > It does not matter [whose] code gets merged.
> > What matters is that the problem gets solved and that the Linux
> > kernel innovates forward.
> > [...]
>
> This attitude has risks over the long term, if outsiders with fresh
> ideas are discouraged. Risking becoming known to defer too much to
> established maintainers, those fresh ideas may stop coming to linux.
Amen to that, Frank. Driving off talented contributers is a Very Bad
Thing for Linux in the long run. This will not not stop evolutionary
progress, but it slows it down and may result in an overly inbred
animal.
It is especially easy to drive off a contributor whose day job is not
Linux hacking.
Regards,
Daniel