openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pedro Giffuni <>
Subject Re: Next steps for Symphony and AOO
Date Tue, 12 Jun 2012 04:44:34 GMT
On 06/11/12 22:24, 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 current community includes those who build special
>     distros (of OOo and LO), provide QA that serves all of us,
>     etc.

I don't think the build procedure would change much at
all, but a change would be good. I don't think anyone is
proud of the current build system-

>   - 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.

That is rather minimal from what I have seen (ucpp).

>   - 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.

That is likely to be very difficult, and is the reason why alternative
II is being proposed. Symphony already works and builds on it's

>   - There is an abundance of bug reports and analysis based on
>     the current lineage.
>   - 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.

I am afraid this is something that just has to be done either
way. Some bugs are simply old and a lot of the
documentation is obsolete or under uncertain copyrights-

>   - Users and others may like new features but for many sudden
>     switches are unsettling
>   - 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 would focus completely on the 4.x release after 3.4.1 is
released so I would expect we would EOL 3.4.x soon. We
would indeed be forking the code though; not sure what
would happen with "base".

The real question here is what works better for the people
doing the work. For me it's easier to take patches from
OOo/AOO and merge them than to try to extract features
from Symphony, but it would be interesting to hear what
the ex-Oracle guys have to say.


> 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