"Cornelius's grand plan" - Merging KDElibs into Qt
Aaron J. Seigo
aseigo at kde.org
Mon Nov 1 07:45:00 GMT 2010
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
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
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...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel