Hi, On Sat, May 5, 2012 at 1:34 AM, Alan Gates <ga...@hortonworks.com> wrote: > My question here was whether this concept of convenience binaries > should extend beyond ASF owned packages. I realize that many existing > convenience binaries contain non-ASF jars, etc. But taking the next > step of explicitly distributing non-ASF binaries on their own concerns me.
The normal guidelines of what kind of third-party bits can be redistributed by Apache projects are in http://www.apache.org/legal/resolved.html. As long as all the components included in a "BigTop x.y" installation meet those guidelines or are system dependencies like "Fedora 16" that don't come form the ASF, then the ASF policy side of things should be fine. A somewhat similar example from another domain is Apache Tika, which binds together a lot of upstream libraries from both within and outside the ASF and makes them available as a single integrated and tested package. AFAIUI the main difference here is that unlike in Tika, BigTop doesn't have a programming API for accessing the included components. Instead, IIUC, the "BigTop API" is a deployment/testing one with stuff like "yum install", etc. Now (again IIUC) the interesting bit is whether it's better for BigTop to be repackaging and -distributing upstream components by itself, or if it would in fact be better for BigTop to simply provide something like "bigtop-x.y.rpm" and "bigtop-x.y.deb" packages that just declare dependencies to specific, integration-tested versions of upstream packages. To do this, BigTop would need to work with the upstream projects to help them produce the appropriate deployment packages as a part of their normal release processes. And BigTop could also team up with Infrastructure to maintain the kind of repository structure and download service expected by deployment tools like yum and apt, a bit like what Maven projects have in https://repository.apache.org/. This is in fact a bit like what Tika has recently been considering (see http://markmail.org/message/wj4xkoax2ojnqlht) with it's upstream components. Instead of repackaging and -distributing them directly as a part of a Tika release, we're looking at ways to add the required extra bits to the upstream releases so that Tika could just consume them as normal dependencies. >> * In that case there might still be a role for BigTop to provide a >> central repository for such easily consumable upstream releases. This >> would be somewhat similar to the discussions that took place a few >> years ago about whether and how the ASF could host something like the >> central Maven repository. > > Do you know what list that discussion took place on and a general time frame? > Reading through that would be very helpful for my thinking on this topic. See January 2007 on board@ and infrastructure@. BR, Jukka Zitting --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
