On Thu, May 3, 2012 at 12:01 PM, Bruno Mahé <bmahe@...> wrote:
>> As a mentor of the Bigtop project, I don't see it as acceptable for an
>> Apache project to distribute binaries of non-Apache software. If the
>> owners of the Hue project decide to donate it to Apache and it had
>> been released by Apache, then it would be acceptable. I'm strictly -1
>> on releasing any version of Bigtop with Hue or any other non-Apache
>> software as part of the release.
>> -- Owen
> As part of mentoring Apache Bigtop (incubating) project, it would also
> be greatly appreciated if you would explain why this -1.
> Apache Bigtop (incubating) does not and will not include anything that
> does not belong to the Apache Foundation.
> So I am really confused as to why this strong reaction.
The strong reaction is because Roman was proposing a Bigtop release
with rpms and debs for non-Apache projects. That is a non-starter.
Apache will not distribute non-Apache projects. Saying that Bigtop
does not release the projects that it incorporates is not justified
given the fact that Bigtop is putting rpms of each of the incorporated
projects into /dist/incubator/bigtop. The 2.9GB size of the latest
Bigtop release has already caused infrastructure significant
> The convenience artefact may pull Hue in, but this is in no way
> different from Apache Hadoop pulling in Google protocol buffer or Google
> guava. So again, how is this different? Is Apache Hadoop going to
> avandon Google Protocolbuffer?
There is a big difference between referencing external projects that
are required for your project's functionality and incorporating
non-Apache projects into your project and publishing releases of them
using independent artifacts. When the user installs a Hadoop rpm, the
protobuf.jar is there under the hood, but is considered an
implementation detail that is required for Hadoop to run.
I'd complain similarly if Hadoop was downloading protobuf tarballs,
making changes to protobuf, making protobuf rpms with those changes,
and publishing those rpms on Apache's servers.
However, it goes deeper than than that. If the user installs Bigtop's
rpms and hits a bug do they contact Hue or Bigtop? Furthermore, I'm
sure the links that are displayed when you run Bigtop's Hue point off
to Cloudera's bug and support system. That kind of branding is not ok
for an Apache project.
Even with Apache projects, Bigtop may become problematic. Look at the
mess that happened when Lucene made a bugfix release of Apache Commons
CSV. Lucene needed a bugfix release of CSV, didn't wait for CSV to
release, and instead released it themselves. Needless to say Apache
Commons didn't like that result. Bigtop is overriding decisions made
by the upstream projects about things like the way the launching
scripts operate and where the configuration directory is. When asked
to correct it, they complain about compatibility for their users
rather than compatibility for Hadoop's users.