Hi Martin,
On Sun, 29 Jul 2007, Martin Steigerwald wrote: > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: > > > Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: > > > > > I > > > > > actually also think that the communication between Ingo and Con > > > > > could have been better especially when Ingo decided to write CFS > > > > > while Con was still working hard on SD. > > > > > > > > You realize that Ingo posted his code for anyone to look at/comment > > > > at about 48 hours after he started to work on CFS? > > > > > > Yes. > > > > So whats wrong then? > > Ingo decides to do a better scheduler - to some extent inspired by > > Con's work. And after 48 hours he publish first version that _anyone_ > > can see and comment on. Whats wrong with that? > > > > Did you expect some lengthy discussion before the coding phase started > > or what? > > > > Just trying to understand what you are arguing about. > > If I tried to rewrite a kernel subsystem - should I ever happen to dig > that deep into kernel matters - while I actually know that someone > already spent countless hours on exactly rewriting the exact same > subsystem, I think I would have told that other developer about it as > soon as I started coding on it. And if it just was a > > "Hi Con, > > I reconsidered the scheduling ideas again you brought to the Linux kernel > world. Instead of using your scheduler tough I like to try to write a new > one with fairness in mind, cause I think this, this and this can be > improved upon. > > I would like to hear your ideas about that as soon as possible and would > like you to contribute your ideas and also code, where you see hit. You > can find the git / bazaar / whatever repository where I do my > developments at: someurl. > > Regards, Ingo" Sending out the code (and early enough, 48 hours /is/ early enough) *is* the normal (and good) way to do exactly the communication you described above, IMHO. > I believe that Ingo did not meant any bad at all. I think its just the way > he works, he likes to have code before saying anything. But still I > believe before I'd go about replacing someone else code completely I > would inform that developer beforehand, even if it then turns out not to > be feasible at all. No need to anounce it to the world already, but I > would have informed that developer. IMHO, what you're suggesting is: (1) not the way development normally happens in Linux, and, (2) not the way it /should/ happen, either. If there's something (subsystem, any code big or small) I think I can do better or have an idea for, I /should/ be able to just hack on it a bit and then send it out so everybody can comment on it. Why should I be forced to dance/discuss around with some other people, when the faster and more effective way would be just present the code/patch that I have in my mind as an RFC? See, Martin, in the end it's not about developer A vs developer B. It's about making the kernel the best out there -- that's what the users want, anyway. Yes, I fully understand (and have said so earlier myself) that there's a very important "social" aspect to development on such projects, but it's best if developer B understands that this is the way things do (and should) happen and adapt to it. [ It's not like I've been around for long, however, but the above is still my opinion, fwiw. ] Satyam - 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/
