incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <kay.sch...@gmail.com>
Subject Re: Next steps for Symphony and AOO
Date Wed, 27 Jun 2012 23:13:53 GMT
On Wed, Jun 27, 2012 at 4:07 PM, Rob Weir <robweir@apache.org> wrote:

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

Unbelievable! It's amazing that people come up with this stuff.

I could say more but maybe I'd better not.



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



-- 
----------------------------------------------------------------------------------------
MzK

"I would rather have a donkey that takes me there
 than a horse that will not fare."
                                          -- Portuguese proverb

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message