Re: Before Symphony contribution
On Tue, Jul 19, 2011 at 12:17 AM, imacat ima...@mail.imacat.idv.tw wrote: On 2011/07/19 03:08, Rob Weir said: +1 Let's start from a stable build and make changes from there that leave the build stable. So I think it looks like this: 1) Get all OOo Hg repository converted over to SVN. This will include all the code that was granted us in the Oracle SGA, as well as code that was not granted us as well as LPGL dependencies. It will be essentially equivalent to to the current OOo trunk. It's very nice we all have this understanding, at least something we can tell our local community about the current progress. So, we'll still have to have SVN up first. 2) Verify that this builds. I'd like to see independent confirmation from several developers that we can build from that source, including at least the 3 major platforms. As far as I know, the current OpenOffice.org HG source does not build on Debian. I can help on this as much as I can. But we still have to have SVN up first. 3) Based on that and the original Oracle SGA, find out what files we need to be added to the SGA. I know work on this has already started. Thanks for everyone that is working on this. 4) At this point, once we have the complete Oracle SGA, then IBM can contribute the Symphony source. Why? Because our code is contributable under Apache 2.0 to the extent that the code is either original, or based on code that also under Apache 2.0. So our contribution depends on the amended SGA of the core code. That said, will there be Symphony candies in our first 3.4? Possibly. But I don't see anything from Symphony is a must have for AOOo 3.4. I think it is more important that we complete 3.4 with the feature set that was originally planned. 6) Then at some point we have an OOo 3.4.0 that is functionality identical to the 3.4 beta, but all under Apache license. Then we work on getting to release quality. This might include some additional testing, integrating existing patches, making additional fixes, etc. Of course, this is not just code, but doc, help, translations, etc. So, will there be fixes to the existing OOo 3.4 that we can work on? I assume so. 3.4.0 beta 1 was released a few months ago. We should review any bugs reports received, etc. I'd also expect that our replacement of LGPL dependencies will introduce new bugs. So we'll need a good QA cycle on 3.4 before we release it. I think we should aim for release 3.4 to continue the tradition of high quality releases that OOo is known for. -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice.org http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/
Re: Before Symphony contribution
On 2011/07/19 19:02, Rob Weir said: On Tue, Jul 19, 2011 at 12:17 AM, imacat ima...@mail.imacat.idv.tw wrote: On 2011/07/19 03:08, Rob Weir said: Possibly. But I don't see anything from Symphony is a must have for AOOo 3.4. I think it is more important that we complete 3.4 with the feature set that was originally planned. I assume so. 3.4.0 beta 1 was released a few months ago. We should review any bugs reports received, etc. I'd also expect that our replacement of LGPL dependencies will introduce new bugs. So we'll need a good QA cycle on 3.4 before we release it. I think we should aim for release 3.4 to continue the tradition of high quality releases that OOo is known for. I see. I agree. That is good idea. ^_*' -- Best regards, imacat ^_*' ima...@mail.imacat.idv.tw PGP Key http://www.imacat.idv.tw/me/pgpkey.asc Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's http://www.imacat.idv.tw/ Woman in FOSS in Taiwan http://wofoss.blogspot.com/ OpenOffice.org http://www.openoffice.org/ EducOO/OOo4Kids Taiwan http://www.educoo.tw/ signature.asc Description: OpenPGP digital signature
Re: Before Symphony contribution
On 18.07.2011 18:32, imacat wrote: Dear all, I welcome the contribution from the Symphony team. But before the Symphony contribution, shouldn't it be the first task to move the source onto Apache SVN or something, instead of the current mercurial hg? Not only IBM would like to contribute back to OpenOffice.org, but many of us here would like to do so, too. Having a new public SVN enables everyone here to be able to participate. And this should not be IBM OpenOffice.org, but Apache OpenOffice.org. (I already heard people talking so.) Sorry to be blunt. ^^; Of course we won't integrate anything from anywhere before we are done with the initial stuff. At least that is my understanding. Regards, Mathias
Re: Before Symphony contribution
Am 07/18/2011 06:32 PM, schrieb imacat: I welcome the contribution from the Symphony team. But before the Symphony contribution, shouldn't it be the first task to move the source onto Apache SVN or something, instead of the current mercurial hg? Not only IBM would like to contribute back to OpenOffice.org, but many of us here would like to do so, too. Having a new public SVN enables everyone here to be able to participate. And this should not be IBM OpenOffice.org, but Apache OpenOffice.org. (I already heard people talking so.) Sure. First we will have our initial release and then we will have a look how to integrate the Symphony code (or parts) into the project. Marcus
Re: Before Symphony contribution
Yes, that is the right sequence. Our project is Apache OpenOffice, no question there. The intent behind the future code contribution of Symphony is to make it possible to harvest some of the value from it, and to merge that value into Apache OpenOffice. PPMC members affiliated with IBM, will be volunteering to do this effort in collaboration with others in the project, in the Apache Way. Building Apache OpenOffice from Oracle's Software Grant to Apache is the priority. If there's another view on this, let's here it. /don On Mon, Jul 18, 2011 at 1:07 PM, Marcus (OOo) marcus.m...@wtnet.de wrote: Am 07/18/2011 06:32 PM, schrieb imacat: I welcome the contribution from the Symphony team. But before the Symphony contribution, shouldn't it be the first task to move the source onto Apache SVN or something, instead of the current mercurial hg? Not only IBM would like to contribute back to OpenOffice.org, but many of us here would like to do so, too. Having a new public SVN enables everyone here to be able to participate. And this should not be IBM OpenOffice.org, but Apache OpenOffice.org. (I already heard people talking so.) Sure. First we will have our initial release and then we will have a look how to integrate the Symphony code (or parts) into the project. Marcus
Re: Before Symphony contribution
On Mon, Jul 18, 2011 at 7:29 PM, Donald Harbison dpharbi...@gmail.com wrote: Yes, that is the right sequence. Our project is Apache OpenOffice, no question there. The intent behind the future code contribution of Symphony is to make it possible to harvest some of the value from it, and to merge that value into Apache OpenOffice. PPMC members affiliated with IBM, will be volunteering to do this effort in collaboration with others in the project, in the Apache Way. Building Apache OpenOffice from Oracle's Software Grant to Apache is the priority. If there's another view on this, let's here it. Symphony replaced most of OO.o's GPL/LGPL dependencies with more liberally licensed code. Shouldn't we use those bits now, to get to Apache OO.o quickly? Damjan
Re: Before Symphony contribution
imacat wrote: Dear all, I welcome the contribution from the Symphony team. But before the Symphony contribution, shouldn't it be the first task to move the source onto Apache SVN or something, instead of the current mercurial hg? Not only IBM would like to contribute back to OpenOffice.org, but many of us here would like to do so, too. Having a new public SVN enables everyone here to be able to participate. And this should not be IBM OpenOffice.org, but Apache OpenOffice.org. (I already heard people talking so.) Sorry to be blunt. ^^; I happen to agree. Andy
Re: Before Symphony contribution
On Mon, Jul 18, 2011 at 2:16 PM, Andy Brown a...@the-martin-byrd.net wrote: Damjan Jovanovic wrote: On Mon, Jul 18, 2011 at 7:29 PM, Donald Harbison dpharbi...@gmail.com wrote: Yes, that is the right sequence. Our project is Apache OpenOffice, no question there. The intent behind the future code contribution of Symphony is to make it possible to harvest some of the value from it, and to merge that value into Apache OpenOffice. PPMC members affiliated with IBM, will be volunteering to do this effort in collaboration with others in the project, in the Apache Way. Building Apache OpenOffice from Oracle's Software Grant to Apache is the priority. If there's another view on this, let's here it. Symphony replaced most of OO.o's GPL/LGPL dependencies with more liberally licensed code. Shouldn't we use those bits now, to get to Apache OO.o quickly? Damjan We have to have the code to make sure that it will build properly before making any changes. Then the process to remove/replace unusable code. This is where the IBM code can be looked at and added. +1 Let's start from a stable build and make changes from there that leave the build stable.So I think it looks like this: 1) Get all OOo Hg repository converted over to SVN. This will include all the code that was granted us in the Oracle SGA, as well as code that was not granted us as well as LPGL dependencies. It will be essentially equivalent to to the current OOo trunk. 2) Verify that this builds. I'd like to see independent confirmation from several developers that we can build from that source, including at least the 3 major platforms. 3) Based on that and the original Oracle SGA, find out what files we need to be added to the SGA. I know work on this has already started. 4) At this point, once we have the complete Oracle SGA, then IBM can contribute the Symphony source. Why? Because our code is contributable under Apache 2.0 to the extent that the code is either original, or based on code that also under Apache 2.0. So our contribution depends on the amended SGA of the core code. 5) Then work on removing the incompatible 3rd party code, GPL, LGPL, etc. This can be done in parallel with #4 if we want. 6) Then at some point we have an OOo 3.4.0 that is functionality identical to the 3.4 beta, but all under Apache license. Then we work on getting to release quality. This might include some additional testing, integrating existing patches, making additional fixes, etc. Of course, this is not just code, but doc, help, translations, etc. 7) We'll also want to do some minimal rebranding, in splash screen, Help/About, documentation, etc. to acknowledge that this is an ASF project. 8) Once we're happy with the build, we can go through the process to approve a Podling Release 9) In future releases we can discuss what other features and fixes from Symphony it makes sense to merge in. But I would not recommend complicating the steps 1-8 above with that. Let's try to finish OOo 3.4 with the features it currently has. That will be hard enough. Andy
