The "E" in "KDE" (more or less was: KDE RC Authority)

[Rob Kaper]

1996. Matthias Ettrich has a vision which I will summarize as "screw all
these incompatible, non-integrated and egocentric libraries and
applications" and more importantly "let's create a unified environment". Not
that the E in KDE indeed stands for Environment.

2002. The launch of kdeextragear (a package to release applications outside
of the release, or whatever, I still don't get it) causes some confusion and
some fiesty discussion amongst the developers. What goes into KDE and what
not? What is part of KDE and what not? Who decides all that?

To answer the last question: I believe community concensus is indeed the
proper way and not the release coordinator's consent. I hope we can all
agree on that and dismiss some of the things said in the previous thread as
miscommunications and misunderstandings. Neil might have been too pedantic
with his repsonses to Dirk and I get the feeling the discussion eventually
focussed on what was said, and not why people said it.

To answer the first two questions, well, that has been made a lot trickier
with kdeextragear. Apparently it is part of KDE, because it will be released
as a package by us. But apparently not, because it will be released seperate
from the rest of KDE.

I urge all of us to seriously think about the implications of not having a
clear determination of the contents of KDE releases. If we can not agree on
this, we're fscked. Different packagers will include different applications
and they will all call it KDE x.y.z. Some might even make intermediate
releases with application updates and create "KDE" version numbers never
present in *our* development and release cycle.

This would make the only part of KDE where we have control over releasing it
the way we want it kdelibs and I fear that this might lead to a situation
where the project as we now know it will focus on developing the API, the
framework, the core.

kdeextragear sounds like a step towards that scenario. It does not resolve
"what applications are part of KDE", it rather dodges the question
alltogether by leaving the decision up to the packagers. Right now this is
about CD burners, but it might soon affect network (kit vs. Kopete for
example) and as KDE continues to grow in size we will only get more and more
application maintainers who would like to be part of the official release.

Well, if you just moved your nifty code to kdeextragear for that purpose:
wake up. You are not part of the KDE release.

My fears might be unjustified. Maybe the majority of developers do
understand how crucial it is for our project to have clear boundaries when
it comes to what we release and what not.

After all, the E in KDE stands for environment. KDE is not just a framework,
a set of libraries, a development platform or an API. KDE is a desktop
environment.

One that should ship with the best CD burning application and only the best.
In case no concensus can be reach on which one that is, we should not ship
any of them or keep the one that was there before competition appeared.

If the developers of similar applications cannot cooperate and work on a
single application that is ocmpletely integrated into out environment, they
should not be part of the KDE release.

Again, my fears of KDE degrading into an API instead of an environment might
not be justified. If you agree with me that

- we should continue building an environment and not just a framework,
- we should not have duplicate applications and
- we should get rid of kdeextragear as soon as possible because it will hurt
  the environment,

then please stand up.

If you don't think this is important, also please stand up. If the majority
feels like the current situation is not a serious problem, that is fine by
me. I am convinced that those who do remember Matthias' vision will create a
very succesful fork to release a desktop environment instead of a framework
which might or might not include certain applications.

To underline how serious this issue is to me: if anyone feels Atlantik is
not suitable for the KDE environment because it uses it's own framework (for
monopd compatibility) instead of KGame, I will pull it from kdegames
immediately and make third-party releases only. The quality of the KDE
environment is more important to me than the ego-boost of having my
application on all those shiny CDs carrying KDE.

Thanks for reading. Thanks in advance for responding objectively.

Rob
-- 
Rob Kaper     | Gimme some love, gimme some skin,
cap at capsi.com | if we ain't got that then we ain't got much
www.capsi.com | and we ain't got nothing, nothing! -- "Nothing" by A