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 Fri, 13 Jan 2012 15:05:09 GMT
On Fri, Jan 13, 2012 at 9:50 AM, Ross Gardler
<> wrote:
> On 13 January 2012 14:43, Rob Weir <> wrote:
> ...
>> If I were on the IPMC, and AOO came up for graduation, I wouldn't be
>> too concerned out the MPL license category being in SVN, so long as
>> the releases were in policy and so long as the PPMC could demonstrate
>> how they are addressing good practices related to code segregation,
>> etc.
> Can someone please explain why it is necessary to have the code here
> at all? Why is it not pulled from the upstream project?

The particular reasons why this is necessary would be on a
case-by-case basis.  But here is the general reason why it is a good
idea for any 3rd party component:

A fundamental principle of software design:  Never depend on a
component less stable than you.  URL's change.  Projects fold.
Corporations divest from open source projects. Websites get hacked and
source code changed.  If we really want to be able to reliably build
and maintain AOO, and allow downstream providers to do the same, then
we need to have archival copies of all 3rd party components we depend
on (or at least the major ones), and to keep then versioned and
associated with our release branches.

This is the same reason Apache has its own mailing list archive and
its own URL shortener. Having control over these assets, from an
archival standpoint, is critical.  This does not mean that we should
be developing such software at Apache.  It just means that the ability
to maintain this software is only as reliable as our ability to
retrieve any third party components it relies on, regardless of

I don't think the above is a policy question, but a technical one that
each PMC should be evaluating on its own.  OpenOffice, an 11 year old
project, with many years ahead of it, has relevant experience in this
area.  We've already outlived at least one upstream component.

> Ross

View raw message