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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
