incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: Next steps for Symphony and AOO
Date Wed, 27 Jun 2012 23:07:25 GMT
Top posting as a comment on the entire post, and what it is and what it isn't.

In a recent article [1], later quoted in in LinuxToday [2], a
LibreOffice board member was interviewed and made some erroneous
statements regarding Apache OpenOffice and Symphony:

"[W]e are looking forward the interesting switch at Apache OpenOffice
from the Openoffice.org codebase to the Symphony codebase; there will
certainly be some code we might be able to reuse. Although, when you
come to think of it, it’s funny to enter the Apache Incubation Process
with one software you’re inheriting, and to use a different software
you’ve also inherited just after the incubation process is completed"

Charles states pretty much the same on the LibreOffice marketing list [3]:

"AOO 4.0 will have the Symphony interface, and what this means is that
it will bring a whole new different set of bugs."

This is asserted as a decision.  It is not.  It is merely one option
of several that this project has been considering in this thread.  In
fact, what IBM employes have been doing most recently, as anyone
following this list knows, is merging bug fixes from Symphony into the
trunk and the 3.4.1 branch.  So we're obviously not currently going
down the 2nd option decribed in this thread.

If Charles, or anyone else at LibreOffice has an opinion on either of
the Symphony merge options, or wishes to suggest other options, they
are welcome to come onto this list and share their comments.  That is
how we do things here at Apache.  In particular, since Charles
mentioned that there might be some code LibreOffice could reuse,  I'd
be interested to know which option they think would make it easiest
for them to benefit from our work.

And if Roy or anyone else doing a story on Apache OpenOffice wants a
better sense of what is happening in the project a good place to start
would be our Press page [4].

[1] http://techrights.org/2012/06/26/mandriva-openoffice-and-libreoffice/
[2] http://www.linuxtoday.com/upload/charles-h.-schulz-speaks-about-mandriva-openoffice.org-and-libreoffice-120626082503.html
[3] http://listarchives.libreoffice.org/global/marketing/msg05407.html
[4] http://incubator.apache.org/openofficeorg/press.html

Regards,

-Rob

On Mon, Jun 11, 2012 at 9:08 PM, Rob Weir <robweir@apache.org> wrote:
> 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.
>
> 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