[scribus-dev] Planning CTL integration

[Khaled Hosny]

Hi all,

I’ve been thinking of a way to get CTL-related code integrated into
Scribus trunk as early as possible since this seems to be the main
failure of previous attempts (whether using a separate branch that
quickly bit-rots, or doing it completely outside Scribus repository
making it even harder to integrate).

Given the disruptive nature of the changes, it is not easy to do them
incrementally easier without breaking lots of functionality in the
meantime, so I have been considering the following plan and would like
to hear the opinions of Scribus developers before moving ahead with it:

* Rebasing old OIF branch on top of trunk and getting it to compile and
  run, with all its limitations.
  - There is quite some good code in this branch and it would be a
    wasted effort if we didn’t make use of it.
* Put all this code behind a compile time switch that is off by default
  and make sure nothing changes when the switch is off.
  - This way we can get the code in trunk as early as possible, without
    drastically affecting the usability of Scribus, until the new code
    is ready to be switched on by default.
  - Being on trunk should allow other interested developers to work on
    it and makes it possible for outside contributors to work on it as
    well and send patches and get them reviewed early on, instead of
    waiting until everything is ready which makes it harder for the
    patches to be reviewed and integrated.
  - Being on trunk will also hopefully prevent the code from
    bit-rotting, especially if we managed to get it compiled regularly
    (using a continuous integration service for example).
  - We can alternatively use a run time switch (like what Qt did when
    they integrated the new HarfBuzz), this makes sure the code is
    always buildable and allows users to test the new functionality
    without having recompile Scribus. But it might be trickier than a
    build time switch. (I used a runtime switch when integrating
    HarfBuzz into LibreOffice and it helped nailing down regression
    greatly, also it gave the users some fallback when the default was
    switched until the new code matured enough to drop the old code
    entirely.)
* Once the code is on trunk, we can identify broken or missing
  functionality, have tickets for them on the issue tracker and any one
  interested can work on them.
* Once all blocking issues are fixed, we can switch the new code on by
  default and after a time of testing we can kill the old code.

What do others think?

Regards,
Khaled