[Kde-pim] PIM Sprint: Porting PIM to Frameworks

[Stephen Kelly]

John Layt wrote:

> 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.

Those TODO tasks are very 'vertical'. Many tasks, and most useful tasks in 
frameworks porting, are horizontal. The horizontal tasks should largely be 
done before the vertical ones. Horizontal tasks are things like:

 * Port existing code to modern APIs (eg port KBlog to KCalCore)
 * Remove use of to-be-deleted code (eg KCal)
 * Remove obsolete code (eg KCal)
 * Make it build
 ** Use compatibility layers (KDE4Support)
 ** Update the C++ code for changes in Qt, KDE and upstreams
 * Remove use of compatibility layers
 ** Remove buildsystem use of KDE4Support
 ** Remove C++ use of KDE4Support
 ** Both of the above can be parallelized
 * Make it cool
 ** API updates
 ** Refactoring

That's the real todo list that should come before everything else you wrote 
in the wiki page. Note also that that todo list applies identically to *all* 
kde modules we're going to port. It also applied to the work already done in 
kdelibs.git.

The point I want to stress is that you should focus on horizontal tasks when 
porting, not on vertical ones.

> 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

Other steps already taken:

 * Include-what-you-use - Add includes which are 'missing' on porting.
 * Ensure that new conventions from KF5 such as C++11 language and library 
use don't conflict with existing code (see 
f237ca726d8ba66d377afaf0e3b5dce6b2d4e224 in kdepimlibs)
 * Use Q_SLOTS and Q_SIGNALS.
 * Replace kde4_add_library with add_library CMake command.
 * Ensure that KF5::KDE4Support provides maximum SC.
 ** This is what I've been doing lately. See gitk --author=steveire in kf5

Note:
 * All of these are 'clean up tasks'
 * All of these should happen in master
 * These are already happening. See gitk --author=steveire in kdepimlibs
 * The above (partial) todo list is the same as should happen in all KDE 
modules we want to port. It should happen in the master branch. That makes 
the 'porting branch' small, readable, reviewable, and something others can 
learn from and replicate.
 * We can use kdepim{,libs} porting as a validation of the SC goals of KF5 
and KDE4Support. The time-to-release goal trumped that so far for plasma and 
related. It's important for all others though, so we should ensure that a 
'clean' (see above) KDE module is easy to port.
 
> 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.

Tiers above 1 are not especially relevant. A tier is a fluid label. It 
doesn't matter when we are using split repos. 

> We will drop all the old KResource
> related code, KCal, and anything still using Qt3Support.  

Already done in my frameworks branch:

 http://quickgit.kde.org/?p=clones%2Fkdepimlibs%2Fskelly%2Fetmwork.git&a=shortlog&h=f97c0b8eff8cc3ab9f7b60146465271c021b7f6e

> We will have
> a more relaxed approach than the kdelibs Frameworks and allow more
> breaking of source compatibility like removing deprecated api and
> renames.  

Good. That's something I'd certainly like to see more of in KF5 too. Time is 
the main reason that's not done there I think, because all resource and 
attention has been on 'splitting'. Much of kdelibs was written/designed in 
Qt 3 times and should be reviewed for modernness, appropriate use of more 
recent Qt APIs, resolving warnings (building KF5 shows *lots*) etc. 

With some small exceptions, and some large ones (eg threadweaver, plasma), 
we haven't seen much of that. It should be part of 'done criteria', but the 
main 'done criteria' so far has been 'split'.

I think KF5 contributors aren't aware or don't agree it should be done? 

> 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.

Yes, I think libakonadi is a primary candidate here.

> 
> We are fortunate that kdepimlibs is already mostly structured as
> standalone libraries,

Yes.

> 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.

This shouldn't be a goal in places where it is hard. If it is trivial and 
worth it (eg drops 'home dependencies' from 1 to 0), then it can be done but 
otherwise should not be.

> 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, 

Clean-ups in kdepim* and other modifications to KF5 to make kdepimlibs 
porting a breeze have been a bigger priority for me for quite some time 
(hence not much noise from me about features or ETM lately (Thanks 
Christian!)). 

Most of the work of frameworks porting should not be done on a 'frameworks' 
branch, so it can be quite invisible.

> * Wait for the KF5 split to be completed and the preview released,
> then fork a kdepimlibs frameworks branch

Waiting doesn't add any value. By not waiting we can make KF5 SC better, do 
necessary cleanups, and make the 'actual port frameworks branch' small, as 
I've been doing.

> * Delete all known obsolete code

Done? See my branch and let me know if there's other big bites for the bit 
bucket in the sky.

> * Blindly port the remaining code to Qt5 / KF5 / kde4support with no
> api or code clean-ups

Largely done in my branch. I'll wait for dfaure to solve the K4AboutData SC 
problem and then see what else is needed.

> * Make any internal splits, code moves, and library renaming required
> * Split kdepimlibs
> * Do api and code clean-ups, port away from kde4support, etc

This should happen before the two above it. It is 'largely horizontal'.

> * Individual PIM Frameworks will be released as and when they are ready
> 
> This means the initial branch should happen in 2-3 months, 

There is an existing frameworks branch which I've been working on for 1.5 
years. I've rebased and force-pushed it to kdepimlibs.git before, to include 
cleanups from master, remove buildsystem hacks which used to be needed for 
KF5 but are now not etc. 

Once the K4AboutData issue is solved I can force push it again. As 
KDE4Support (in terms of both buildsystem and C++ code) is in good shape and 
won't deteriorate, there won't be further need for force-pushes and 
everything will be quite clean.

> 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.

Yes. This can be done independent of the existence of any frameworks branch.

> 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.

See above. It's useful but out-of-date. The up to date (minus the afore 
mentioned K4AboutData issue) branch is in my clone I linked above, and which 
I'll force-push to kdepimlibs.git soon.

> 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.

Done? I note again, that 'fixing includes' is largely something that should 
be committed in master, even if finding the missing parts requires building 
the frameworks branch.


> The initial port to KF5 may use kde4support for simplicity, but the
> released Frameworks must not use kde4support at all. 

Yes. Porting away from KDE4Support is item No 1 on any frameworks porting 
TODO list.
 
> * Review the wiki page to ensure the information there is correct

You may want to revise it with the list of horizontal tasks and other 
information from this mail.

> 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

Why is this a prerequisite to a frameworks branch?

> * 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

Also not relevant, and not a prerequisite to a frameworks branch. 


> 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.

Note that even *after* the frameworks branch is re-created and in use, such 
cleanups belong in master.

> 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.

I recommend:

 * clean up master
 * make frameworks build
 * do frameworks todo tasks
 ** split, move code around, API update etc.
 ** Close master for significant updates at some point.
 * As one of the last commits in kdepimlibs.git, run astyle
 ** It might be an idea to do this in kdelibs.git too.
 * Close kdepimlibs.git frameworks branch. 
 ** It remains for archeology with additional help from git grafts.
 *** The astyle change being 'at the top' means that it won't get in the 
way.
 * Split into multiple repos.

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

I'm sure I'll end up porting this to Akonadi/KF5(/Grantlee :)?). It's a very 
important application for me.

Thanks,

Steve.


_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/