Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 you would have had 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
> > 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 you would have had ". 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 you would have had ". 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ck] Re: Linus 2.6.23-rc1 -- It does not matter who's code gets merged!
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
