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

[Stephen Kelly]

Mark Kretschmann wrote:
> What do you think about it?

Let's merge Qt and the KDE development platform. Let's put all KDE 
libraries, 
support libraries, platform modules into Qt, remove the redundancies in Qt, 
and polish it into one nice consistent set of APIs, providing both, the 
wonderful KDE integration, consistency and convenience, as well as the 
simplicity and portability of the Qt platform.



Obstacles to getting most of kdelibs wholesale into Qt (or close to it):

1) Qt is moving in the opposite direction, even proposing separate repos for 
Qt based modules developed in-house, like QtMultimedia, QtQuick etc.

http://labs.qt.nokia.com/2010/10/26/qt-is-going-modular/

2) APIs in kde platform are not all compatible with the goals and quality 
standards of Qt. Some kde stuff is there for nepomuk or akonadi features for 
example. Such things would only be put into Qt if they were compatible with 
the goals of Qt. Additionally, putting all of the functional libraries of 
KDE into Qt would significantly increase the bloat and dependencies of Qt. 
The modular Qt of the future is a lean mean framework for creating 
libraries, applications and platforms and some additional modules released 
synchronously.

3) The license and copyright assignments are incompatible with KDE library 
code. Rather than being 'merged into Qt', features would have to be 
rewritten Chinese Wall style.

4) Push access to the Qt repos is not currently available, but lets assume a 
world where is available for established contributors. Everything still 
would need pre-review, whereas in KDE we mostly do post-review. New 
contributors would have to use the Merge Request system, or some other form 
of pre-review for all patches until they are trusted enough by Nokia (not by 
the KDE community) to push themselves. This raises the barrier to entry.

5) Any code shipped in Qt by Nokia has maintenance and compatibility 
guarantees that would need to be satisfied by the KDE community, even on 
platforms many KDE developers don't know much about, like Symbian. That's 
not really a guarantee that a FreeSoftware community can make.

6) Release schedules of Qt may not suit the goals and needs of KDE 
applications and release cycles.

7) We're a bit low on concrete details about what would happen specifically 
to specific classes and libraries. Someone needs to start creating an 
annotated list.

How many of the above obstacles are solvable?

All the best,

Steve.