Re: Next steps for Symphony and AOO
--- Ven 13/7/12, Greg Madden ha scritto: ... I have been testing the Symphony deb packages. The 'properties' area is a nice feature, not compelling enough to re-base AOO on Symphony. AOO has progressed, new feaures that I use more than the 'properties area'. thanks for the feedback. The drop down list for 'open document' on the initial screen with all apps is missing. 'ToolsOpenoffice,orgViewUser InterfaceScaleing' is not included. AFAICT, The symphony builds were not meant to be production ready, just meant to show the basic features. I am not interested in losing features that I have incorporated in my work flow, for promises of a 'better whatever' Document fidelity has been outstanding in AOO , add Symphony feaures to AOO if appropriate, by user demand not from the top down. I agree, we all want a better product and the challenge is to preserve all the feature set with no regressions. Pedro.
Re: Next steps for Symphony and AOO
Andrea, Thanks for your comments! Please see my comments below. - Simon 2012/7/12 Andrea Pescetti pesce...@apache.org On 05/07/2012 Shenfeng Liu wrote: While per my reading from the discussion, we generally agreed that the favorite way of integrating the values is to continuously merging Symphony into AOO, feature by feature. ... I also noticed that this thread is no longer as active as 2 weeks before. So I suggest we close this topic Well, it is still a very big issue. People who have seen the Symphony-OpenOffice builds (those made available shortly after the code was granted) were really impressed in general, and have some reasonable expectations to see the OpenOffice interface evolve in that direction soon. What hasn't been discussed in detail, and the key issue to me, is how much OpenOffice plus Symphony would differ from Symphony plus OpenOffice. Ideally, finally there will be little difference between OpenOffice plus Symphonyand Symphony plus OpenOffice when we totally integrated the values from both side. But I can see in 2 years or even longer time, we can not make it. So there will be quite big differences. For the unique value in Symphony code base, you can refer to the wiki with brief introduction: http://wiki.services.openoffice.org/wiki/Symphony_contribution While for the unique value in current AOO code base, unfortunately I do not have a completed list. I can list some of what I know below, people may add more: - Renaissance - Print interface - Extension API enhancement - Some Chart enhancement - Quick save in Calc editor - Some Calc usability improvements - Presentation auto-layout - Presentation Comments - Some fidelity improvements - Some infrastructure refactor works - ... If we choose Symphony plus OpenOffice, during our migration period, the existing OpenOffice users certainly will feel the regression. The mission of this project is to produce an excellent free software office suite. The faster we can improve, the better. If rebasing on Symphony is just a technicality and will bring the same (or very similar) results of gradually merging Symphony into OpenOffice, then I wouldn't see any problems in going this way. Actually, there is one problem: this choice could make life harder for downstream products. Offering a basis for others to build upon is an extremely nice feature of the OpenOffice project, and it should be a priority; but this shouldn't happen at the expense of our mission. (Any possible decisions to rebase on Symphony will of course be accompanied by FUD, rants, disputes over the legacy of OpenOffice... But even the current discussion will be -or has been- very likely misused the same way, even if it's only words so far). From my personal feeling (I'm from Symphony team), all the discussion in this mail thread was fact based. Even the motion people said, is reasonable to me. And I believe every one's goal is, as you said, to produce an excellent free software office suite. And all we are doing is trying to find a better way. That's the reason I really like this community! :) Regards, Andrea.
Re: Next steps for Symphony and AOO
Hi Simon and everyone; --- Gio 12/7/12, Shenfeng Liu ha scritto: ... What hasn't been discussed in detail, and the key issue to me, is how much OpenOffice plus Symphony would differ from Symphony plus OpenOffice. Ideally, finally there will be little difference between OpenOffice plus Symphonyand Symphony plus OpenOffice when we totally integrated the values from both side. But I can see in 2 years or even longer time, we can not make it. So there will be quite big differences. I think we all agree two years is a lot of time. We can always start with option I and re-evaluate later on. I would propose the following: For 3.x Release (x4) we go option I merging only the things that are easy and perhaps a restricted set of CWSs. No UI or drastic changes. For 4.x we go for option II and rebase on Symphony. Part of what was done for 3.5+ will likely be useful here. Another thing that we haven't discussed at all are the patent issues. _ If you don't like speculation please stop reading here. _ The current AOO code has a patent grant from Oracle. The Symphony code adds a patent grant from IBM. It is well known that IBM has more office-relevant patents than Oracle which will likely be an important advantage for most of our users. Pedro.
Re: Next steps for Symphony and AOO
On Thu, Jul 12, 2012 at 12:52 PM, Pedro Giffuni p...@apache.org wrote: Ideally, finally there will be little difference between OpenOffice plus Symphonyand Symphony plus OpenOffice when we totally integrated the values from both side. But I can see in 2 years or even longer time, we can not make it. So there will be quite big differences. I think we all agree two years is a lot of time. We can always start with option I and re-evaluate later on. I would propose the following: For 3.x Release (x4) we go option I merging only the things that are easy and perhaps a restricted set of CWSs. No UI or drastic changes. For 4.x we go for option II and rebase on Symphony. Part of what was done for 3.5+ will likely be useful here. I still don't understand what ground you have to support rebasing on Symphony, because as you have answered me before, you didn't try the build they made, nor finished building by yourself. So, unless you started reading the C++ source code, your support is completely unjustified. It's just like people talking in this thread about revolutionary changes in the Symphony contribution... someone should point at facts, not simply words. The most prominent UI change I see is the property sidebar, that in indeed something new, but not revolutionary, and even worse, in several aspects is an involution from what OpenOffice has been offering its users. Regards
Re: Next steps for Symphony and AOO
--- Gio 12/7/12, Ariel Constenla-Haile arie...@apache.org ha scritto: ... I think we all agree two years is a lot of time. We can always start with option I and re-evaluate later on. I would propose the following: For 3.x Release (x4) we go option I merging only the things that are easy and perhaps a restricted set of CWSs. No UI or drastic changes. For 4.x we go for option II and rebase on Symphony. Part of what was done for 3.5+ will likely be useful here. I still don't understand what ground you have to support rebasing on Symphony, because as you have answered me before, you didn't try the build they made, nor finished building by yourself. So, unless you started reading the C++ source code, your support is completely unjustified. My current proposal is to continue option I and re-evaluate option II next year. I have been very busy on another project, and you might have noticed that I haven't done anything on AOO lately either but by next year we will surely get the Symphony build issues fixed and we can make a more educated decision. There's no way 4.0 will make it this year so I don't think my proposal is at all disruptive. Pedro.
Re: Next steps for Symphony and AOO
On 05/07/2012 Shenfeng Liu wrote: While per my reading from the discussion, we generally agreed that the favorite way of integrating the values is to continuously merging Symphony into AOO, feature by feature. ... I also noticed that this thread is no longer as active as 2 weeks before. So I suggest we close this topic Well, it is still a very big issue. People who have seen the Symphony-OpenOffice builds (those made available shortly after the code was granted) were really impressed in general, and have some reasonable expectations to see the OpenOffice interface evolve in that direction soon. What hasn't been discussed in detail, and the key issue to me, is how much OpenOffice plus Symphony would differ from Symphony plus OpenOffice. The mission of this project is to produce an excellent free software office suite. The faster we can improve, the better. If rebasing on Symphony is just a technicality and will bring the same (or very similar) results of gradually merging Symphony into OpenOffice, then I wouldn't see any problems in going this way. Actually, there is one problem: this choice could make life harder for downstream products. Offering a basis for others to build upon is an extremely nice feature of the OpenOffice project, and it should be a priority; but this shouldn't happen at the expense of our mission. (Any possible decisions to rebase on Symphony will of course be accompanied by FUD, rants, disputes over the legacy of OpenOffice... But even the current discussion will be -or has been- very likely misused the same way, even if it's only words so far). Regards, Andrea.
Re: Next steps for Symphony and AOO
Hi, all, It was 4 weeks since Rob raised the topic, and there were a lot of discussions. I'm so glad to see that people got more familiar with the values in the code contributed from Symphony, tried it out, and liked to see those values to be integrated into AOO future releases. I treat it as a big recognition to Symphony team. While per my reading from the discussion, we generally agreed that the favorite way of integrating the values is to continuously merging Symphony into AOO, feature by feature. This way is good for community's growth and emotion, keeping strong support to the large OpenOffice users base as well as many BPs, and avoiding the technical uncertainty of the code base switch. I also noticed that this thread is no longer as active as 2 weeks before. So I suggest we close this topic, and move on following the current direction we agreed. We already have a successfully 3.4, and 3.4.1 is coming soon. And we can notice that many people are actively working on the trunk for the next release. I think it is time for us to discuss the target and plan for the next release now. It is long way to go, but as RGB ES quoted, walking slow you'll arrive far. With more contributors, we will have bigger steps to bring Symphony value in and develop new features. Overall, my suggestion is: close this discussion thread, and kick off a new topic for the discussion of our next release. Thanks! - Simon 2012/6/29 Kay Schenk kay.sch...@gmail.com On Wed, Jun 27, 2012 at 5:06 PM, Sam Ruby ru...@intertwingly.net wrote: On Wed, Jun 27, 2012 at 7:49 PM, Pedro Giffuni p...@apache.org wrote: It's really disappointing to see uninformed people give opinions about things they evidently don't understand. I can't resist :-) http://xkcd.com/386/ - Sam Ruby Sam, good one! :) This guy would keep busy forever and NEVER sleep! -- MzK I would rather have a donkey that takes me there than a horse that will not fare. -- Portuguese proverb
Re: Next steps for Symphony and AOO
Hello Simon; I know rebasing from Symphony option was never very popular here. Just for the record, I ran a small experiment in the Symphony SVN: I used svn merge to bring some changes from AOO. The process was rather easy and fun. I find the Symphony team did a good job updating a lot of stuff from AOO. The effort was incomplete but it was in the right direction. If we could identify areas that are outdated I think it wouldn't be difficult to merge changes from the legacy SVN server. Some changes would require care but they are doable. I like the current work going on in trunk and I am OK with what seems to be the choice of the majority, just thought I'd share the experience :). best regards, Pedro. --- Gio 5/7/12, Shenfeng Liu liush...@gmail.com ha scritto: Da: Shenfeng Liu liush...@gmail.com Oggetto: Re: Next steps for Symphony and AOO A: ooo-dev@incubator.apache.org Data: Giovedì 5 luglio 2012, 01:28 Hi, all, It was 4 weeks since Rob raised the topic, and there were a lot of discussions. I'm so glad to see that people got more familiar with the values in the code contributed from Symphony, tried it out, and liked to see those values to be integrated into AOO future releases. I treat it as a big recognition to Symphony team. While per my reading from the discussion, we generally agreed that the favorite way of integrating the values is to continuously merging Symphony into AOO, feature by feature. This way is good for community's growth and emotion, keeping strong support to the large OpenOffice users base as well as many BPs, and avoiding the technical uncertainty of the code base switch. I also noticed that this thread is no longer as active as 2 weeks before. So I suggest we close this topic, and move on following the current direction we agreed. We already have a successfully 3.4, and 3.4.1 is coming soon. And we can notice that many people are actively working on the trunk for the next release. I think it is time for us to discuss the target and plan for the next release now. It is long way to go, but as RGB ES quoted, walking slow you'll arrive far. With more contributors, we will have bigger steps to bring Symphony value in and develop new features. Overall, my suggestion is: close this discussion thread, and kick off a new topic for the discussion of our next release. Thanks! - Simon
Re: Next steps for Symphony and AOO
Hi Pedro, On Thu, Jul 5, 2012 at 12:30 PM, Pedro Giffuni p...@apache.org wrote: I know rebasing from Symphony option was never very popular here. Just for the record, I ran a small experiment in the Symphony SVN: I used svn merge to bring some changes from AOO. The process was rather easy and fun. I find the Symphony team did a good job updating a lot of stuff from AOO. The effort was incomplete but it was in the right direction. If we could identify areas that are outdated I think it wouldn't be difficult to merge changes from the legacy SVN server. Some changes would require care but they are doable. I like the current work going on in trunk and I am OK with what seems to be the choice of the majority, just thought I'd share the experience :). could you build it? or at least try one of the binaries they uploaded? Regards
Re: Next steps for Symphony and AOO
Pedro, I feel so glad to see your support to Symphony! And I believe what you experimented will be a Very good experience for the code merge, whatever the direction will be. It is a hard choice, and we want to keep the strong support to existing users, and attract more new users. But we have limited effort, so IMO we'd better focus on one direction and move forward ASAP. I hope there will be more people out of Symphony team can help the feature migration. If you are interested in any of the Symphony feature and want to integrate into AOO, don't hesitate to reach out to Symphony developers for more details, and we can work together! - Simon 在 2012年7月5日星期四，Pedro Giffuni p...@apache.org 写道： Hello Simon; I know rebasing from Symphony option was never very popular here. Just for the record, I ran a small experiment in the Symphony SVN: I used svn merge to bring some changes from AOO. The process was rather easy and fun. I find the Symphony team did a good job updating a lot of stuff from AOO. The effort was incomplete but it was in the right direction. If we could identify areas that are outdated I think it wouldn't be difficult to merge changes from the legacy SVN server. Some changes would require care but they are doable. I like the current work going on in trunk and I am OK with what seems to be the choice of the majority, just thought I'd share the experience :). best regards, Pedro. --- Gio 5/7/12, Shenfeng Liu liush...@gmail.com ha scritto: Da: Shenfeng Liu liush...@gmail.com Oggetto: Re: Next steps for Symphony and AOO A: ooo-dev@incubator.apache.org Data: Giovedì 5 luglio 2012, 01:28 Hi, all, It was 4 weeks since Rob raised the topic, and there were a lot of discussions. I'm so glad to see that people got more familiar with the values in the code contributed from Symphony, tried it out, and liked to see those values to be integrated into AOO future releases. I treat it as a big recognition to Symphony team. While per my reading from the discussion, we generally agreed that the favorite way of integrating the values is to continuously merging Symphony into AOO, feature by feature. This way is good for community's growth and emotion, keeping strong support to the large OpenOffice users base as well as many BPs, and avoiding the technical uncertainty of the code base switch. I also noticed that this thread is no longer as active as 2 weeks before. So I suggest we close this topic, and move on following the current direction we agreed. We already have a successfully 3.4, and 3.4.1 is coming soon. And we can notice that many people are actively working on the trunk for the next release. I think it is time for us to discuss the target and plan for the next release now. It is long way to go, but as RGB ES quoted, walking slow you'll arrive far. With more contributors, we will have bigger steps to bring Symphony value in and develop new features. Overall, my suggestion is: close this discussion thread, and kick off a new topic for the discussion of our next release. Thanks! - Simon
Re: Next steps for Symphony and AOO
--- Gio 5/7/12, Ariel Constenla-Haile arie...@apache.org ha scritto: ... Hi Pedro, On Thu, Jul 5, 2012 at 12:30 PM, Pedro Giffuni p...@apache.org wrote: I know rebasing from Symphony option was never very popular here. Just for the record, I ran a small experiment in the Symphony SVN: I used svn merge to bring some changes from AOO. The process was rather easy and fun. I find the Symphony team did a good job updating a lot of stuff from AOO. The effort was incomplete but it was in the right direction. If we could identify areas that are outdated I think it wouldn't be difficult to merge changes from the legacy SVN server. Some changes would require care but they are doable. I like the current work going on in trunk and I am OK with what seems to be the choice of the majority, just thought I'd share the experience :). could you build it? or at least try one of the binaries they uploaded? I haven't tried the binaries because they didn't include FreeBSD :). I have been short of time lately but it looks like the FreeBSD patches are in sync with AOO. The FreeBSD port (or at least building it) is certainly in my TODO list, no matter what. Pedro.
Re: Next steps for Symphony and AOO
On Wed, Jun 27, 2012 at 5:06 PM, Sam Ruby ru...@intertwingly.net wrote: On Wed, Jun 27, 2012 at 7:49 PM, Pedro Giffuni p...@apache.org wrote: It's really disappointing to see uninformed people give opinions about things they evidently don't understand. I can't resist :-) http://xkcd.com/386/ - Sam Ruby Sam, good one! :) This guy would keep busy forever and NEVER sleep! -- MzK I would rather have a donkey that takes me there than a horse that will not fare. -- Portuguese proverb
Re: Next steps for Symphony and AOO
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 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
Re: Next steps for Symphony and AOO
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 --
Re: Next steps for Symphony and AOO
--- Mer 27/6/12, Rob Weir robw...@apache.org ha scritto: ... 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 employees 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. For the record, I am probably the only supporter of the so-called option II and I am certainly not an IBM employee. If we do take option II, which I honestly see unlikely, the idea would be to reintegrate all the OpenOffice base on top of Symphony and it would be done simply for practical purposes: we know the OpenOffice code and the related changes better than Symphony and we still have the traditional version control systems in place to do an orderly re-merge. We would (and notice it's an hypothetical situation at this time) just be rebasing, something that LibreOffice should be used to already. It's really disappointing to see uninformed people give opinions about things they evidently don't understand. Pedro.
Re: Next steps for Symphony and AOO
On Wed, Jun 27, 2012 at 7:49 PM, Pedro Giffuni p...@apache.org wrote: It's really disappointing to see uninformed people give opinions about things they evidently don't understand. I can't resist :-) http://xkcd.com/386/ - Sam Ruby
Re: Next steps for Symphony and AOO
Now I've got Bobby Weir singing One More Saturday Night in my head. Sent from my iPhone On Jun 27, 2012, at 5:06 PM, Sam Ruby ru...@intertwingly.net wrote: On Wed, Jun 27, 2012 at 7:49 PM, Pedro Giffuni p...@apache.org wrote: It's really disappointing to see uninformed people give opinions about things they evidently don't understand. I can't resist :-) http://xkcd.com/386/ - Sam Ruby
Re: Next steps for Symphony and AOO
Hello All, Sorry for top post. Where are we at? Have we summarized the discussion? Have all expressed their views? How might we crystallized our position and move forward? Regards, Kevin On Thursday, June 28, 2012, Rob Weir 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 On Mon, Jun 11, 2012 at 9:08 PM, Rob Weir robw...@apache.orgjavascript:; 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]
Re: Next steps for Symphony and AOO
Hi Kevin; --- Mer 27/6/12, Kevin Grignon kevingrignon...@gmail.com ha scritto: Hello All, Sorry for top post. Where are we at? Have we summarized the discussion? Have all expressed their views? How might we crystallized our position and move forward? There is indeed a big problem. I think we all agree there is a lot of nice code to integrate, but beyond the method we use to merge the codebases, there is still the much deeper issue: should we abandon the OOo UI to use a Symphony UI + enhancements? I don't have an answer. Pedro.
Re: Next steps for Symphony and AOO
For option I, it is a easy path. Quitely like we will keep going with it. As we see recently, a lot of patches from Symphony were submitted. The problem with Option I is some features may never be migrated into AOO, like Async document loading, property sidebar and some improvements don't look like that important. If we go with option II, I would agree with Pedro that we will work on both options at the same time. keep two releases for a period of time until we are sure that AOO 3.4 user can smoothly move to a new release. Concerns from Dennis and RGB's are quite reasonable and need be considered first before we make any big move for this project. The feature missed from the Symphony code base may be exaggerated from an end user's point of view. Both of them were developed from OO.o 3.1 and quite a few improvements from OO.o 3.x have been integrated into the symphony code base already Both options need huge effort. Option I needs more effort but with low risk. The code has been ready now. Can people work on the contribution code base if they like? Can such kind of changes be documented in BZ? These are decisions need be made by community. On Sun, Jun 17, 2012 at 1:55 AM, Fernando Cassia fcas...@gmail.com wrote: On Fri, Jun 15, 2012 at 9:24 PM, Yong Lin Ma mayo...@apache.org wrote: Symphony get a java wrapper. That needs more memory footprint. Well ThinkFree office is a Java-based office suite and very lean, even compared to stock OpenOffice.org. a 56MB download. http://office.thinkfree.com/en/download.html So I guess Java or no-Java is not an indication of bloat or lack thereof. The Java part makes Symphony bigger than OO.o. It is not a common claim that Java makes things big. I remember saying 3-4 years ago it´d be great if Sun bought ThinkFree and turned it into OpenOffice Cloud integrating it with then-new Google Docs, keeping OO.o as ´openoffice desktop´. Where would we be now... FC
Re: Next steps for Symphony and AOO
On Fri, Jun 15, 2012 at 5:24 PM, Yong Lin Ma mayo...@apache.org wrote: Symphony get a java wrapper. That needs more memory footprint. Symphony also needs more disk space due the java plug-ins and new templates, clip arts. There is no java wrapper for the build we are discussing here. Thank you -- this was not clear to me...I didn't really understand the reference to the java wrapper -- sorry. I really was quite in agreement with Fernando's remarks on this thread, and after seeing the additional information on the IBM site, I got more concerned. The memory it needs should in the same level of AOO or may be less due to some optimization we made. Well this would be good news in the right direction! When Symphony was integrated in notes, we were pushed very hard to fix any increase on memory cost. Disk space also is not a problem. It quite depends on what we want packaged in it. Good! I was thinking about this more also last evening. I was thinking that maybe some of the current enhancements in Symphony could perhaps be provided as extensions instead of directly integrated if that's possible. I think many of our users are happy with the capabilities provided now and don't really want extra features that consume more resources. Last but not the least, the recommended configuration for a software given by different people may also be different. Well it would be interesting to see a further discussion on that as well. For more detail info about the contribution, please visit http://wiki.services.openoffice.org/wiki/Symphony I did read through this but it was too much of a summary to provide much detail. Thank you for it though. This is why I decided to find out more client requirements from the IBM site. Yes, we need to discuss in detail development considerations including sustainability, design considerations, but, in the end, our clients are what will ultimately determine success I think. Thank you for this additional information. On Sat, Jun 16, 2012 at 7:36 AM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Jun 15, 2012 at 3:06 PM, Fernando Cassia fcas...@gmail.com wrote: On Mon, Jun 11, 2012 at 10:08 PM, Rob Weir robw...@apache.org wrote: 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. I'm in favor of an evolutionary rather then revolutionary change. This way, it also gives devs more time to consider what features have a higher priority and give most benefit to the AOO Suite. The second option you suggest is simply replacing OpenOffice with Symphony FC Folks may also be interested in the general FAQ on Symphony (IBM doc) http://www-03.ibm.com/software/lotus/symphony/help.nsf/GeneralFAQ particularly the client requirements which is a concern to me anyway. The recommended disk space is 750M compared to the current 450M for linux for example. (Though on my current setup, it doesn't use even close to 450M). And similar increase for memory requirements. Can someone give more explanation of the client system requirements for Symphony maybe by augmenting : http://wiki.services.openoffice.org/wiki/Symphony_contribution So, for now, without additional information, I have no opinion. -- MzK There's no crying in baseball! -- Jimmy Dugan (Tom Hanks), A League of Their Own -- MzK There's no crying in baseball! -- Jimmy Dugan (Tom Hanks), A League of Their Own
Re: Next steps for Symphony and AOO
On 6/14/12 10:19 PM, Pedro Giffuni wrote: --- Gio 14/6/12, Marcus (OOo) marcus.m...@wtnet.de ha scritto: ... And I think it's not just about emotions. If you take A as base and pick the enhancements of B you'll get an enhanced A. You won't probably remove features from A but take only some of B. So the decision between Method I and II is also the decision to work for an enhanced OOo/AOO or for an enhanced Symphony. I might have missed something but the idea behind both options is to arrive to the same product, that means reusing as much available code as possible. more or less, I doubt that we will achieve 100% in both directions. Also a clear +1 from me to go the way of option I. It would be interesting to could put the options in some time metric. My guess (and it's only a guess, not an estimate) ... Option I : 2 years. Option II: 8 months. we should be careful with spreading numbers based on wild guessing. It requires some deeper analysis. Personally, I think I will work on both options at the same time: I do want to have an early Symphony BSD port. No objections if I start merging patches into Symphony once uploaded? :). you are free in the work you are doing but I think it would be wrong. We should find an agreement on the direction we want to move forward. Our goal is to take the best of both and build the best free office suite ever. We shouldn't split further resources by working on 2 code bases. It will be the completely wrong signal. I am of course against releasing 2 source releases based on 2 different source trees. I am surprised about such an idea Juergen
Re: Next steps for Symphony and AOO
And I'd like to repeat what Rob mentioned in his previous mail, behind option I option II is in fact an open question: how can we quickly integrate the most value in current AOO and Symphony together to deliver the next generation of AOO 4.0? We made a lot of technical study, and either option has some advantage and disadvantage for short term as well as long term of AOO development, and will face different issues and risks on the way. But is there any other innovative way that can be even better and even faster? That's the question for brainstorming. 发自我的 iPhone 在 2012-6-15，15:31，Pedro Giffuni p...@apache.org 写道： --- Ven 15/6/12, Jürgen Schmidt jogischm...@googlemail.com ha scritto: ... we should be careful with spreading numbers based on wild guessing. It requires some deeper analysis. Yes, you are right. The estimates for bringing the accessibility stuff are rather discouraging for option I though. Personally, I think I will work on both options at the same time: I do want to have an early Symphony BSD port. No objections if I start merging patches into Symphony once uploaded? :). you are free in the work you are doing but I think it would be wrong. We should find an agreement on the direction we want to move forward. Our goal is to take the best of both and build the best free office suite ever. We shouldn't split further resources by working on 2 code bases. It will be the completely wrong signal. Well, I won't be doing any main development just merge some of what has already been done in AOO, mostly the BSD port. I am of course against releasing 2 source releases based on 2 different source trees. There are unofficial demo releases of Symphony already, I am not forking, I only want to do the BSD port. I am surprised about such an idea Surprises can be good :). Pedro.
Re: Next steps for Symphony and AOO
On Mon, Jun 11, 2012 at 10:08 PM, Rob Weir robw...@apache.org wrote: 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. I'm in favor of an evolutionary rather then revolutionary change. This way, it also gives devs more time to consider what features have a higher priority and give most benefit to the AOO Suite. The second option you suggest is simply replacing OpenOffice with Symphony FC
Re: Next steps for Symphony and AOO
On Fri, Jun 15, 2012 at 3:06 PM, Fernando Cassia fcas...@gmail.com wrote: On Mon, Jun 11, 2012 at 10:08 PM, Rob Weir robw...@apache.org wrote: 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. I'm in favor of an evolutionary rather then revolutionary change. This way, it also gives devs more time to consider what features have a higher priority and give most benefit to the AOO Suite. The second option you suggest is simply replacing OpenOffice with Symphony FC Folks may also be interested in the general FAQ on Symphony (IBM doc) http://www-03.ibm.com/software/lotus/symphony/help.nsf/GeneralFAQ particularly the client requirements which is a concern to me anyway. The recommended disk space is 750M compared to the current 450M for linux for example. (Though on my current setup, it doesn't use even close to 450M). And similar increase for memory requirements. Can someone give more explanation of the client system requirements for Symphony maybe by augmenting : http://wiki.services.openoffice.org/wiki/Symphony_contribution So, for now, without additional information, I have no opinion. -- MzK There's no crying in baseball! -- Jimmy Dugan (Tom Hanks), A League of Their Own
Re: Next steps for Symphony and AOO
Symphony get a java wrapper. That needs more memory footprint. Symphony also needs more disk space due the java plug-ins and new templates, clip arts. There is no java wrapper for the build we are discussing here. The memory it needs should in the same level of AOO or may be less due to some optimization we made. When Symphony was integrated in notes, we were pushed very hard to fix any increase on memory cost. Disk space also is not a problem. It quite depends on what we want packaged in it. Last but not the least, the recommended configuration for a software given by different people may also be different. For more detail info about the contribution, please visit http://wiki.services.openoffice.org/wiki/Symphony On Sat, Jun 16, 2012 at 7:36 AM, Kay Schenk kay.sch...@gmail.com wrote: On Fri, Jun 15, 2012 at 3:06 PM, Fernando Cassia fcas...@gmail.com wrote: On Mon, Jun 11, 2012 at 10:08 PM, Rob Weir robw...@apache.org wrote: 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. I'm in favor of an evolutionary rather then revolutionary change. This way, it also gives devs more time to consider what features have a higher priority and give most benefit to the AOO Suite. The second option you suggest is simply replacing OpenOffice with Symphony FC Folks may also be interested in the general FAQ on Symphony (IBM doc) http://www-03.ibm.com/software/lotus/symphony/help.nsf/GeneralFAQ particularly the client requirements which is a concern to me anyway. The recommended disk space is 750M compared to the current 450M for linux for example. (Though on my current setup, it doesn't use even close to 450M). And similar increase for memory requirements. Can someone give more explanation of the client system requirements for Symphony maybe by augmenting : http://wiki.services.openoffice.org/wiki/Symphony_contribution So, for now, without additional information, I have no opinion. -- MzK There's no crying in baseball! -- Jimmy Dugan (Tom Hanks), A League of Their Own
Re: Next steps for Symphony and AOO
Hello Ma Yong Lin, 2012/6/14 Ma Yong Lin mayo...@apache.org Yes. Please see FAQ in http://wiki.services.openoffice.org/wiki/Symphonyfor more details. I've tried to install the binary build on Windows 7 after suppressing AOO 3.4 and Symphony 3.01. Installation : OK No problem up to now when running the provided US version. Only problems if I try to install the fr language pack 3.4. Installation runs fine but AOO doesn't work correctly after (especially Writer doesn't open). Many thanks for your work, I really like this version. A+ -- gw
Re: Next steps for Symphony and AOO
Am 06/12/2012 10:53 PM, schrieb Christoph Jopp: Am 12.06.2012 21:46, schrieb Regina Henschel: [...] I do not like version II. It is not about objective reasons, but about emotions. I'm involved in OpenOffice.org more then ten years. After Oracle shuts it down, being at Apache gives more the feeling of a translation than of a new product. Using Symphony as base feels like loosing OOo a second time. +1 And I think it's not just about emotions. If you take A as base and pick the enhancements of B you'll get an enhanced A. You won't probably remove features from A but take only some of B. So the decision between Method I and II is also the decision to work for an enhanced OOo/AOO or for an enhanced Symphony. Also a clear +1 from me to go the way of option I. Marcus
Re: Next steps for Symphony and AOO
--- Gio 14/6/12, Marcus (OOo) marcus.m...@wtnet.de ha scritto: ... And I think it's not just about emotions. If you take A as base and pick the enhancements of B you'll get an enhanced A. You won't probably remove features from A but take only some of B. So the decision between Method I and II is also the decision to work for an enhanced OOo/AOO or for an enhanced Symphony. I might have missed something but the idea behind both options is to arrive to the same product, that means reusing as much available code as possible. Also a clear +1 from me to go the way of option I. It would be interesting to could put the options in some time metric. My guess (and it's only a guess, not an estimate) ... Option I : 2 years. Option II: 8 months. Personally, I think I will work on both options at the same time: I do want to have an early Symphony BSD port. No objections if I start merging patches into Symphony once uploaded? :). Pedro.
Re: Next steps for Symphony and AOO
On Thu, 2012-06-14 at 13:19 -0700, Pedro Giffuni wrote: --- Gio 14/6/12, Marcus (OOo) marcus.m...@wtnet.de ha scritto: ... And I think it's not just about emotions. If you take A as base and pick the enhancements of B you'll get an enhanced A. You won't probably remove features from A but take only some of B. So the decision between Method I and II is also the decision to work for an enhanced OOo/AOO or for an enhanced Symphony. I might have missed something but the idea behind both options is to arrive to the same product, that means reusing as much available code as possible. Also a clear +1 from me to go the way of option I. It would be interesting to could put the options in some time metric. My guess (and it's only a guess, not an estimate) ... Option I : 2 years. Option II: 8 months. Personally, I think I will work on both options at the same time: *chuckling*... good choice. I do want to have an early Symphony BSD port. No objections if I start merging patches into Symphony once uploaded? :). Oh no, a wild variant (mutant) version is born.. ;-) why not, you have the skill and the clay in your hands. //drew Pedro.
Re: Next steps for Symphony and AOO
Hi Rob, Hi all, 2012/6/12 Rob Weir robw...@apache.org 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. It's not an easy choice. From my end user point of view : Solution I is better for maintaining the existing population of OO.org users. Solution II is better for getting new users, I think. A MS Office teacher said me recently that he thought that the principal issue for the growing of the number of OO users was not a quality issue of the software, but simply the fact that it looks too much like a new MS Office 2003 version ... but free. So, it appears too much as an old maintained software. Just my opinion A+ -- gw
Re: Next steps for Symphony and AOO
On 6/13/12 11:03 AM, Guy Waterval wrote: Hi Rob, Hi all, 2012/6/12 Rob Weir robw...@apache.org 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. It's not an easy choice. From my end user point of view : Solution I is better for maintaining the existing population of OO.org users. Solution II is better for getting new users, I think. A MS Office teacher said me recently that he thought that the principal issue for the growing of the number of OO users was not a quality issue of the software, but simply the fact that it looks too much like a new MS Office 2003 version ... but free. So, it appears too much as an old maintained software. Both options will bring UI changes and I hope that we can focus in the future on finding our own identity and can provide an office application that solves daily problems and that makes the work on common and frequently tasks as easy as possible for our users. Juergen
Re: Next steps for Symphony and AOO
2012/6/12 Rob Weir robw...@apache.org 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. Apologies if I missed this, but what version of OpenOffice.org is Symphony based on? Presumably we'll need to backport any features added to OpenOffice.org since that version if we just rebrand Symphony this way. S.
Re: Next steps for Symphony and AOO
On Wed, Jun 13, 2012 at 2:11 PM, Simon Phipps si...@webmink.com wrote: 2012/6/12 Rob Weir robw...@apache.org 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. Apologies if I missed this, but what version of OpenOffice.org is Symphony based on? Presumably we'll need to backport any features added to OpenOffice.org since that version if we just rebrand Symphony this way. We've been porting OOo features into Symphony on an ongoing basis for years. So one should not think of Symphony as being derived from only a single version of OOo. It is a mix. But what you say about back porting is certainly true. That is why I wrote, ...there are areas where Symphony is missing enhancements or bug fixes that are in OpenOffice. But one cannot quantify this delta merely by comparing version numbers. One would need to look at individual change sets. -Rb S.
Re: Next steps for Symphony and AOO
On 13 Jun 2012, at 21:02, Rob Weir wrote: On Wed, Jun 13, 2012 at 2:11 PM, Simon Phipps si...@webmink.com wrote: 2012/6/12 Rob Weir robw...@apache.org 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. Apologies if I missed this, but what version of OpenOffice.org is Symphony based on? Presumably we'll need to backport any features added to OpenOffice.org since that version if we just rebrand Symphony this way. We've been porting OOo features into Symphony on an ongoing basis for years. So one should not think of Symphony as being derived from only a single version of OOo. It is a mix. OK, understood. But what was the base version of the fork you've been porting to? 3.1? Thanks, S.
Re: Next steps for Symphony and AOO
Sent from iPad 在 2012-6-14，上午4:14，Simon Phipps si...@webmink.com 写道： On 13 Jun 2012, at 21:02, Rob Weir wrote: On Wed, Jun 13, 2012 at 2:11 PM, Simon Phipps si...@webmink.com wrote: 2012/6/12 Rob Weir robw...@apache.org 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. Apologies if I missed this, but what version of OpenOffice.org is Symphony based on? Presumably we'll need to backport any features added to OpenOffice.org since that version if we just rebrand Symphony this way. We've been porting OOo features into Symphony on an ongoing basis for years. So one should not think of Symphony as being derived from only a single version of OOo. It is a mix. OK, understood. But what was the base version of the fork you've been porting to? 3.1? Yes. Please see FAQ in http://wiki.services.openoffice.org/wiki/Symphony for more details. Thanks, S.
Re: Next steps for Symphony and AOO
On Mon, Jun 11, 2012 at 11:10 PM, Pedro Giffuni p...@apache.org wrote: Can we really not have the java components from Symphony? Why? Java is an asset rather than a problem. FC
Re: Next steps for Symphony and AOO
On 13 Jun 2012, at 23:56, Ma Yong Lin wrote: 在 2012-6-14，上午4:14，Simon Phipps si...@webmink.com 写道： OK, understood. But what was the base version of the fork you've been porting to? 3.1? Yes. Please see FAQ in http://wiki.services.openoffice.org/wiki/Symphony for more details. Great, many thanks. I see from that page that the help content in Symphony is from OO.o 3.3 as well. S.
Re: Next steps for Symphony and AOO
On Thu, Jun 14, 2012 at 7:02 AM, Simon Phipps si...@webmink.com wrote: On 13 Jun 2012, at 23:56, Ma Yong Lin wrote: 在 2012-6-14，上午4:14，Simon Phipps si...@webmink.com 写道： OK, understood. But what was the base version of the fork you've been porting to? 3.1? Yes. Please see FAQ in http://wiki.services.openoffice.org/wiki/Symphony for more details. Great, many thanks. I see from that page that the help content in Symphony is from OO.o 3.3 as well. Good question. It is a little complicated. I will answer here then add it to the FAQ. OO.o 3.x help content is packaged in the the binary build of the Symphony code contribution. But both OO.o 3.x help content and Symphony 3.1 help content can be found in the source code of the contribution. The help system of Symphony 3.1 is eclipse based. AOO or OO.o help mechanism is used in the code contribution. The Symphony help content can't be consumed by AOO directly. S.
Re: Next steps for Symphony and AOO
KG01 - See comments inline. On Wed, Jun 13, 2012 at 5:16 PM, Jürgen Schmidt jogischm...@googlemail.comwrote: On 6/13/12 11:03 AM, Guy Waterval wrote: Hi Rob, Hi all, 2012/6/12 Rob Weir robw...@apache.org 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. It's not an easy choice. From my end user point of view : Solution I is better for maintaining the existing population of OO.org users. Solution II is better for getting new users, I think. A MS Office teacher said me recently that he thought that the principal issue for the growing of the number of OO users was not a quality issue of the software, but simply the fact that it looks too much like a new MS Office 2003 version ... but free. So, it appears too much as an old maintained software. Both options will bring UI changes and I hope that we can focus in the future on finding our own identity and can provide an office application that solves daily problems and that makes the work on common and frequently tasks as easy as possible for our users. KG01 - This is an important point. Beyond technical bits, we need to be mindful to design and develop products that help people capture their thoughts, and share their ideas. KG01 - AOO 4.0 will some flavour of code merge/migration effort, but should also have, as Jurgen so eloquently put it, a unique identity. Our release themes should include such items. Juergen
Re: Next steps for Symphony and AOO
--- Mer 13/6/12, Fernando Cassia fcas...@gmail.com ha scritto: Pedro Giffuni p...@apache.org wrote: Can we really not have the java components from Symphony? Why? Java is an asset rather than a problem. Oh, you misunderstood .. I *want* them. I even updated most of our Java stuff in the hope that we disprove that myth about Java being slow. Pedro. FC
Re: Next steps for Symphony and AOO
2012/6/12 Dennis E. Hamilton orc...@apache.org: Predictably, I prefer approach I on first principles: Never derail the train that's running. I think this is fundamental: big changes on short times will give enormous problems to the current user base, not only because the obvious need to learn something new, but also for the inevitable load of new bugs. AOO is a user oriented system, so we need to put our users first by avoiding any regression and limiting the annoyances. I think we can learn a lot about the KDE 4.0 experience: even if KDE 4 started to be wonderful after 4.3, even now on the 4.8 era there are people still protesting because the disastrous experience with 4.0... Four years have passed! Option 1 is slow, but as my grandmother used to say walking slow you'll arrive far Regards Ricardo
RE: Next steps for Symphony and AOO
I have the additional concern that UOF integration may be disrupted by a rebasing on Symphony (approach II). It depends on how close UOF was working against an OO.o base that is essentially retained by AOO (approach I). Last year, I did some *very* limited interoperability testing of Symphony support for ODF package features and I found inexplicable differences in the handling of packages, especially ones having ODF 1.2 digital signatures. I have not tested enough to determine how close Symphony 3 is to some version of OO.o in terms of ODF support and have no opinion about that beyond wondering what it is and if there is an impact if rebasing on Symphony were attempted. - Dennis -Original Message- From: RGB ES [mailto:rgb.m...@gmail.com] Sent: Tuesday, June 12, 2012 01:36 To: ooo-dev@incubator.apache.org; orc...@apache.org Subject: Re: Next steps for Symphony and AOO 2012/6/12 Dennis E. Hamilton orc...@apache.org: Predictably, I prefer approach I on first principles: Never derail the train that's running. I think this is fundamental: big changes on short times will give enormous problems to the current user base, not only because the obvious need to learn something new, but also for the inevitable load of new bugs. AOO is a user oriented system, so we need to put our users first by avoiding any regression and limiting the annoyances. I think we can learn a lot about the KDE 4.0 experience: even if KDE 4 started to be wonderful after 4.3, even now on the 4.8 era there are people still protesting because the disastrous experience with 4.0... Four years have passed! Option 1 is slow, but as my grandmother used to say walking slow you'll arrive far Regards Ricardo
Re: Next steps for Symphony and AOO
On Mon, Jun 11, 2012 at 11:24 PM, Dennis E. Hamilton orc...@apache.org 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 PortableApps? - 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.). -Rob Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, June 11, 2012 18:08 To: ooo-dev@incubator.apache.org 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 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
Re: Next steps for Symphony and AOO
On Tue, Jun 12, 2012 at 1:38 PM, Rob Weir robw...@apache.org wrote: (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.). 1/ Are you publishing this under GPL ? if not, then what is the relevance of that remark ? 2/ If that code had been developed under a coplyleft regime then you would not be dumping multiple year of fix + improvement in one big dump. Incremental changes are easier to assimilate. Norbert
Re: Next steps for Symphony and AOO
Am 12.06.2012 21:46, schrieb Regina Henschel: [...] I do not like version II. It is not about objective reasons, but about emotions. I'm involved in OpenOffice.org more then ten years. After Oracle shuts it down, being at Apache gives more the feeling of a translation than of a new product. Using Symphony as base feels like loosing OOo a second time. +1 And I think it's not just about emotions. If you take A as base and pick the enhancements of B you'll get an enhanced A. You won't probably remove features from A but take only some of B. So the decision between Method I and II is also the decision to work for an enhanced OOo/AOO or for an enhanced Symphony. Kind regards Regina
Re: Next steps for Symphony and AOO
On Tue, 2012-06-12 at 14:38 -0400, Rob Weir wrote: On Mon, Jun 11, 2012 at 11:24 PM, Dennis E. Hamilton orc...@apache.org 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 PortableApps? Sure, and EuroOffice, NeoOffice, NeoShineOffice and I suppose a few others - a few companies field vertical market style applications based on the code line, medical records comes to mind but I can't recall the actual company name . At least that is what came to my mind when reading along. //drew snip
Re: Next steps for Symphony and AOO
On Mon, 2012-06-11 at 21:08 -0400, Rob Weir 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. Hi Rob, others May I break out one piece of that work and ask about that. Is there a reasonably trusted estimate on the effort to move the Windows accessibility enhancements from the Symphony code line to the current 3.4 line? Thanks much for your time, //drew snip
Re: 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 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. I always liked those two choices! My gut goes for revolution, however do I remember a comment from way back that OOo extensions don't work with Symphony? That might be a disruption too far perhaps. Cheers GL 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
Re: 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 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. I always liked those two choices! My gut goes for revolution, however do I remember a comment from way back that OOo extensions don't work with Symphony? That might be a disruption too far perhaps. Cheers GL 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
Re: Next steps for Symphony and AOO
On Wed, Jun 13, 2012 at 8:48 AM, Graham Lauder g.a.lau...@gmail.com wrote: I always liked those two choices! My gut goes for revolution, however do I remember a comment from way back that OOo extensions don't work with Symphony? That might be a disruption too far perhaps. Cheers GL That's partially true. The contributed Symphony code is originated from OOo 3.1m11, it also contains a few new extension code from AOO 3.4, so some simple extensions like dictionaries does work, but if the extension involves GUI extensions or depends on late AOO features that Symphony doesn't have yet, they still don't work. Option II also implies that all extension support code should be migrated to Symphony code base. Regards, zhangjf
Re: Next steps for Symphony and AOO
On Wed, Jun 13, 2012 at 5:03 AM, drew d...@baseanswers.com wrote: On Mon, 2012-06-11 at 21:08 -0400, Rob Weir 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. Hi Rob, others May I break out one piece of that work and ask about that. Is there a reasonably trusted estimate on the effort to move the Windows accessibility enhancements from the Symphony code line to the current 3.4 line? Steve Yin will answer this with a new thread. Thanks. Thanks much for your time, //drew snip
Re: Next steps for Symphony and AOO
On 06/11/12 20:08, Rob Weir 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. Wow ... First of all let me ask one question: Can we really not have the java components from Symphony? We do have Java stuff already and even if it may not seem so, Eclipse is not really a problem since we can ship Category B binaries. Concerning the dilemma: - Option (I) can basically only be done well by the Symphony guys because they know the changes well enough and only they have access to the history. It will likely take them a lot of time and we may lose some features in the process and we will never know. -On option (II) we can all help as we all have access to the Hg repositories and we can use svn merge for the changes AOO has done. There is the unfortunate risk that we might have issues merging some of the pre-Apache changes. This may also lead to inconsistencies between 3.4 and 4.0. For me option II is more mechanical and although it may seem more work (redo the BSD port!) it is less effort and more predictable. I would go with that one: merging AOO into Symphony. Pedro.
Re: Next steps for Symphony and AOO
First of all let me ask one question: Can we really not have the java components from Symphony? We do have Java stuff already and even if it may not seem so, Eclipse is not really a problem since we can ship Category B binaries. I'm curious about this as well. Was IBM's rationale for not donating the Java bits based on a perception that we wouldn't *want* that stuff, or is it just proprietary IP that IBM wants to hold onto (Yog-Soggoth knows why, if so, since they donated everything else!), or is there some other reason? Personally I'd love to see AOO get our hands on the Java bits, even if they don't make it into an eventual AOO release. I suspect (hope?) that some stuff in there might be useful to future (or current) projects focused on integrating AOO and Eclipse, which would be kinda cool. But, in either case, big thanks to IBM for donating the Symphony code as they did. Even if they don't ever release the Java stuff. :-) Phil
RE: Next steps for Symphony and AOO
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. - 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. - 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. - 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. - 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. Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, June 11, 2012 18:08 To: ooo-dev@incubator.apache.org 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 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
Re: Next steps for Symphony and AOO
On Tue, Jun 12, 2012 at 10:10 AM, Pedro Giffuni p...@apache.org wrote: On 06/11/12 20:08, Rob Weir 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. Wow ... First of all let me ask one question: Can we really not have the java components from Symphony? We do have Java stuff already and even if it may not seem so, Eclipse is not really a problem since we can ship Category B binaries. The Java components in Symphony are implemented on Lotus Expeditor(XPD) libraries and running on it's workbenches. Such as the multi-tabbed documents, toolbar, status bar... XPD has a more modern UI comparing to OpenOffice's own one. Technically they should also work if they are migrated to Eclipse RCP. But it also has it's own shortage. There is big impact on performance and need great effort on UX integration, and it is hard to maintain the communication and integration between the two processes. Personally I don't think AOO will make such big changes in a short period. While some pieces of Java code which doesn't heavily depends on XPD libraries can be migrated to OOo AWT controls with small effort, Or even we can keep using the RCP libraries for more fancy UI, such as the mail merge. zhangjf Concerning the dilemma: - Option (I) can basically only be done well by the Symphony guys because they know the changes well enough and only they have access to the history. It will likely take them a lot of time and we may lose some features in the process and we will never know. -On option (II) we can all help as we all have access to the Hg repositories and we can use svn merge for the changes AOO has done. There is the unfortunate risk that we might have issues merging some of the pre-Apache changes. This may also lead to inconsistencies between 3.4 and 4.0. For me option II is more mechanical and although it may seem more work (redo the BSD port!) it is less effort and more predictable. I would go with that one: merging AOO into Symphony. Pedro.
Re: Next steps for Symphony and AOO
KG01 - See comments inline. On Tuesday, June 12, 2012, Dennis E. Hamilton wrote:that the challenge before us is to find the best possible 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. - 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. - 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. - 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. - 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. Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org javascript:;] Sent: Monday, June 11, 2012 18:08 To: ooo-dev@incubator.apache.org javascript:; 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 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. KG01 - While I appreciate that merge/migration presents a host of challenges and opportunities from an implementation and support perspective, I'll defer to the community to assess the technical dimensions. I do, however, have an opinion on the design direction of the offering moving forward. I don't see one product as better than the other. Rather, they are different. Each has strengths which could be emulated, and each have opportunties for improvement. Diversity presents opportunity. If design is choice, then we have two great products as sources of user experience design patterns. The best possible user experience would ultimately be the outcome of migrating and merging the best user experience elements from each of the offerings into a new code base. Features found in one offering, but not the other, present migration opportunities. Features found in both offerings, present an opportunity to merge the user experience. As Rob noted, our challenge is to determine how we choose the best user experience, then establish a roadmap to deliver the best user experience possible for our users. The AOO UX wiki [1] contains a user experience-oriented assessment of the Symphony contribution. Visit the AOO UX wiki to learn more about UX migration/merge candidates, and review key feature analysis. The intended outcome of the UX-oriented assessment activity is to form a prioritized, actionable backlog of user experience opportunities to drive informed design and development decisions. Please note, this UX-oriented assessment is an living, ongoing activity, and all are welcome to contribute to these work products. [1] http://wiki.services.openoffice.org/wiki/AOO_UX_Symphony_Contribution 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
Re: Next steps for Symphony and AOO
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 own. - 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. Pedro. Dennis -Original Message- From: Rob Weir [mailto:robw...@apache.org] Sent: Monday, June 11, 2012 18:08 To: ooo-dev@incubator.apache.org 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 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]
