Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
MapReduce >> mail # dev >> 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?


Copy link to this message
-
Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar?
On 10/12/2011 09:07 AM, Alejandro Abdelnur wrote:
> For simplicity (for the build system and for users) I'd prefer a single
> binary TAR and a single source TAR.

All that is required for a release is a single source TAR.  As an
open-source project our product is source code.  We may also distribute
some derivative binary artifacts as conveniences, but those can be added
to the distribution directory by other committers after the release vote
as desired.

So it's fine if folks want to include, e.g., an HDFS-only binary package
for 64-bit linux that's convenient for sites that only wish to run HBase
and never run mapreduce jobs, but that's not what we should vote on.
Rather voters should evaluate sources.

I am +1 for creating a single source tarball for the entire release and
+0 for creating any number of binary tarballs for various subsets,
platforms, etc.

Doug
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB