Return-Path: X-Original-To: apmail-hadoop-common-dev-archive@www.apache.org Delivered-To: apmail-hadoop-common-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2318F78AE for ; Wed, 12 Oct 2011 17:26:11 +0000 (UTC) Received: (qmail 67389 invoked by uid 500); 12 Oct 2011 17:26:06 -0000 Delivered-To: apmail-hadoop-common-dev-archive@hadoop.apache.org Received: (qmail 67254 invoked by uid 500); 12 Oct 2011 17:26:06 -0000 Mailing-List: contact common-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-dev@hadoop.apache.org Delivered-To: mailing list common-dev@hadoop.apache.org Received: (qmail 67070 invoked by uid 99); 12 Oct 2011 17:26:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2011 17:26:06 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.210.50] (HELO mail-pz0-f50.google.com) (209.85.210.50) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Oct 2011 17:26:00 +0000 Received: by pzk37 with SMTP id 37so536804pzk.9 for ; Wed, 12 Oct 2011 10:25:39 -0700 (PDT) Received: by 10.68.4.201 with SMTP id m9mr2551350pbm.40.1318440339501; Wed, 12 Oct 2011 10:25:39 -0700 (PDT) Received: from gkesavan.hortonworks.com (host1.hortonworks.com. [70.35.59.2]) by mx.google.com with ESMTPS id v8sm1780730pbf.8.2011.10.12.10.25.37 (version=SSLv3 cipher=OTHER); Wed, 12 Oct 2011 10:25:38 -0700 (PDT) Message-ID: <4E95CD94.1040904@hortonworks.com> Date: Wed, 12 Oct 2011 10:25:40 -0700 From: giridharan kesavan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: hdfs-dev@hadoop.apache.org CC: Eric Yang , mapreduce-dev@hadoop.apache.org, common-dev@hadoop.apache.org Subject: Re: 0.23 & trunk tars, we'll we publishing 1 tar per component or a single tar? What about source tar? References:

In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 for option 4 On 10/12/11 9:50 AM, Eric Yang wrote: > Option #4 is the most practical use case for making a release. For bleeding edge developers, they would prefer to mix and match different version of hdfs and mapreduce. Hence, it may be good to release the single tarball for release, but continue to support component tarballs for developers and rpm/deb packaging. In case, someone wants to run hdfs + hbase, but not mapreduce for specialized application. Component separation tarball should continue to work for rpm/deb packaging. > > regards, > Eric > > On Oct 12, 2011, at 9:30 AM, Prashant Sharma wrote: > >> I support the idea of having 4 as additional option. >> >> On Wed, Oct 12, 2011 at 9:37 PM, Alejandro Abdelnur wrote: >>> Currently common, hdfs and mapred create partial tars which are not usable >>> unless they are stitched together into a single tar. >>> >>> With HADOOP-7642 the stitching happens as part of the build. >>> >>> The build currently produces the following tars: >>> >>> 1* common TAR >>> 2* hdfs (partial) TAR >>> 3* mapreduce (partial) TAR >>> 4* hadoop (full, the stitched one) TAR >>> >>> #1 on its own does not run anything, #2 and #3 on their own don't run. #4 >>> runs hdfs& mapreduce. >>> >>> Questions: >>> >>> Q1. Does it make sense to publish #1, #2& #3? Or #4 is sufficient and you >>> start the services you want (i.e. Hbase would just use HDFS)? >>> >>> Q2. And what about a source TAR, does it make sense to have source TAR per >>> component or a single TAR for the whole? >>> >>> >>> For simplicity (for the build system and for users) I'd prefer a single >>> binary TAR and a single source TAR. >>> >>> Thanks. >>> >>> Alejandro >>> >> >> >> -- >> >> Prashant Sharma >> Pramati Technologies >> Begumpet, Hyderabad. > -- -Giri