Taking care of a TODO item

[David Faure]

On Monday 05 November 2012 00:03:44 Valentin Rusu wrote:
> Hello,
> 
> Trying to catchup with frameworks splitting effort, after a quite busy
> lapse of time, I'd like to take care of a TODO item, as listed on the
> epics page:
> http://community.kde.org/Frameworks/Epics/Splitting_kdelibs
> 
> I think I can take care of kutils/kemoticons or kdeui/dialogs. Are these
> already taken by someone?
> 
> After reading the available documentation and taking a look into the
> sources I understand that framework splitting should be done this way:
> - create a new entry for the framework under the staging directory and
> move the sources in that location,
> - adjust all the other dependencies around kdelibs to make them compile
> using the new configuration,
> - remove unwanted dependencies and apply the porting rules (is there un
> up-to-date guide for that?),
> - finally, move the framework to it's new tier (tier3 for these items)
> Am I correct with these steps?

The problem with doing it in that order, as we did initially, is that after 
the first step, you end up with something that doesn't compile, and that 
requires a lot of work still, and you can't push that yet (since it breaks 
compilation), so this ends up being one huge commit or many commits that you 
can't push for a very long time. Not great. This is how some past work has 
been mostly lost by now, with frameworks splitted out in git branches, and 
never merged back because the work wasn't finished.

This is why I have now moved to a different order, which I recommend:
1) identify dependencies to unsplitted stuff (kdecore, kdeui, etc.)
and unwanted dependencies to other frameworks
2) solve these dependencies (port away from unsplitted stuff, etc.)
Commit, push now and then, no problem there.
3) Create new framework in staging/, move the stuff there, commit (don't push), 
make it compile, commit (don't push)
4) Fix compilation of the rest of kdelibs, commit, push.
The separate commits above make reviewing of the changes much easier than "one 
big commit which moves and modifies the code at the same time".
5) Check the TODO list for frameworks on community.kde.org, and once 
everything is green, move the framework from staging to tierN.

PS:  the porting guide is KDE5PORTING.html at the top of kdelibs, but it won't 
help you very much, most of kdelibs code was already ported to these steps, I 
think.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5