incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Next steps for Symphony and AOO
Date Tue, 12 Jun 2012 18:38:12 GMT
On Mon, Jun 11, 2012 at 11:24 PM, Dennis E. Hamilton <> wrote:
> Predictably, I prefer approach I on first principles:
> Never derail the train that's running.
> From that perspective, there's all of this:
>  - All of the developers and many testers and others know
>   how to build AOO 3.4.0 including people who are working
>   from the source tarball and the folks working on LibreOffice
>   and other co-dependents as well

The Symphony build platform is not very different from AOO.  But since
it was supported only on Windows/Mac/Linux, additional work would be
needed for the *BSD, Solaris and OS/2.  But this is also required for
option I, since the code merged in from Symphony would also be
untested on other ports.  So I think it is the same or similar work,
differing mainly in the pace of change.

>  - the current community includes those who build special
>   distros (of OOo and LO), provide QA that serves all of us,
>   etc.

Not sure what you are referring to.  Are you referring to things like

>  - There is still IP clearance to be done on the Symphony
>   contribution bits and that can be worked through selectively
>   as staging of features/fixes before merging to the SVN trunk.

Yup.  That work needs to be done in either approach.  The main
difference is whether we do it all at once, or gradually.

>  - Alignment of the symphony code can be done off-trunk with
>   merging of selected features and fixes on an iterative basis
>   accompanied by testing of various kinds and localized attention
>   to build breakers and other potential regressions.

I think that is one way in which option I could be implemented.  We
should think of it from the stability perspective, as well as CTR.

>  - There is an abundance of bug reports and analysis based on
>   the current lineage.

There are also bug reports and analysis from the Symphony side.  But
it is fair to say that either approach probably requires that existing
defects from the non-base product be re-validated to see if they are
still relevant.

>  - All of the documentation, forum contributions, MediaWiki
>   and user lists are currently oriented around the OOo-lineage
>   and they need to be morphed in a progressive way, not a sudden
>   switch.

The Symphony contribution should have come with its own documentation.
 If not, that can be added.  Ditto for translations.

>  - Users and others may like new features but for many sudden
>   switches are unsettling

Very true.

>  - Plan II could end up with us having to maintain OOo-lineage releases
>   and Symphony-merged releases concurrently.  That is a frightening
>   prospect.  It is like forking ourselves and maintaining both forks.
>  - Then there's the localizations, etc. that would crash against the
>   forked support, etc.

We're already maintaining two branches, the 3.4.x maintenance branch,
and the trunk.  If we took Plan II, I think we'd still need to
maintain the 3.4.x branch, but do new work in the Symphony trunk.  So
we're dealing with two branches either way.

But hey!  It is not an easy decision.  If there was an obvious perfect
solution that would make everyone happy, I would have just proposed
it.  But both approaches have trade-offs. Symphony is free code, but
integrating it is not free.  (That is the essentially lie of copyleft,
IMHO.  The GPL just forces one to disclose the code.  It does not
force anyone to actively share, integrate, work through issues, etc.).


> Dennis
> -----Original Message-----
> From: Rob Weir []
> Sent: Monday, June 11, 2012 18:08
> To:
> Subject: Next steps for Symphony and AOO
> 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 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.
> 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]
> [1]
> [2]
> [3]
> [4]
> [5]

View raw message