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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
