From: Martin Steigerwald <Martin@lichtvoll.de>
To: ck@vds.kolivas.org,
       linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: way of managing the kernel development involvement process (was: Re: [ck] It is the end of -ck)
Date: Sun, 17 Jun 2007 12:38:52 +0200
User-Agent: KMail/1.9.7
Cc: Con Kolivas <kernel@kolivas.org>
References: <117f368d0706160821t6376fde7ha4df0117d3657ac6@mail.gmail.com> <46742CC0.5010302@debianpt.org> <200706170955.02165.kernel@kolivas.org> (sfid-20070617_100413_486841_FFF0B9BE)
In-Reply-To: <200706170955.02165.kernel@kolivas.org>
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart1651900.dTk24FHFKs";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200706171238.57605.Martin@lichtvoll.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 5013
Lines: 117

--nextPart1651900.dTk24FHFKs
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


I am ccing this to kernel mailing list, cause in my point of view this at=20
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=20
matter what - and improved my desktop experience with KDE on a IBM=20
ThinkPad T23 quite considerably. I had the feeling that I have bought a=20
new machine actually ;-). I really enjoyed ck quite much - like suspend2=20
which still isn't in mainline either despite its technical superiority=20
(in my eyes).

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

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

I was trying to bring some communication in there by private mails to you=20
and Ingo - but maybe this was a mistake - not Linus or Andrew. It is a=20
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=20
partners was involved in this outcome. And I believe that kernel=20
management can be improved by actually looking at what really went on=20
here.

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

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

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

--nextPart1651900.dTk24FHFKs
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBGdQ9BmRvqrKWZhMcRAqvzAJ46Ak/wtVpFKAH+41onwLnN3ogkCQCgiRWN
BJAZBoIqWMNBdqejBLKx3Lw=
=kVQs
-----END PGP SIGNATURE-----

--nextPart1651900.dTk24FHFKs--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/