[scribus-dev] Planning CTL integration
khaledhosny at eglug.org
Wed Nov 4 13:31:38 UTC 2015
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
* 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?
More information about the scribus-dev