On 05/03/2012 11:46 AM, Alan Gates wrote: > Roman, > > I see your point that many Apache projects include non-Apache code in their > binary distributions. But there is a distinction here. In the case of > Hadoop and other projects, they bring things such Guava along because they > need them, not for the express purpose of distributing those artifacts. > Bigtop, by its nature, is different because it provides artifacts for users > to download regardless of what other components they need. It is the > difference between "we include this because we need it" and "we include this > because you might want it". > > My concern is that this is a slippery slope. There are lots of other things > people use with Hadoop (Ganglia for monitoring, Postgres for their Hive > metastore, Cascading, etc.). Would we want Bigtop distributing those? This > would consume a lot of Apache resources to host these things on the download > servers. > > Additionally, we need to think about maintaining Apache's brand. When we > redistribute Apache binaries, we know those have gone through an established > release process. With non-Apache binaries, even those that are APL, we know > nothing of their releases processes, code quality, etc. I do not mean this > as a slight to Hue nor any of the projects mentioned above. But if we let > one in we will have to let others in. Again this is important because we > would be opening ourselves up as a distribution point for those projects > independent of their usage in other Apache projects. > > By drawing the line at distributing only Apache projects we protect Apache > both in terms of server resource usage and in branding. > > As Bruno pointed out in the thread on bigtop-dev > (http://mail-archives.apache.org/mod_mbox/incubator-bigtop-dev/201205.mbox/%3C4F9F4F6C.4000404%40apache.org%3E > ) this does limit Bigtop, so I understand the motivation to do it. But > before we take this step it merits discussion in the community. > > Finally, a comment on the role of mentors. You were concerned that Owen was > vetoing this for non-technical reasons. Your mentors are not here to guide > the project just, or even primarily, technically. We are here to help the > project learn the Apache way. It is perfectly legitimate, even expected, for > a mentor to raise non-techincal concerns such as these. > > Alan. >
Apache Bigtop (incubating) releases don't distribute any binary. They only contain Apache Bigtop (incubating) source code. Convenience binaries are just convenience as far as I understand. So from what you are saying, your issues have nothing to do with Apache Bigtop (incubating) releases, but the convenience binaries. Therefore I don't see the need to suddenly -1 releases of Apache Bigtop (incubating). Given that we already have to host our own build machines because the Apache infrastructure is not suited to this sort of work, we could also host the artefacts on our jenkins instance and save them some burded? But even though, this is for a discussion with Apache Infrastructure. And also I wouldn't see any point in distributing Ganglia or Postgres, even though I see your point. Or we could restrict the convenience binaries to be just of those projects belonging to the Apache Foundation. So it would not limit the scope and abilities of Apache Bigtop (incubating) so much. Regarding the fact we don't consider these as dependencies, I disagree. Apache Bigtop (incubating) is an integration point for any project related to Apache Hadoop. So we produce recipes for a consistent stack. So of course convenience binaries will include packages, but Apache Bigtop (incubating) goes way beyond that. Anyone can build their own stack, with their own version on their favorite GNU/Linux distribution. There are all sorts of tests (integration, performance, package), recipes to build your own virtual machine, bootable image and even deployment recipes for puppet. So packages are not an end but only a part of this story. The end product is a deployable stack of Apache Hadoop ecosystem and these projects related to Apache Hadoop are just used as dependencies. Thanks, Bruno --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
