incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pedro F. Giffuni" <giffu...@tutopia.com>
Subject Re: [code][repo] Integration of CWSs
Date Tue, 06 Sep 2011 18:23:43 GMT
Hello Eike;

From what I discussed with Rob there is no objection
on his side wrt to integrating the CWS'.

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