Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAKQbXgC5Dwaa9wLc5uXjEc=Vw_xxJ-5XeNnSY5cCuiDrAmsXrg@mail.gmail.com>
References: <1326466786.35062.YahooMailNeo@web160902.mail.bf1.yahoo.com>
	<1326467323.8801.YahooMailClassic@web113520.mail.gq1.yahoo.com>
	<1326467553.12721.YahooMailNeo@web160906.mail.bf1.yahoo.com>
	<CAKQbXgBu9sJ5iwqKpcq9YKThrDVETapqt96Qdn7bc=dhhsrdzQ@mail.gmail.com>
	<4F105583.7080302@a-w-f.de>
	<CAKQbXgD65GQOMJZxHDtmpTbKbfT7s86E+P_d4=DpN4zykCZtPA@mail.gmail.com>
	<CAP-ksog4TGRj7iFMYa3nueVZjUtCAzH4JCRVM_O-brxacNV_OQ@mail.gmail.com>
	<CAKQbXgAE3EOEmpwQEjS=NTxAtPT6qJ0fEx_XQM5ATHPOmy5qog@mail.gmail.com>
	<CAP-ksojgo1werGZ9oW-3-j1GWZ9Y8x3N78MdHCruURwzc6xJ=w@mail.gmail.com>
	<CAKQbXgC5Dwaa9wLc5uXjEc=Vw_xxJ-5XeNnSY5cCuiDrAmsXrg@mail.gmail.com>
Date: Fri, 13 Jan 2012 13:36:32 -0500
Message-ID: 
 <CAP-ksojG7fKDWL6GzdrLAz3WFe1HxSFSm+D0t0z-ojPpKSkw=Q@mail.gmail.com>
Subject: Re: Category-B tarballs in SVN (was Re: External libraries)
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8

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.

Consider:

AOO has a dependency on component X.  Never mind the license.  It
could be anything. We have a dependency on X, specifically version 1.0
of X.  We, in the role of an integrator, write our code to integrate
with X, version 1.0.

We then release, it gets widely adopted.  Time passes.

The maintainers of X release version 1.1, with minor feature changes.
Then they release version 1.2 with minor feature changes.  AOO has no
releases in the interim, so we're still dependent on X 1.0.

Many things could go wrong at this point.  For example, a critical
security flaw is found in component X.  The X project quickly release
a new patched version, X 1.2.1 to fix the problem, and releases a
package for that, source and binaries.  For sake of argument say they
do not patch versions 1.0 and 1.1.

What do we do then?

We could try to upgrade to version 1.2.1 of their component.  It might
be possible.  We might hope it is possible.  But it might not work.
It could fail for any number of reasons. Time is ticking.  Our users
are at risk.

What do we do?

Well, obviously, we can apply the patch from 1.2.1 to 1.0 and fix the
flaw in a way that works with our code and we get that new AOO out to
users quickly. And at the same time we make available our patched 1.0
available to the X project if they will host it.  If not we make it
available to downstream consumers, as courtesy, but not as an Apache
release.   And then we make an issue in Bugzilla to investigate more
thoroughly how to upgrade to 1.2.1 in the future.

It is not pretty, but prettiness is not a necessity either.  The whole
OSS universe does not march lock step on the same release schedule.
We're not working with Legos.  Things don't always just fit.  We need
to deal with the messiness of that reality.  And obviously do it
within policy.

It could easily be every worse than that.  Suppose, hypothetically,
that we could upgrade our code to X 1.2.1, that it was not
impractical.  But we might still have another dependency, on component
Y that also has its own dependency on X 1.0 and which does not work
with X 1.2.1.

Being an integrator of 3rd party components, regardless of license, is
complex.  You can get all sorts of interactions like this.

What we need to do is get away from false alternatives, that either we
have no category-b code in SVN, or we are subverting ASF policy and
running stealth copyleft development efforts under the noses of the
IPMC.  There is plenty in the middle, including the prudent archiving
of source code for 3rd party dependencies **regardless of license**
and using them, in full conformance with Apache release policies,  in
order best to serve our users and downstream consumers.

None of this would be necessary if there was some master OSS source
code archive that was guaranteed to be as reliable and stable and
secure and independent as Apache's SVN is.  If such an alternative
server existed, then we'd just use that.  But one does not exist.


-Rob

> Ross