incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J├╝rgen Schmidt <>
Subject Re: Category-B tarballs in SVN (was Re: External libraries)
Date Fri, 13 Jan 2012 18:43:08 GMT
Am Freitag, 13. Januar 2012 schrieb Rob Weir <>:
> 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.
> 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.

Thanks Rob, that's the mail I needed to finally go in the weekend.


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