On Mon, Jul 18, 2011 at 2:16 PM, Andy Brown <[email protected]> wrote: > Damjan Jovanovic wrote: >> On Mon, Jul 18, 2011 at 7:29 PM, Donald Harbison <[email protected]> >> 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 >
