incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Lauder <g.a.lau...@gmail.com>
Subject Re: Next steps for Symphony and AOO
Date Wed, 13 Jun 2012 00:48:28 GMT
> As we wait [0] for the Symphony [1] code to be loaded into Subversion
> I think it would be good to start a discussion on "next steps" of how
> we can make best use of this contribution.
> 
> Hopefully you've had time to review the list of features on the wiki
> [2], install one of the binaries [3] , or maybe even download the
> source [4] and try to build it [5].
> 
> As will see by your examination, the Symphony code base has co-evolved
> with OpenOffice.org for several years now, and continued to co-evolve
> with Apache OpenOffice even recently.  Symphony has many features and
> bug fixes that AOO lacks.  And there are areas where Symphony is
> missing enhancements or bug fixes that are in OpenOffice.
> 
> Our challenge is to find the best way to bring these two code bases
> together, to make the best product.
> 
> I think there are two main approaches to this problem:
> 
> I.  Merge code, from Symphony, feature by feature, into AOO, in a
> prioritized order.  This is the "slow" approach, since it would take
> (by the estimates I've seen) a couple of years to bring all of the
> Symphony enhancements and bug fixes over to AOO.
> 
> II.  Use Symphony as the the new base, and merge (over time) AOO (and
> OOo) enhancements and bug fixes into the new trunk.  This approach
> quickly gives a new UI, something we could fairly call Apache
> OpenOffice 4.0.  But this approach would also give us some short-term
> pain.   For example, those involved in porting AOO 3.4 would need to
> merge their patches into the new trunk.   We'd need to update license
> headers again.  Help files and translation are done differently in
> Symphony, and so on.
> 
> Looked at another way, option I is a slow, but easy path.  Option II
> is a leap forward, but will be initially more work and disruption.
> Evolution versus Revolution.

I always liked those two choices!  My gut goes for revolution, however do I 
remember a comment from way back that OOo extensions don't work with Symphony?  
That might be a disruption too far perhaps.

Cheers
GL 


> 
> So let's discuss.  Please ask questions about the pro's and con's of
> each approach.  The code and binaries are all posted, and my IBM
> colleagues in Beijing are happy to answer your questions.
> 
> Regards,
> 
> -Rob
> 
> 
> [0] https://issues.apache.org/jira/browse/INFRA-4799
> 
> [1] http://wiki.services.openoffice.org/wiki/Symphony
> 
> [2] http://wiki.services.openoffice.org/wiki/Symphony_contribution
> 
> [3] http://people.apache.org/~zhangjf/symphony/build/
> 
> [4] https://svn-master.apache.org/repos/test/danielsh/symphony-import/
> 
> [5]
> http://wiki.services.openoffice.org/wiki/How_to_build_Symphony%27s_source_
> code

Mime
View raw message