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

[Hetz Ben Hamo]

If I may say something please..

I think it will be a good idea to make a vote among KDE DEVELOPERS only!

How? pretty simple:

We'll have A web page that developers with CVS accounts (user/pass) can access 
it and vote what should be included, and whats not. After X days someone can 
publish the results and decides whether to:

* include it in the main KDE tree (not including kdenonbeta and 
kde-extra-gear)
* move it into kde-extra-gear
* leave it on kdenonbeta (although I think kdenonbeta needs some serious 
cleanup - there are lots of stuff that aren't even compilable!)
* reject from KDE entirely (license problems, not fitting into the KDE goals, 
etc...)

Comments?

Thanks,
Hetz

On Friday 05 July 2002 15:38, Rob Kaper wrote:
> 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