Hi Alan!
On Thu, May 3, 2012 at 11:46 AM, Alan Gates <ga...@hortonworks.com> wrote:
> 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".
I think what needs to be kept in mind is that at the end of the day,
Apache Foundation Projects release source code. Everything else
is inconsequential binary artifacts.
For some projects binary artifacts hardly matter (e.g. Apache HTTPD
server), for some others they get a lot of attention and consume
a lot of precious Apache INFRA bandwidth (e.g. Apache OpenOffice
[incubating], Apache Bigtop [incubating]).
Yet, I would dare to say that from ASF perspective even OpenOffice
is all about source code releases.
>From that perspective, Bigtop's ultimate goal is to be an ASF project that
provides an integration, validation and deployment framework for
Bigdata management stacks based on Apache Hadoop. In that respect
Bigtop is very close to OpenEmbedded/OpenWRT projects in how
they provide you with a tools to create custom linux distributions.
> 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?
Including support for them into the framework -- sure. Why not? If folks
find it useful to manage all of the above via the Bigtop framework -- where's
harm in that? As long as the license is compatible with APL -- my answer
would be a positive one. In fact, if you look closely you'll see that Bigtop
already supports Kerberos, MySQL and hopefully will soon support
Ganglia via Puppet code.
Now, if you're asking a question of whether we should be including all these
dependencies into the binary convenience artifacts that we publish, then
my answer is predicated on two things:
#1 I would like to steer clear from distributing anything that is
not APL licensed
using Apache infrastructure.
#2 I would like to get an explicit Apache INFRA team blessing that they are
comfortable with the storage and bandwidth requirements.
> 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.
I don't think I agree with your line of thought as far as "known
release process"
is concerned. The same argument could be applied to every project that
depends on Guava -- it is something we know nothing about, yet we're perefctly
willing to make it part of the binary artifacts for Hadoop and quite a few other
projects.
I do, however, agree with your concern as far as "distribution point"
goes. Indeed,
it is pretty outlandish to imagine somebody downloading Hadoop binary artifacts
just to extract Guava and use it from there. Thus, by any stretch of
imagination,
Hadoop is not a distribution point for Guava, but if we start
packaging it in Bigtop's
binary convenience artifact -- we will be. This is a valid concern.
Now, personally, I think that this is much more a concern for the
project itself,
rather that Apache, but I'd be curious to hear what other think about it.
> 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.
Good point. However, as a mentee I expect the level of discourse to be
appropriate.
I have no problem with your reply and careful explanation of the issues at hand.
In fact, I welcome it very much. Owen's reply lacked any of the nuance and felt
as a "my way or the highway" kind of -1. I don't think there's
anything to be learned
from that type of mentoring approach.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
