[scribus-dev] Planning CTL integration

[Craig Bradney]

Hi Khaled

I think this is fine - and would work well. 

The only thing I am not sure of are the plans that Andreas had for this CTL work and how that fits in too.

thanks
Craig

> On 04 Nov 2015, at 14:31, Khaled Hosny <khaledhosny at eglug.org> wrote:
> 
> 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
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev