Jump to content

Calligra/Schedules/3.0/Porting Plan: Difference between revisions

From KDE Community Wiki
Frinring (talk | contribs)
Initial version
 
Frinring (talk | contribs)
Line 53: Line 53:
kdchart & kdgantt are to be replaced by kdiagram (kchart,kgantt, ask frinring).
kdchart & kdgantt are to be replaced by kdiagram (kchart,kgantt, ask frinring).


koproperty & koreport are to be replaced by kproperty & kreport (ask jstaniek).
db, koproperty & koreport are to be replaced by predicate, kproperty & kreport (ask jstaniek).
Removing these libs/plugins will also render some Find*,cmake macros unneeded, but best check the buildsystem before just removing them.


=Initial porting steps=
=Initial porting steps=

Revision as of 22:35, 24 February 2015

Dates

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

^ 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!

General

  • Porting branch named "frameworks" usually, some stuff expects it even.
  • Min Qt5 version: 5.2 (matches current KF5 min required version)
  • Min KF5 version: 5.?
  • Min CMake version: ?
  • Min ECM version: 1.?

Porting Rules

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

To not have people step on each other toes and do conflicting work there will be a board on todo.kde.org where people can take a product before they start working on making it build. (TODO for Friedrich)

Porting Helpers

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.

Porting Targets

Different parts of Calligra will 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 :)

Stuff that can be removed

  • 3rdparty/kdchart/
  • 3rdparty/kdchartpatches/
  • 3rdparty/kdgantt/
  • 3rdparty/kdganttpatches/
  • libs/db/
  • libs/koproperty/
  • libs/koreport/
  • plugins/reporting/

kdchart & kdgantt are to be replaced by kdiagram (kchart,kgantt, ask frinring).

db, koproperty & koreport are to be replaced by predicate, kproperty & kreport (ask jstaniek). Removing these libs/plugins will also render some Find*,cmake macros unneeded, but best check the buildsystem before just removing them.

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 subdirs of stuff moved outside already
  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 build dir:

   dot -Tsvg product_deps.dot > product_deps.svg

or

   dot -Tpng product_deps.dot > product_deps.png