On 31 October 2010 12:37, Modestas Vainius <modes...@vainius.eu> wrote: > Hello, > > On sekmadienis 31 Spalis 2010 14:04:28 Matt Williams wrote: >> On 31 October 2010 11:53, John Tapsell <johnf...@gmail.com> wrote: >> > On 31 October 2010 11:33, Mark Kretschmann <kretschm...@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