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.