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

[Modestas Vainius]

Hello,

On sekmadienis 31 Spalis 2010 14:04:28 Matt Williams wrote:
> On 31 October 2010 11:53, John Tapsell <johnflux at gmail.com> wrote:
> > On 31 October 2010 11:33, Mark Kretschmann <kretschmann at kde.org> wrote:
> >> Hey all,
> >> 
> >> after reading the whole thread that started with Chani's mail ("why
> >> kdelibs?"), I think the noise level has become a bit too much there.
> >> Cornelius had proposed this rather daring idea:
> >> 
> >> http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2
> > 
> > Sounds great.  This should probably be done by picking a specific
> > technology in KDE, and adapting it and merging it to work in Qt.
> > 
> > A wonderful place to start would be kioslaves imho.  This is something
> > which has a real advantage, is relatively self-contained, and would
> > provide a big advantage.  Possibly it needs to be merged more with the
> > Qt API though.
> 
> So, if we decided that we wanted to merge KIO slaves into Qt, what
> would the steps we go through be? If we're going to be doing this with
> a number of classes we need to have a process which ensures that the
> code is Qute enough, KDE still compiles against it (with minimal/no
> code changes) etc.

With my packager hat on:

But what happens when you (KDE) decide that you really need a new feature of 
kioslaves for the next release. But the next Qt release is not due in 7 months 
or you (again) have trouble merging changes back to Qt with patience running 
out? Sure, developers compiling from source can patch Qt, install differently 
configured builds to different prefixes with/without specific features etc.  
But what are poor packagers supposed to do? Phonon situation all over again? 
It was *really* bad and my mind is still recovering from that experience. I 
really doubt I'm ever going to trust such merges to Qt again.

In my opinion, KDE should keep libraries small, *modular* and develop them in-
house. Try not to attach binaries and esp. daemons to the libraries. Maybe 
strip KDE branding from library names to gain wider acceptance. Only this way 
you as a project will be in control of release schedules and feature sets.

Nokia might be nice, but it has different goals and problems (mobile OS war), 
their priorities are shifting, they are controlled by the market they are in. 
IMHO, KDE project cannot afford to depend on the good will of the third party 
too much. It will just slow innovation down in KDE or become yet another 
opportunity to fork KDE-grown library which has (almost) been forgotten in 
Qt...

-- 
Modestas Vainius <modestas at vainius.eu>
-------------- 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/20101031/0225b967/attachment.sig>