Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <1315333423.83704.YahooMailClassic@web113519.mail.gq1.yahoo.com>
References: <20110906165052.GL11827@kulungile.erack.de>
	<1315333423.83704.YahooMailClassic@web113519.mail.gq1.yahoo.com>
Date: Tue, 6 Sep 2011 14:32:27 -0400
Message-ID: 
 <CAP-ksoi1OToUK10L79VFkT_VReLuwetowvgRrfq6D8YiO8WLHA@mail.gmail.com>
Subject: Re: [code][repo] Integration of CWSs
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Sep 6, 2011 at 2:23 PM, Pedro F. Giffuni <giffunip@tutopia.com> wro=
te:
> 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.=C2=A0 Right now I think the most
>> important task is to
>> | > review the IP of the code and get that fixed where
>> needed.=C2=A0 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.=C2=A0 The complexity
>> | > would be if they are modify or adding files that are
>> in categories #2,
>> | > #4, or #5.=C2=A0 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,
>> |=C2=A0 =C2=A0 should not give any problem other than merge
>> conflicts if it touches
>> |=C2=A0 =C2=A0 code that was already removed for #2, #3 or
>> #4. All other code newly
>> |=C2=A0 =C2=A0 introduced in such a CWS is covered by the
>> SCA/OCA and hence also
>> |=C2=A0 =C2=A0 covered by the SGA, if I understood
>> correctly.
>> |
>> | b) CWS does introduce new code covered by an incompatible
>> license, will
>> |=C2=A0 =C2=A0 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
>> |=C2=A0 =C2=A0 clashes when the CWSs will be integrated,
>> additionally lookout for
>> |=C2=A0 =C2=A0 new license incompatible code when
>> integrating CWSs thereafter, or
>> |
>> | y) first integrate all CWSs, note down new license
>> incompatible code the
>> |=C2=A0 =C2=A0 CWS introduces, and after all CWSs are
>> integrated start the clean-up
>> |=C2=A0 =C2=A0 of the entire tree. CWSs rarely introduce
>> new external code, so new
>> |=C2=A0 =C2=A0 code that would be covered by an
>> incompatible license should be an
>> |=C2=A0 =C2=A0 exemption.
>> |
>> | I'd favour y) because we wouldn't have to deal with
>> additional merge
>> | conflicts as would be the case with x).
>>
>>
>> =C2=A0 Eike
>>
>> --
>> =C2=A0PGP/OpenPGP/GnuPG encrypted mail preferred in all private
>> communication.
>> =C2=A0Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3=C2=A0 9E96
>> 2F1A D073 293C 05FD
>>
>