incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: Category-B tarballs in SVN (was Re: External libraries)
Date Sun, 15 Jan 2012 09:33:14 GMT
Jeez Rob,

I'm tired of this. I am trying to put a full stop at the end of this.

I say again.

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

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

My mail acknowledged that I understand people here feel that a case can be
made.  I am not arguing fire our against the case. I am communicating
*again* that this is an edge case with respect to existing ASF policy and I
am not the person to make a final decision on this.

Why you are still trying to argue with me? Either make the case our get on
with an interim solution. There is nothing more that can be productively
discussed about policy here.

Sent from my mobile device, please forgive errors and brevity.
On Jan 15, 2012 3:20 AM, "Rob Weir" <robweir@apache.org> wrote:

> On Sat, Jan 14, 2012 at 9:01 PM, Ross Gardler
> <rgardler@opendirective.com> wrote:
> > On 13 January 2012 18:36, Rob Weir <robweir@apache.org> wrote:
> >> On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler
> >> <rgardler@opendirective.com> wrote:
> >>> On 13 January 2012 17:38, Rob Weir <robweir@apache.org> 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
> for.
>
> > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message