RFC: plan for starting the Qt5/KF5 port

[Friedrich W. H. Kossebau]

Hi,

rough plan was to start porting after the 2.9 release. Whose dates are:

Tagging February 24nd (moved from 22nd)
Release February 26th

To get some patches in that do not fit for the 2.9 branch and otherwise would 
bitrot due to the Qt5/KF5 port, there will be a merge window for master. 
Everyone having some WIP stuff that is good enough for merging, brush it up 
now and get it in!

"Merge window for master" until: Wed March 4th (proposed)
"Porting start": same day of merge window close

Porting branch named "frameworks" usually, some stuff expects it even.

Initial porting steps (done by 1 person):
-----------------------------------------
1. Merge "calligra/2.9" another time into "master"
2. Branch off "frameworks" from "master"
3. Apply https://git.reviewboard.kde.org/r/121541/
4. Remove these subdirs:
   3rdparty/kdchart/
   3rdparty/kdchartpatches/
   3rdparty/kdgantt/
   3rdparty/kdganttpatches/
   libs/koproperty/
   libs/koreport/
   (anything else moved outside?)
5. Port just the buildsystem to Qt5/KF5/ECM as much as needed to get "cmake" 
configure pass and "make" && "make install" also pass with success, without 
porting any code (should be all disabled still by step 3).
6. Create commit and push "frameworks" branch to central Calligra repo
7. Request a build on KDE CI for the "frameworks" branch
8. Take disabled product from end of product dep tree* and make it build:
   1. remove "UNPORTED" tag
   2. port it as much as needed to make it build
   3. commit to "frameworks" branch
9. if LIB_CALLIGRA has been added to the build, tell everyone to join
   goto 8. until there is no more "UNPORTED" tag

*The dep tree of products can be either seen from content of 
CalligraProducts.cmake or in a picture by using the generated 
"product_deps.dot" in the toplevel dir:
dot -Tsvg product_deps.dot > product_deps.svg
or
dot -Tpng product_deps.dot > product_deps.png

Porting Rules (proposed):
-------------------------
* do not port away from kdelibs4support initally, but see to get it added to 
the build as quickly as possible (only then go perhaps further)
* ensure CI always manages to build (to ease life of co-porters)
* love to the tests
* anything that needs temporarily to be disabled by commenting out should get
  a tag "QT5TODO" (anything better?), so it will not be forgotton before 3.0


Reasoning:
----------
Calligra has over 4 M lines (claims openhub.net, not counted myself), so 
expecting one person to do all the initial porting would be quite some burden 
to that. Also is noone expert in all code.
The proposed UNPORTED tag system (see step 3. above) and the initial porting 
product-by-product as much as needed to get it build at least should help to 
parallelize the work quickly, so everyone can give special love to the code 
they care for.
Sadly krita is not "product"ed, so there it will be more a matter of control 
by commenting in CMakeLists.txt. Surely also doable :)

To not have people step on each other toes and do conflicting work, I will add 
a wiki page where people can "take" a product before they start working on 
making it build (and where I possibly should also dump this plan).
Any proposal for the location and name of the wiki page below 
community.kde.org/Calligra ?

On #kde-devel the recommendation was to not blindly run any porting scripts 
that are available, but rather decide case-by-case if to run the script or 
just do manual porting. Another reason why splitting the porting work into 
different people makes more sense.

I expect different parts of Calligra to go different miles for 3.0. Some might 
port away from kdelibs4support as there is not a lot to do, some might be 
happily using it for 3.0. Both should be very fine.
Important are as few regressions as possible and something that is usable :)

Comments, please.

Cheers
Friedrich

PS: Tomas, you had done some initial buildsystem porting experients, right? 
Would you be willing to be the person to do the initial porting steps?