Am Freitag, 13. Januar 2012 schrieb Rob Weir <robw...@apache.org>: > On Fri, Jan 13, 2012 at 12:50 PM, Ross Gardler > <rgard...@opendirective.com> wrote: >> On 13 January 2012 17:38, Rob Weir <robw...@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. >
Thanks Rob, that's the mail I needed to finally go in the weekend. Juergen
