"Cornelius's grand plan" - Merging KDElibs into Qt

[Steven Sroka]

I am very impressed by the discussion going on. KDE users should be proud of the people maintaining this project. Unfortunately, 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 discussed.

What needs to be done ASAP, is a more formal discussion which will create common goals that can be achieved within KDE before anything actually changes. Right now, nobody truly knows or understands what needs to happen. This is all at its early stages, in fact, in the early brainstorming stage, 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/strategy-sucks/. First line, 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, cleaning out fluff from the code, tighter Qt integration, stability [I hear you, KDE3 users!]),
*and what may not be needed or is already not needed (duplicate code with Qt, deprecated code, useless dependencies).

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

Figuring out how KDE will change on its own and how it will change with Qt, 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, congrats, Aaron for bringing something like this up before me:
 
> this just begs for a system where people with domain-specific knowledge and 
> hands-on experience with specific parts of the code (e.g. you and KLocale / 
> KCalenderSystem) can write up specific proposals for such changes and add them 
> to a central repository of them.
> 
> some of these things will end up requiring coordination with Qt or even other 
> projects, which wiould make such a system invaluable.
> 
> it would also give us a way to measure the effort we'd be considering getting 
> ourselves into, prioritize which parts to tackle and, should we undertake it, 
> a way to track our progress.





 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101102/a1705186/attachment.htm>