Calligra 3.0 for Qt 5.1?

[Sebastian Sauer]

On 07/30/2013 08:47 PM, Jaroslaw Staniek wrote:
> On 30 July 2013 02:20, Sven Langkamp <sven.langkamp at gmail.com> wrote:
>> On Mon, Jul 29, 2013 at 12:11 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
>>> I want to propose that we start porting Calligra to Qt 5.1 now that 2.7 is
>>> released. Jolla is funding KO GmbH to work on porting the core, so this is a
>>> good moment to get started. On the other hand, we're in the middle of gsoc
>>> and users still want new features and bug fixes. And there is quite a large
>>> number of (Krita) users who actually use git master for their daily work.
>>
>> I have the feeling that we are running into the same problems as we did in
>> the KDE 4 port. Back then we did start porting too early and that made a lot
>> more work and to much longer than it should have.
>>
>> I still excited that Jolla steps up and funds some of the porting work and
>> with our already stretched manpower we should make use of that.
>>
>>> I see the following options:
>>>
>>> * git master becomes the Qt5 branch. Work on gsoc, features and bug fixes
>>> can go on in Qt4 based branches, and the patches need to be ported to Qt5
>>> when merging to master.
>>>
>>> * we keep a qt5 branch and regularly merge master to the qt5 branch. Big
>>> refactorings (komvc, build system changes) should only happen in the Qt5
>>> branch. New features and bug fixes and gsoc results can be merged to master.
>>
>> I prefer the second one. That what be less a surprise for everyone running
>> master. To avoid much merge work we could put that in feature freeze for
>> bigger features and at some point merge the qt5 branch back.
> +1

+2

May I suggest a two steps approach:

0) Get pending work needed for the port to master while still on Qt4. 
Give them some time till problems are sorted out.

1) Port

Port to Qt5, keep kdelibs deps like they are, use e.g. those kdelibs 
fake lib I have in coffice.

Golden rule: Not refactor. Never ever refactor while porting.

That's not a rule I came up with but its very very true. Just not 
refactor during a port. Never ever. Get things compiling, starting up, 
core functionality working, voila.

2) Refactor.

Specific things will need refactoring the one or other way. This will 
need much testing and has lots of potential for regressions. So, ideally 
now the work should happen in master.

What I suggest is to do the port in a branch, get things working good 
enough so people can at least start the apps, load a document, view it. 
Then merge the work to master, start discussing / working on needed 
refactorings.

p.s. I would be willing to help on 1) and 2).