incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Category-B tarballs in SVN (was Re: External libraries)
Date Sun, 15 Jan 2012 03:19:53 GMT
On Sat, Jan 14, 2012 at 9:01 PM, Ross Gardler
<> wrote:
> 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.

The point Pedro brought up, and the point you are trying to argue
against, is storage of MPL modules in SVN.  That is what I am arguing

> 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).

You say, "no need".  I say "engineering prudence".  This is not a
policy question.

> 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.

So you are arguing that there may be reasons for storing MPL code in SVN?

> 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.

You say, "no need".  I say "engineering prudence".  This is not a
policy question.

> 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.

You say, "unworkable".  I say "engineering prudence".  This is not a
policy question.

> 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.

We avoid changing this code in other ways.  Maybe this was not
clear,or you did not read what was said previously.  We do not store
individual source files in SVN, as we would the core AOO code.  We
store tarballs, i.e., archived bundles of the complete module, with a
name that includes an MD5 hash of the source code.  This prevents
anyone on this project from changing that modules without breaking the
hash.  We're doing only as little as is necessary to ensure the the
3rd party module is properly archived, as a service to the continuity
of this project and to downstream consumers.

Perhaps you underestimate the importance of this?  This might be from
lack of experience with software products of comparable size and
complexity.  AOO is unlike anything else you have at Apache, in terms
of size and number of modules we integrate with.  This is because
unlike almost every other project, we are an end-user GUI application
and need to integrate broadly with the platform at many levels, from
install/uninstall, to address books, to crypto, to clipboard, to
platform specific UI libraries, etc.  The typical Apache product does
only a small percentage of this.

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

View raw message