On Tue, Sep 6, 2011 at 2:23 PM, Pedro F. Giffuni <giffu...@tutopia.com> wrote: > Hello Eike; > > From what I discussed with Rob there is no objection > on his side wrt to integrating the CWS'. >
Yes, please, just don't break the universe. The work to do the IP review appears to be approximately the same if we do it before versus after the CWS integration. -Rob > I was waiting for the FreeBSD port to go through before > pushing this further, but in general the idea here is > that lazy consensus applies: no one objected so the > issue is left for those that actually know what to > integrate. > > Perhaps Matthias and you, which seem to know better than > anyone else what to integrate can agree on the order and > just do it? > > Pedro. > > ps. yes.. I agree this email list is getting just too > cluttered. > > > --- On Tue, 9/6/11, Eike Rathke <o...@erack.de> wrote: > >> From: Eike Rathke <o...@erack.de> >> Subject: [code][repo] Integration of CWSs >> To: ooo-dev@incubator.apache.org >> Date: Tuesday, September 6, 2011, 11:50 AM >> Hi, >> >> And now for something completely different: CODE >> >> As lined out in >> >> Message-ID: <20110831191817.gf29...@kulungile.erack.de> >> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3c20110831191817.gf29...@kulungile.erack.de%3E >> >> there are 2 possible approaches to integrate pending CWSs >> and I favoured >> one of them. I've seen no response to that other than >> Pedro's, maybe my >> suggestion was buried too deep in that thread and people >> are too busy >> with fighting over forum and documentation governance. I'm >> tired of >> wading through those piles of mails wasting the project's >> time and >> efforts and putting people off. In the mean time -- I'm >> referring a time >> span of more than the last week that passed since my mail >> -- we could >> have had the CWSs integrated, identified copyright/license >> problematic >> bits of code, and maybe even found some solutions for >> copyleft code >> removal to get things going. >> >> I offered my help with the CWSs since the beginning, hoping >> that the >> code repository would had been there much earlier. Summer >> here was >> almost non-existing with weather conditions just right to >> keep me >> indoors, but now I will focus on other things, spare time >> life is short >> enough and can be enjoyed.. as for my part that means I'll >> enjoy staying >> away from computer keyboards for some time starting next >> week and have >> fun under the sun. >> >> For reference, here the body of the mail mentioned above: >> >> | On Wednesday, 2011-08-31 09:22:46 -0400, Rob Weir wrote: >> | >> | > It is a trade-off. Right now I think the most >> important task is to >> | > review the IP of the code and get that fixed where >> needed. Right now >> | > all code in the repository is in one of these >> categories: >> | > >> | > 1) Files that are in the Oracle SGA >> | > >> | > 2) Files that Oracle owns that are not in their >> original SGA but will >> | > need ot be in their new SGA >> | > >> | > 3) Files that are from 3rd party open source >> modules, where the code >> | > has a compatible license >> | > >> | > 4) Files that are from 3rd party open source >> modules, where the code >> | > has an incompatible license >> | > >> | > 5) Files where we cannot establish accurately their >> origin or license >> | > >> | > I think the priority should be to identify all files >> in categories #2, >> | > #4 and #5, so we can fix them. >> | > >> | > If people are adding new code to the repository, >> that introduces a new >> | > category, of changes made by committers, under >> ALv2. The complexity >> | > would be if they are modify or adding files that are >> in categories #2, >> | > #4, or #5. If we can avoid that, then I don't >> see a problem. >> | > >> | > What we want to avoid is having us review a given >> AOOo module, clean >> | > it up from IP perspective, and move on to another >> modules, and then >> | > have it recontaminated by merging in, via a patch or >> CWS integration, >> | > code that is dirty. >> | >> | CWS integration can be of two categories: >> | >> | a) CWS does not introduce new code covered by an >> incompatible license, >> | should not give any problem other than merge >> conflicts if it touches >> | code that was already removed for #2, #3 or >> #4. All other code newly >> | introduced in such a CWS is covered by the >> SCA/OCA and hence also >> | covered by the SGA, if I understood >> correctly. >> | >> | b) CWS does introduce new code covered by an incompatible >> license, will >> | pollute the tree anyway and those code parts >> will have to be removed. >> | >> | So, we can choose: >> | >> | x) first identify and remove license incompatible code to >> be pointed to >> | clashes when the CWSs will be integrated, >> additionally lookout for >> | new license incompatible code when >> integrating CWSs thereafter, or >> | >> | y) first integrate all CWSs, note down new license >> incompatible code the >> | CWS introduces, and after all CWSs are >> integrated start the clean-up >> | of the entire tree. CWSs rarely introduce >> new external code, so new >> | code that would be covered by an >> incompatible license should be an >> | exemption. >> | >> | I'd favour y) because we wouldn't have to deal with >> additional merge >> | conflicts as would be the case with x). >> >> >> Eike >> >> -- >> PGP/OpenPGP/GnuPG encrypted mail preferred in all private >> communication. >> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 >> 2F1A D073 293C 05FD >> >
