[scribus-dev] Planning CTL integration

[Khaled Hosny]

Hi,

I contacted Andreas about the status of his work few weeks ago and got
no answer from him, so I’d much like to hear his opinion on this.

Regards,
Khaled

On Thu, Nov 05, 2015 at 12:04:31AM +0100, Craig Bradney wrote:
> 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
> 
> 
> _______________________________________________
> scribus-dev mailing list
> scribus-dev at lists.scribus.net
> http://lists.scribus.net/mailman/listinfo/scribus-dev