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.
- Prev by Date: Re: [PATCH] (Re: regression tracking (Re: Linux 2.6.21))
- Next by Date: Re: [PATCH] headercheck: add dependency check and improve speed
- Previous by thread: git-current: slub breaks s2ram with fglrx...
- Next by thread: solution to "usb disconnect problems regarding usb 1.1 and 2.0"
- Index(es):
 |