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

[Matt Williams]

On 31 October 2010 12:37, Modestas Vainius <modestas at vainius.eu> wrote:
> 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.

Basically, what you're suggesting is to move as much (well, within
reason of course) of kdelibs 'upstream' into kdesupport. I think I
agree that this could be the way to go (at least for the short/medium
term).

It doesn't solve our BIC/SIC problem (unless as I asked before: does
moving the real code out into kdesupport and keeping wrapper classes
in kdelibs solve either of those?) so we'd still need to make this a
KDE5 thing. Or would we just have to make it libkdecore.so.6 bump
while keeping KDE Platform/SC at version 4? It would be breaking our
BC promise but maybe we could get away with it? :)

-- 
Matt Williams
http://milliams.com