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

[Piotr Szymanski]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob Kaper (5/07/2002 14:38):
> To answer the last question: I believe community concensus is indeed the
> proper way and not the release coordinator's consent. 
I think that if one person is responsible for something then it should have 
the means to direct/control that thing. I cant imagine that if I were a 
release coordinator Neil would tell me what I should add to the release and 
what not, but I should have the right to decide what should be in it myself, 
because I wil be the one who'll get all teh criticism if something goes 
wrong. 

> 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.
Good point, but what is required is not that we forget about it, but that we 
learn from it, in other words there should be less selfishness, bitching and 
arrogance in threads...

> 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.
And it will happen unles KDE has a future development strategy. At the moment 
we dont.

> 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.
The idea of kdeextremegear is for projects that are release quality to be 
developed in the cvs and not in kdenonbeta (which is here for a different 
purpose). Ex. there were 3 cd-recorders in kde, which is sick, because this 
is a total doubling of effort.

> 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.
Those clear boundaries were discussed over and over again and no consensus was 
reached, we need an efficient deecision making system first.

> 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.
Agreed.

> 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.
I think that the policy should be:
If we have several programs that do the same in kde, their developers should 
discuss merging their code and making a new app, we move them to 
kdeextremegear and they will stay there until they are merged into one 
project and until that project is worth moving back. If they can not agree 
than they will not get into KDE simple. KDE is not a dumpster for all apps.

> 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.
Agreed.

> - we should continue building an environment and not just a framework,
Agreed, but we need to work out a more detailed policy

> - we should not have duplicate applications and
Agreed

> - we should get rid of kdeextragear as soon as possible because it will
> hurt the environment,
Not agreed, kdeextremegear is a place whwre devs can work on apps that were in 
kde but failed tocompply to the new policy, if they cant workc anything out 
than we kick them out.

> then please stand up.
I do not know whether to stand up or not, I do not agree with 

> 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.
I do not know that vision, but I agree that we need to choose apps that to the 
release with extreame caution.

> 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.
It is not that a kde app can only use qt and kde and nothing else. The apps 
that should be release must be:
- - stable and usable
- - not doubling code
- - needed by the users (here is where QA comes in)

I already made a proposal of a system we could use to make decisission in KDE, 
it is jsut a draft, but if we work on it it might be effective.
- -- 
!: Piotr Szymanski | LinuxPL Developer  | KDE i18n-pl coordinator
@: djurban at linuxpl.org | Homepage: should be ready by August
&: LinuxPL.org: layout (done);php engine(due to September)
#: GG: 2300264 | ICQ: 12622400 
%: "Give evil nothing to oppose, and it will destroy itself." -Tsunami Shijo 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9JZ/HFie3dglPmVIRAjmxAKCYpRpCzIRwa5D+bM1KHglsS0a3GQCglHmj
flurS5gCXxfeIQ2ySqMhdY0=
=Ygnn
-----END PGP SIGNATURE-----