On Tue, May 29, 2012 at 8:18 PM, sebb <[email protected]> wrote: > On 30 May 2012 00:50, Rob Weir <[email protected]> wrote: >> On Tue, May 29, 2012 at 7:34 PM, sebb <[email protected]> wrote: >>> On 30 May 2012 00:03, Pedro Giffuni <[email protected]> wrote: >>>> >>>> --- Mar 29/5/12, Rob Weir <[email protected]> ha scritto: >>>> ... >>>> >>>>> > >>>>> > The idea that we have remaining issues with Category-B >>>>> > tarballs in the tree has been around since before the >>>>> > release, and one of our mentors (Ross I recall) did >>>>> > acknowledge my point of view. >>>>> > >>>>> >>>>> Again, I don't see an issue here. But if you feel >>>>> strongly about this you are welcome to copy the >>>>> ext_sources over to Apache Extras and do a >>>>> trivial update of the build >>>>> script. Whatever makes you happy. >>>> >>>> I am busy at the moment, plus doing this will >>>> mean I have to suspend the updates I was working >>>> on. >>>> >>>> I think I will start next week. I will only move >>>> Category-B code and I will disable it from the >>>> buildbots too: it's rather inconvenient to have >>>> the buildbot depend on downloading extra tarballs. >>>> >>>> This is admittedly a stop gap solution to comply >>>> better with the Apache policies, the real fix would >>>> be to work collectively on replacing the code that >>>> can be replaced: >>> >>> Alternatively, it is possible to include cat B [1] dependencies in binary >>> form. >>> Is there any need to include the source? >>> >> >> If the build did not consumer source then we would need to store, in >> SVN, category-b binaries files for each component, in each >> platform/architecture. That would be 4 platforms now, but I'd expect >> that go up to 7 in the near future. > > Surely at least Mozilla Rhino is written in Java, and tar balls are > published in various locations (e.g. Maven Central) suitable for use > as part of a build. >
Maven is a good analogy. We've essentially reinvented Maven, only we did it before Maven did. Although you could argue for Maven for Java dependencies, I'd rather use a single mechanism for all dependencies rather than multiple ones. > If there are other non-Java dependencies that are not available for > all platforms as binaries, then of course the source needs to be > built. > Thus what we have. >> I don't think that solves any real problem. We'd still need access to >> the source to provide urgent security patches, etc. So we're then >> back to the same question: where to store the category-b source >> tarballs? > > If the dependency is provided as a binary by the maintainer, then > surely it is up to them to apply patches and provide patched builds? > In almost all cases the binaries are not provided by the maintainer on the full range of platforms that we support. > Likewise, surely security fixes will be applied by the maintainers to > their source? > To source, but not always to binaries, since they don't typically provide binaries. And not always to older versions of the source distributions. We might be using version N-1 of a component and cannot quickly consume version N of a component in order to meet the urgency of a security fix. So we could need to backport a security patch. In any case, this as all been discussed previously, and the various options have been explored. Surely this is for the project to figure out? If something was truly a question of policy and an important Foundation principle was at stake, it would not vary according to the underlying technology and we would not be discussing the implementation details. If it was a policy issue then we'd be discussing policy and the principles behind the policy. As you know the licensing policy is based on three very simple principles [1]. Do you have any concerns with our meeting these principles? We can discuss configuration management, but the principles at stake are not technological. They are about the obligations of downstream source consumers and whether we give them ample warning and notification about what these obligations are. [1] http://www.apache.org/legal/resolved.html#criteria >> -Rob >> >>> [1] http://www.apache.org/legal/resolved.html#category-b >>> >>>> rhino --> Google V8 >>>> nss --> openssl >>>> Seamonkey --> Mulberry library >>>> >>>> but that doesn't seem to be a priority for 4.0 :( . >>>> >>>> Pedro. >>>>
