Re: [ck] Re: Linus 2.6.23-rc1

[Martin Steigerwald <Martin@lichtvoll.de>]

Am Sonntag 29 Juli 2007 schrieb Satyam Sharma:
> Hi Martin,

Hi Satyam,

> > 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?

Hmmm, that email would have taken how long? 5 minutes maybe?

I just feel that I would have written it if I happen to know that another 
developer spent lots of time and effort into a subsystem I plan to 
rewrite. Its just human logic to me. Especially when I happen to know 
that the other developer may be new to the kernel development process as 
I know it from a internal view point.

The current kernel development process tries to pretend that there is no 
human involvement. Which is plain inaccurate: It is *all* human 
involvement, without a human not a single bit of kernel code would 
change.

I always believed that kernel developers are human beings and no robots. 
And thus the kernel development process IMHO should be designed with 
human developers in mind instead of robots which take no offence out of 
anything. Otherwise things like what happened here will happen again and 
again and again and talent is lost.

It is damn good to take technical merits into full account! But ignoring 
human aspects of development actually will hinder this. Cause then in the 
end its not about technical merits anymore that do the decision, but that 
human aspects that have been ignored and are floating around 
unconsiously.

Actually I do believe that this discussion already took more resources 
than actually writing a few more mails and doing a bit more communication 
here and there... IMHO the fact that this discussion exists already shows 
that something in the process of submitting kernel patches and supporting 
involvement in kernel development can be improved upon.

> 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.
> ]

I am not saying that developer B (Con) does not have his share in how it 
all happened. As written before I got the impression that Con reacted 
hurt where from my point of view no offence was meant - and I told him 
that. But from what I know it would have been possible to actually deal 
with that quite a bit better than has happened. And it would not have 
taken much effort. Well actually I think it would have been quite easy to 
take the talent that has offered itself.

Regards,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7