Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: unknown ipv4:200.91.200.0/24 (nike.apache.org: encountered
 unrecognized mechanism during SPF processing of domain of
 giffunip@tutopia.com)
Message-ID: <1315333423.83704.YahooMailClassic@web113519.mail.gq1.yahoo.com>
Date: Tue, 6 Sep 2011 11:23:43 -0700 (PDT)
From: "Pedro F. Giffuni" <giffunip@tutopia.com>
Reply-To: giffunip@tutopia.com
Subject: Re: [code][repo] Integration of CWSs
To: ooo-dev@incubator.apache.org
In-Reply-To: <20110906165052.GL11827@kulungile.erack.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Eike;=0A=0AFrom what I discussed with Rob there is no objection=0Aon =
his side wrt to integrating the CWS'.=0A=0AI was waiting for the FreeBSD po=
rt to go through before=0Apushing this further, but in general the idea her=
e is=0Athat lazy consensus applies: no one objected so the=0Aissue is left =
for those that actually know what to=0Aintegrate.=0A=0APerhaps Matthias and=
 you, which seem to know better than=0Aanyone else what to integrate can ag=
ree on the order and=0Ajust do it?=0A=0APedro.=0A=0Aps. yes.. I agree this =
email list is getting just too=0Acluttered.=0A=0A=0A--- On Tue, 9/6/11, Eik=
e Rathke <ooo@erack.de> wrote:=0A=0A> From: Eike Rathke <ooo@erack.de>=0A> =
Subject: [code][repo] Integration of CWSs=0A> To: ooo-dev@incubator.apache.=
org=0A> Date: Tuesday, September 6, 2011, 11:50 AM=0A> Hi,=0A> =0A> And now=
 for something completely different: CODE=0A> =0A> As lined out in=0A> =0A>=
 Message-ID: <20110831191817.GF29051@kulungile.erack.de>=0A> http://mail-ar=
chives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3C20110831191817.=
GF29051@kulungile.erack.de%3E=0A> =0A> there are 2 possible approaches to i=
ntegrate pending CWSs=0A> and I favoured=0A> one of them. I've seen no resp=
onse to that other than=0A> Pedro's, maybe my=0A> suggestion was buried too=
 deep in that thread and people=0A> are too busy=0A> with fighting over for=
um and documentation governance. I'm=0A> tired of=0A> wading through those =
piles of mails wasting the project's=0A> time and=0A> efforts and putting p=
eople off. In the mean time -- I'm=0A> referring a time=0A> span of more th=
an the last week that passed since my mail=0A> -- we could=0A> have had the=
 CWSs integrated, identified copyright/license=0A> problematic=0A> bits of =
code, and maybe even found some solutions for=0A> copyleft code=0A> removal=
 to get things going.=0A> =0A> I offered my help with the CWSs since the be=
ginning, hoping=0A> that the=0A> code repository would had been there much =
earlier. Summer=0A> here was=0A> almost non-existing with weather condition=
s just right to=0A> keep me=0A> indoors, but now I will focus on other thin=
gs, spare time=0A> life is short=0A> enough and can be enjoyed.. as for my =
part that means I'll=0A> enjoy staying=0A> away from computer keyboards for=
 some time starting next=0A> week and have=0A> fun under the sun.=0A> =0A> =
For reference, here the body of the mail mentioned above:=0A> =0A> | On Wed=
nesday, 2011-08-31 09:22:46 -0400, Rob Weir wrote:=0A> | =0A> | > It is a t=
rade-off.=A0 Right now I think the most=0A> important task is to=0A> | > re=
view the IP of the code and get that fixed where=0A> needed.=A0 Right now=
=0A> | > all code in the repository is in one of these=0A> categories:=0A> =
| > =0A> | > 1) Files that are in the Oracle SGA=0A> | > =0A> | > 2) Files =
that Oracle owns that are not in their=0A> original SGA but will=0A> | > ne=
ed ot be in their new SGA=0A> | > =0A> | > 3) Files that are from 3rd party=
 open source=0A> modules, where the code=0A> | > has a compatible license=
=0A> | > =0A> | > 4) Files that are from 3rd party open source=0A> modules,=
 where the code=0A> | > has an incompatible license=0A> | > =0A> | > 5) Fil=
es where we cannot establish accurately their=0A> origin or license=0A> | >=
 =0A> | > I think the priority should be to identify all files=0A> in categ=
ories #2,=0A> | > #4 and #5, so we can fix them.=0A> | > =0A> | > If people=
 are adding new code to the repository,=0A> that introduces a new=0A> | > c=
ategory, of changes made by committers, under=0A> ALv2.=A0 The complexity=
=0A> | > would be if they are modify or adding files that are=0A> in catego=
ries #2,=0A> | > #4, or #5.=A0 If we can avoid that, then I don't=0A> see a=
 problem.=0A> | > =0A> | > What we want to avoid is having us review a give=
n=0A> AOOo module, clean=0A> | > it up from IP perspective, and move on to =
another=0A> modules, and then=0A> | > have it recontaminated by merging in,=
 via a patch or=0A> CWS integration,=0A> | > code that is dirty.=0A> | =0A>=
 | CWS integration can be of two categories:=0A> | =0A> | a) CWS does not i=
ntroduce new code covered by an=0A> incompatible license,=0A> |=A0 =A0 shou=
ld not give any problem other than merge=0A> conflicts if it touches=0A> |=
=A0 =A0 code that was already removed for #2, #3 or=0A> #4. All other code =
newly=0A> |=A0 =A0 introduced in such a CWS is covered by the=0A> SCA/OCA a=
nd hence also=0A> |=A0 =A0 covered by the SGA, if I understood=0A> correctl=
y.=0A> | =0A> | b) CWS does introduce new code covered by an incompatible=
=0A> license, will=0A> |=A0 =A0 pollute the tree anyway and those code part=
s=0A> will have to be removed.=0A> | =0A> | So, we can choose:=0A> | =0A> |=
 x) first identify and remove license incompatible code to=0A> be pointed t=
o=0A> |=A0 =A0 clashes when the CWSs will be integrated,=0A> additionally l=
ookout for=0A> |=A0 =A0 new license incompatible code when=0A> integrating =
CWSs thereafter, or=0A> | =0A> | y) first integrate all CWSs, note down new=
 license=0A> incompatible code the=0A> |=A0 =A0 CWS introduces, and after a=
ll CWSs are=0A> integrated start the clean-up=0A> |=A0 =A0 of the entire tr=
ee. CWSs rarely introduce=0A> new external code, so new=0A> |=A0 =A0 code t=
hat would be covered by an=0A> incompatible license should be an=0A> |=A0 =
=A0 exemption.=0A> | =0A> | I'd favour y) because we wouldn't have to deal =
with=0A> additional merge=0A> | conflicts as would be the case with x).=0A>=
 =0A> =0A> =A0 Eike=0A> =0A> -- =0A>  PGP/OpenPGP/GnuPG encrypted mail pref=
erred in all private=0A> communication.=0A>  Key ID: 0x293C05FD - 997A 4C60=
 CE41 0149 0DB3=A0 9E96=0A> 2F1A D073 293C 05FD=0A>