way of managing the kernel development involvement process (was: Re: [ck] It is the end of -ck)

[Martin Steigerwald <Martin@lichtvoll.de>]

I am ccing this to kernel mailing list, cause in my point of view this at 
least partly points at a failure of proper kernel management.


Am Sonntag 17 Juni 2007 schrieb Con Kolivas:

> Yes it's true, -ck is over after the next stable release. I was going
> to announce this with the actual release, but many have become aware of
> this already from other sources (like IRC). So I'll explain in more
> depth now and leave a quick announcement for the release.
>
> There are many reasons for this, but two major ones that most of you
> will have deduced by now:
>
> 1. If whatever performance advantage it has is all but abolished
> compared to mainline then there is no point maintaining alternate
> patches to achieve the same endpoint.
> 2. All interest I have in kernel development, even out of the mainline
> spotlight, has been... abolished (I had nastier words but decided not
> to use them.)
>
> It is clear that I cannot develop code for the linux kernel intended
> only to be used out of mainline and not have mainline get involved
> somewhere along the line. Whether it be the users or even other
> developers repeatedly asking "when will this be merged". This forever
> gets me into a cycle of actually trying to merge the stuff and ... well
> you all know what happens at that point (again I had nastier words but
> decided not to use them.)
>
> So, I've had enough. I'm out of here forever. I want to leave before I
> get so disgruntled that I end up using windows. I may play occasionally
> with userspace code but for me the kernel is a black hole that I don't
> want to enter the event horizon of again.
>
> I thank you all deeply for your involvement, patronage, support, bug
> reports and feedback. I also apologise because I realise what the -ck
> patchset means to a lot of people.
>
> Truly, thank you very much.

Hello Con!

Thank you very much!

ck patchset introduced to me the concept of seamless audio playback - no 
matter what - and improved my desktop experience with KDE on a IBM 
ThinkPad T23 quite considerably. I had the feeling that I have bought a 
new machine actually ;-). I really enjoyed ck quite much - like suspend2 
which still isn't in mainline either despite its technical superiority 
(in my eyes).

However I agree with you that when you feel more frustration than fun with 
developing the ck patchset it is time to stop doing it.

I think the way mainline management is done right now certainly needs some 
improvements! When it comes to collect technical feedback before 
summarizing it - as I told Linus -, but mainly on the side of 
communication. Actually I believe that aside from technical aspects the 
way of communication, the tone of it is really important, too. And I 
perceived *lack of communication* where it actually from my point of view 
was greatly needed. Maybe just a *friendly* word, a "thank you" would 
have done so much of a difference at times. 

I was trying to bring some communication in there by private mails to you 
and Ingo - but maybe this was a mistake - not Linus or Andrew. It is a 
pity that it didn't work out, but I at least hope it helped a bit.

Every communication has at least two partners. I believe that each of the 
partners was involved in this outcome. And I believe that kernel 
management can be improved by actually looking at what really went on 
here.

At least in my eyes the kernel development involvement process should not 
frustrate talented developers like you, Con, to a point where they do not 
want to contribute anymore. Also here are at least two communication 
partners involved: The developer who wants to contribute and the decision 
makers and reviewers.

Since you made your decision I understand when you do not want to look 
deeper into that. For Ingo, Linus, Andrew and everyone else involved it 
IMHO still is worth to look at what happened here and what their part of 
it was - in order to find a way to utilize the talent of talented 
developers who want to contribute instead of letting frustration raise so 
much as seen here.

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

Attachment: signature.asc
Description: This is a digitally signed message part.