On Wed, Jun 27, 2012 at 4:07 PM, Rob Weir <robw...@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 <robw...@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
