incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <robw...@apache.org>
Subject Re: [code][repo] Integration of CWSs
Date Tue, 06 Sep 2011 18:32:27 GMT
On Tue, Sep 6, 2011 at 2:23 PM, Pedro F. Giffuni <giffunip@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 <ooo@erack.de> wrote:
>
>> From: Eike Rathke <ooo@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.GF29051@kulungile.erack.de>
>> http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C20110831191817.GF29051@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
>>
>

Mime
View raw message