PIM Sprint: Porting PIM to Frameworks

[John Layt]

Hi,

At the PIM Sprint a major topic discussed was the plans for migrating
to Qt5 / KF5, in particular how and when to convert from "kdepimlibs"
to "PIM Frameworks".  I've started a wiki page to document the process
required and to co-ordinate the tasks at
http://community.kde.org/Frameworks/Epics/kdepimlibs.

To start with, there's already been two major steps taken:
* Akonadi supports Qt5 since v1.11
* All of KDEPIM has already been ported to the CMake automoc

Dan and Volker discussed a number of changes to Akonadi, how it is
organised, and the removal of unsupported and deprecated code, which
I'll leave to them to document.

It was agreed that the ideal plan for kdepimlibs was to split all the
libraries up and make them all stand-alone Frameworks, aiming for Tier
2 or even Tier 1 where possible.  We will drop all the old KResource
related code, KCal, and anything still using Qt3Support.  We will have
a more relaxed approach than the kdelibs Frameworks and allow more
breaking of source compatibility like removing deprecated api and
renames.  We will also consider splitting existing libraries into
smaller libraries if they will be more useful, especially focusing on
the split between KDE integration, and the underlying libraries and
utilities that could be used by other PIM apps.

We are fortunate that kdepimlibs is already mostly structured as
standalone libraries, so the build system splitting shouldn't be too
hard.  Most of the hard work will be source incompatibility related
around KDateTime, KTimeZone, KLocale, and using Qt's tr() instead of
KDE's i18n() for lower tier frameworks.

The kdepim-runtime will need to be reviewed in the same way as
kde-runtime with the aim of moving everything either into the
Framework or into kdepim proper, with kdepim-runtime then being
removed.

The time frame is still uncertain, we're reluctant to divert developer
effort from bug fixing in the 4 branch as that is what most users will
care about for the next 2-3 years, but are aware that some of the
libraries are dependencies for Plasma 2 and are needed sooner rather
than later.

The rough plan agreed is:

* Wait for the KF5 split to be completed and the preview released,
then fork a kdepimlibs frameworks branch
* Delete all known obsolete code
* Blindly port the remaining code to Qt5 / KF5 / kde4support with no
api or code clean-ups
* Make any internal splits, code moves, and library renaming required
* Split kdepimlibs
* Do api and code clean-ups, port away from kde4support, etc
* Individual PIM Frameworks will be released as and when they are ready

This means the initial branch should happen in 2-3 months, during
which time we can plan what we want to obsolete, any other splitting
we need to do, and the priority order for the libraries.

One step needed before forking is to review the existing frameworks
branch in kdepimlibs to see if there is actually anything useful
there, if not it needs to be deleted first.

We would like to ask the Frameworks community to assist us by taking
the lead on the "blind port to Qt5 / KF5" step as they have the
experience to quickly achieve this, i.e. changing includes, using
tr(), etc.

The initial port to KF5 may use kde4support for simplicity, but the
released Frameworks must not use kde4support at all.  This allows the
initial port to be a 'blind' port by non-pim people, but the other
steps will require considerable effort from the maintainers.

By releasing each library as it is ready we help speed up availability
for others to use them, especially for Plasma 2, but we do run the
risk of releasing libraries before they have had any serious usage in
our KDEPIM apps.  This will be judged on a case-by-case basis
depending on how much has been changed, and libraries only used by
KDEPIM could be held back.

Following this plan we would hope to have all the PIM Frameworks
released within a year, or ready to be used in porting kdepim.

EVERYONE needs to help with the following steps over the next few days:

* Review the wiki page to ensure the information there is correct
* Split out any other "Code Units" not currently documented
* Fill in the Description field so non-PIM people can understand what
a Unit does
* Fill in all the Maintainer name fields so we have a name against every Unit
* If there is no active Maintainer and you know enough to make
decisions, you're Maintainer for this purpose

MAINTAINERS need to perform the following steps before the frameworks
branch is forked:

* Decide what Code Units are to be deleted
* Document the dependencies required for the Unit
* Determine any usage of the Unit outside of kdepim
* Decide what priority the Unit is
* Decide on any internal splits of the Unit moving of code into other Units
* Take a guess at the Frameworks Tier to aim for
* Email the list with the details of decisions made for review

If during this review you see any changes or clean-ups you can make
before the frameworks fork then please do so, e.g. clean-up un-needed
includes, remove dead code, etc.

One consequence of moving into Frameworks will be the need to meet the
Frameworks coding style.  Any changes to coding style will need to be
completed before the frameworks branch is made, or wait until after
the kdepimlibs split is made.  This is to keep any merges of bug fixes
from master as simple as possible.

We may need a PIM Frameworks Sprint early in the new year with 4-5 key
people to work through every class in kdepimlibs to decide on its
eventual destination.

A few major decisions were left for later:

* When to put kdepimlibs into feature freeze
* How long we plan to provide LTS for kdepimlibs
* What timeframe to put on kdepim apps migrating to Frameworks 5
* If/how to split kdepim into separate repos
* What apps to include in kdepim 5

The one app decision made was to drop KNode due to using Qt3Support.

Cheers!

John.