incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver-Rainer Wittmann <orwittm...@googlemail.com>
Subject handling of ext_sources - Juergen's suggestion [was: Re: A systematic approach to IP review?]
Date Tue, 20 Sep 2011 13:33:15 GMT
Hi,

On 20.09.2011 14:37, Jürgen Schmidt wrote:
> On Mon, Sep 19, 2011 at 1:59 PM, Rob Weir<robweir@apache.org>  wrote:
>
>> 2011/9/19 Jürgen Schmidt<jogischmidt@googlemail.com>:
>>> On Mon, Sep 19, 2011 at 2:27 AM, Rob Weir<robweir@apache.org>  wrote:
>>>
>>>> ...
>>>>
>>>> Suggestions:
>>>>
>>>> 1) We need to get all files needed for the build into SVN.  Right now
>>>> there are some that are copied down from the OpenOffice.org website
>>>> during the build's bootstrap process.   Until we get the files all in
>>>> one place it is hard to get a comprehensive view of our dependencies.
>>>>
>>>
>>> do you mean to check in the files under ext_source into svn and remove it
>>> later on when we have cleaned up the code. Or do you mean to put it
>>> somehwere on apache extras?
>>> I would prefer to save these binary files under apache extra if possible.
>>>
>>
>>
>> Why not just keep in in SVN?   Moving things to Apache-Extras does not
>> help us with the IP review.   In other words, if we have a dependency
>> on a OSS module that has an incompatible license, then moving that
>> module to Apache Extras does not make that dependency go away.  We
>> still need to understand the nature of the dependency: a build tool, a
>> dynamic runtime dependency, a statically linked library, an optional
>> extensions, a necessary core module.
>>
>> If we find out, for example, that something in ext-sources is only
>> used as a build tool, and is not part of the release, then there is
>> nothing that prevents us from hosting it in SVN.   But if something is
>> a necessary library and it is under GPL, then this is a problem even
>> if we store it on Apache-Extras,
>>
>> i am not really happy with all the binaries in the trunk tree because of
> the large binary blobs and i don't expect too many changes of these
> dependencies. And i would like to avoid to check them out every time.
>
> What do others think about a structure where we have "ext_sources" besides
> "trunk".
>
> incubator/ooo/trunk
> incubator/ooo/ext_source
> ...
>

I like this idea.

 From a developer point of view I only have to checkout "ext_sources" 
once and reference it from all my "trunks" using the already existing 
configure-switch 'with-external-tar="<path to ext_sources>"'

Best regards, Oliver.

Mime
View raw message