[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Plan to transition to KDE Frameworks
From:       David Faure <faure () kde ! org>
Date:       2011-06-06 23:43:44
Message-ID: 201106070143.44615.faure () kde ! org
[Download RAW message or body]

Hi everyone,

It's getting rather late here, so I'll skip introductions and get right to the point \
:-)

Until 4.7 is branched, we keep fixing bugs in kdelibs 4, and work on trying to 
get the things into Qt 5 that we need -- about 20 KDE-related people will be
going to the Qt Contributor Summit, that should help.

Once the 4.7 branch is created, the plan is to do the following:

- application developers can work in master as usual, no change there.

- we create a new branch in kdelibs (say, "frameworks") for the work on splitting up \
kdelibs and reworking dependencies.  Initially, this work is based on Qt 4. We don't \
need Qt 5 to reorganize our own code.

- kdelibs in master is frozen. No work going on there.
   At most, "merging" the fixes from 4.7 branch.
   (No git bikeshedding please, when I say merging it can be either merge or \
cherry-pick, I don't care)  The idea here is: people who are used to "get everything \
from master" can keep doing that, without hitting the lib-splitting breakage.  But at \
the same time, we don't really want to apply bugfixes to three branches (4.7, master, \
frameworks).  At least I'm too lazy for that, I think two branches is plenty already. \
:-)  Dividing our efforts is never a good idea. So the kdelibs-master branch would be \
basically dead  (no work going on there, no release from that code), until the \
frameworks branch is merged into it.  
  To ease testing, kde-runtime will probably be branched at the same time, in order \
to have matching  libs and runtime bits (and possibly to move together stuff that \
belongs together).

  Once the code is fully reorganized, we will move each library into a separate git \
repository.  (technical git note: Olivier Goffart showed us a very cool trick with \
git graft which allows one to chain  the history of a git module to another one, \
thereby preserving history when moving code between git modules).  We are working on \
solutions to make it easier to manage split-up git repositories more easily, there is \
Alex Neundorf's current work on a cmake-based solution, and kdesrc-build's module-set \
feature.

- at some point we switch to Qt 5, in order to test it and to be able to use the \
features that we might need  from Qt. On that note: if you look at the dependencies \
plan PDF, most Qt Addons in Tier 1 are something  that "should ideally be in Qt", or \
at least something that any Qt developer might want to use.  So if we do get things \
into Qt, this diagram can change a bit with things moving down (which is good).  The \
point is that the diagram currently assumes the worst, i.e. that we can't get \
anything into Qt; we'll see  how that goes.

- at that point, we create a frameworks branch for kdesupport modules in order to \
port them to Qt 5.

- later on, we create a frameworks branch in kdepimlibs in order to split it and port \
it to Qt 5.

This plan is only about KDE Frameworks. For the KDE Applications and Workspaces, \
nothing is decided yet, that is still to be discussed, for instance at Desktop \
Summit. There is no rush in doing that. This migration will be different from the \
previous migrations because the goal is to preserve source compatibility as much as \
possible. So there is no need to adapt the rest of the code while we make changes in \
the KDE Frameworks. This is why the rest of the code can be branched much later.

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).


[prev in list] [next in list] [prev in thread] [next in thread]