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

[Aaron J. Seigo]

On Sunday, October 31, 2010, Mark Kretschmann wrote:
> What do you think about it?

i think it isn't a plan as much as it as an open ended question that we really 
don't have the ability to answer very well right now.


unfortunately, it was also positioned on some rather dubious claims such as: 
"Over the last couple of years, KDE development has constantly shifted from 
library development to application development. Our struggles with even just 
doing the basic maintenance of the libraries show that. [...]There are still 
brave souls taking care of kdelibs, but it's really hard to keep up there."

this is a line we've been telling ourslves for at least 6 years now. compare 
kdelibs now to then and the facts don't particularly align with the scary 
scenario outlined above. more importantly, if we look at Qt we can find all 
kinds of poorly or outright unmaintained stuff that causes issues because it 
is so. which means that merging with Qt willl not, in the least, resolve this 
kind of issue for us.

we should not delude ourselves there, because if we decide to pursue such a 
course of action we need to not do so with the expectation that our need to 
work on libraries will suddenly evaporate or significantly lessen in some way.


as for MeeGo as the aims there, i don't think there is nearly the overlap 
between MeeGo's goals and the goals of kdelibs that Cornelius seems to 
perceive. MeeGo is very specific and very pragmatic about caring about one 
specific platform. i've seen the result of that first hand, and it isn't 
something i see as being particularly healthy for generic libraries that come 
under its umbrella since product release schedules and "it needs to work for 
our consumer electronic product" trumps all.


but looking at the idea squarley, the first question i think of is: What does 
"merge with Qt" mean, exactly? dicing up our libraries a bit differently, 
hoping to get them shipped with Qt? changing the release cycle to match that 
of Qt's? moving kdelibs code development to gitorious alongside Qt? merging 
code into existing Qt libraries, and if so which kde code and which Qt 
libraries? are we doing this primarily for technical gain, primarily for 
marketing gain, or for some mix of both (and to what extent)? these questions 
matter because:

imho Qt open governance is mature enough yet to realistically support free 
handed 3rd party involvement in development. when we (KDE) would need 
something, it would result in a lot of asking Qt Dev Frameworks for permission 
and convincing of others. right now, that's unlikely ime, and when things are 
improved (and i do think they will) it will be less efficient than what we 
have now due to the increased number of entities involved.

if it is about reaching the broader audience of the Qt develper world, it's a 
bit more than "shove it all into Qt". we need to understand what would make 
such libraries attractive. in the 2 threads on this already we've seen some 
are hesitant about the large dependency chains, including how that looks on 
non-Linux/UNIX platforms. mergin with Qt doesn't solve that set of issues in 
the least, and simply thinking that merging with Qt means the dependencies go 
away or that we can get rid of those dependencies without impact on our 
applications (the whole point of our libraries) is probably a bit simplistic.

so what exactly do people mean when talking about "merging with Qt"? not broad 
brush strokes, but specific detailed goals.


on the kdelibs side, we have several kinds of functionality. i think Michael 
Jansen did a very good job of outlining the differences in his first email in 
this thread.

not everything in kdelibs will be of interest in the scope of Qt, though much 
of it will continue to be of interest to our applications.

if anyone is really truly serious about taking on such a "merging with Qt" 
project, the first thing that problably needs to be done after identifying 
specific detailed goals is a class-by-class census of what is in kdelibs right 
now. break them out by what kind of functionality they provide and what they 
are appropriate for. start to draw out what the resulting library set would 
look like from an application developer's POV.

some of this work has already been done, e.g. with solid. it might make sense 
to identify which parts are ready _right now_ and start working those "into 
Qt" in a way that is an improvement over the methods used for Phonon or 
printing. it would help build paths and slim the profile of kdelibs while 
openning the door to our libraries to more developers ... without a huge 
"merge kdelibs with Qt" concept at the outset.


in summary, i think the picture of being involved with Qt at this point in 
time was painted a bit more optimistically than the reality of it and the 
details of what it would mean for kdelibs has not been filled in at all.

i don't think it is reasonable to ask anyone to have an opinion on the idea of 
merging kdelibs with Qt until both the state of Qt and kdelibs as relevant to 
that goal have been detailed.

it could work out great, it could be a disaster, it could be a lot of work for 
a little gain ... we just can't tell right now because it's nothing more than 
a vague idea.

you really can't plan the future of core assets like that.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20101101/62a67703/attachment.sig>