incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: Category-B tarballs in SVN (was Re: External libraries)
Date Sun, 15 Jan 2012 02:01:36 GMT
On 13 January 2012 18:36, Rob Weir <> wrote:
> On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler
> <> wrote:
>> On 13 January 2012 17:38, Rob Weir <> wrote:
>>> You are trying to argue the necessity point.
>> I'm not arguing any point. I'm asking questions so that I might
>> understand what the sticking point is.
> OK.  You'll understand this better if you think of it as a
> configuration management question rather than a question of necessity.

Thank you Rob. Of course this is well understood in a general context.
However, earlier in this thread I was informed that we were not
talking about situations where the code had been modified. I'm not
clear whether we are talking about hypothetical or real situations
here. There seems to be many contradictions in this thread.

To be absolutely clear about my own position in the general context:

If the third party code is available elsewhere then there is no need
to hold it here in AOO (if there is reason to believe the third party
host is at risk that is an edge case).

If third party code needs modification and those modifications have
been contributed to the upstream project but not yet included there
then those patches need to be stored here.

I realise that some want to store the full code here, I don't see the
need myself. In the past I've always maintained change sets and
checked out source and applied patches in the build scripts. I've
found that this encourages people to work upstream to get the patches
included. There is some short term pain for this, but in my experience
it is for long term gain. However, I do accept that this doesn't
always work out.

Where the AOO project feels this approach is unworkable I believe that
a case for hosting source tarballs should be made to the legal team as
I have tried to communicate earlier in this thread.

What I, and I guess many other ASF Members, will want to avoid is to
make it easier to modify code and archive it here as a fork than it is
to work at getting the patches committed upstream.

In the meantime Pedro has made a suggestion that he feels will allow
the project to move forwards.


View raw message