From kde-core-devel Tue Nov 02 21:51:30 2010 From: Steven Sroka Date: Tue, 02 Nov 2010 21:51:30 +0000 To: kde-core-devel Subject: RE: "Cornelius's grand plan" - Merging KDElibs into Qt Message-Id: X-MARC-Message: https://marc.info/?l=kde-core-devel&m=128873472904833 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--_4ee8d1d0-a4b1-4f05-9029-852b154280c5_" --_4ee8d1d0-a4b1-4f05-9029-852b154280c5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am very impressed by the discussion going on. KDE users should be proud o= f the people maintaining this project. Unfortunately=2C I noticed fewer and= fewer people are using this mailing list for other reasons than to discuss= the possibility of a Qt and KDE merger/figuring out what KDE is/what makes= KDE useful/the hundred and one other things that do indeed need to be disc= ussed. What needs to be done ASAP=2C is a more formal discussion which will create= common goals that can be achieved within KDE before anything actually chan= ges. Right now=2C nobody truly knows or understands what needs to happen. T= his is all at its early stages=2C in fact=2C in the early brainstorming sta= ge=2C even so this is becoming serious fast. openSUSE had a similar issue (= but not the exact same) a while ago: http://news.opensuse.org/2010/09/03/st= rategy-sucks/. First line=2C second paragraph. I would love to organize something formal that could get KDE on the road to= figuring out: *what _may_ be needed (i.e. advertising KDE=2C cleaning out fluff from the = code=2C tighter Qt integration=2C stability [I hear you=2C KDE3 users!])=2C *and what may not be needed or is already not needed (duplicate code with Q= t=2C deprecated code=2C useless dependencies). Unfortunately=2C I have little expertise in this manner=2C so its a road bl= ock for me personally :( Figuring out how KDE will change on its own and how it will change with Qt= =2C needs to be made a bit more formal and solid. There are *too many* good= ideas being thrown around without being tallied and kept organized. Now don't kill me for trying to keep this massive topic in order :) By the way=2C congrats=2C Aaron for bringing something like this up before = me: =20 > this just begs for a system where people with domain-specific knowledge a= nd=20 > hands-on experience with specific parts of the code (e.g. you and KLocale= /=20 > KCalenderSystem) can write up specific proposals for such changes and add= them=20 > to a central repository of them. >=20 > some of these things will end up requiring coordination with Qt or even o= ther=20 > projects=2C which wiould make such a system invaluable. >=20 > it would also give us a way to measure the effort we'd be considering get= ting=20 > ourselves into=2C prioritize which parts to tackle and=2C should we under= take it=2C=20 > a way to track our progress. = --_4ee8d1d0-a4b1-4f05-9029-852b154280c5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am very impressed by the discussion going on. KDE users should= be proud of the people maintaining this project. Unfortunately=2C I notice= d fewer and fewer people are using this mailing list for other reasons than= to discuss the possibility of a Qt and KDE merger/figuring out what KDE is= /what makes KDE useful/the hundred and one other things that do indeed need= to be discussed.

What needs to be done ASAP=2C is a more formal dis= cussion which will create common goals that can be achieved within KDE befo= re anything actually changes. Right now=2C nobody truly knows or understand= s what needs to happen. This is all at its early stages=2C in fact=2C in th= e early brainstorming stage=2C even so this is becoming serious fast. openS= USE had a similar issue (but not the exact same) a while ago: http://news.o= pensuse.org/2010/09/03/strategy-sucks/. First line=2C second paragraph.
=
I would love to organize something formal that could get KDE on the roa= d to figuring out:

*what _may_ be needed (i.e. advertising KDE=2C cl= eaning out fluff from the code=2C tighter Qt integration=2C stability [I he= ar you=2C KDE3 users!])=2C
*and what may not be needed or is already not= needed (duplicate code with Qt=2C deprecated code=2C useless dependencies)= .

Unfortunately=2C I have little expertise in this manner=2C so its = a road block for me personally :(

Figuring out how KDE will change o= n its own and how it will change with Qt=2C needs to be made a bit more for= mal and solid. There are *too many* good ideas being thrown around without = being tallied and kept organized.

Now don't kill me for trying t= o keep this massive topic in order :)

By the way=2C cong= rats=2C Aaron for bringing something like this up before me:
=3B>=3B this just begs for a system where people with domain-specific knowl= edge and
>=3B hands-on experience with specific parts of the code (e.= g. you and KLocale /
>=3B KCalenderSystem) can write up specific prop= osals for such changes and add them
>=3B to a central repository of t= hem.
>=3B
>=3B some of these things will end up requiring coordi= nation with Qt or even other
>=3B projects=2C which wiould make such = a system invaluable.
>=3B
>=3B it would also give us a way to me= asure the effort we'd be considering getting
>=3B ourselves into=2C p= rioritize which parts to tackle and=2C should we undertake it=2C
>=3B= a way to track our progress.
= --_4ee8d1d0-a4b1-4f05-9029-852b154280c5_--