Mailing-List: contact user-help@giraph.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@giraph.apache.org
Message-ID: <5168A84A.6070904@apache.org>
Date: Fri, 12 Apr 2013 17:35:22 -0700
From: Avery Ching <aching@apache.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: user@giraph.apache.org
CC: Roman Shaposhnik <rvs@apache.org>, dev@giraph.apache.org
Subject: Re: [VOTE] Release Giraph 1.0 (rc0)
References: <51689132.8010303@apache.org>
 <CA+ULb+t9v8r-G8P7tAdAjyQthq8mHWqv=w1LW+7STx86ZdZYOQ@mail.gmail.com>
In-Reply-To: 
 <CA+ULb+t9v8r-G8P7tAdAjyQthq8mHWqv=w1LW+7STx86ZdZYOQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Thanks Roman for the comments.  I'll fix them and make a RC1 some time 
tonight.
Regarding 3) and 4), I'd prefer to make a 1.1 release since we don't 
know exactly when 2.0.4 comes out.  After going through the process 
once, it's not too hard to do it again. =)

Avery


On 4/12/13 5:30 PM, Roman Shaposhnik wrote:
> On Fri, Apr 12, 2013 at 3:56 PM, Avery Ching <aching@apache.org> wrote:
>> Fellow Giraphers,
>>
>> We have a our first release candidate since graduating from incubation.
>> This is a source release, primarily due to the different versions of Hadoop
>> we support with munge (similar to the 0.1 release).  Since 0.1, we've made A
>> TON of progress on overall performance, optimizing memory use, split
>> vertex/edge inputs, easy interoperability with Apache Hive, and a bunch of
>> other areas.  In many ways, this is an almost totally different codebase.
>> Thanks everyone for your hard work!
> Indeed this is a VERY impressive amount of new functionality! Kudos!
>
> Here's my feedback so far (before I pull the bits into Bigtop for more
> integration testing). I hope to convince you guys that we may need
> to spin additional RC (#1-#3 -- with #4 bein a subject of a special plea):
>      1. tarball contains the .git repo
>      2. tarball was generated in such a way that make Linux Ubuntu
>      tar spew out tons of warnings
>      3. YARN profile is broken (GIRAPH-627 -- patch attached).
>      4. YARN profile is broken when compiled against hadoop-2.0.4
>      (GIRAPH-629 -- working on a patch)
>
> And here we come to me pleading with Giraph community (on
> behalf of Bigtop and Hadoop ones ;-)). I know that what I'm about
> to ask is typically considered a sort of a 'bad taste' in ASF but
> here I go: given the incompatibility between 2.0.3-alpha and
> 2.0.4-alpha is there any chance we can delay Griaph 1.0 to be
> full compatible with 2.0.4? The 2.0.4 release is suppose to come
> out at the end of next week and I can volunteer to make Giraph
> compatible with it.
>
> Hadoop 2.0.4-alpha is kind of a big deal because if everything
> goes according to a plan 2.0.4 will be a stepping stone towards
> the first Hadoop 2.X beta (and eventually GA). It is way more
> important to be compatible with it in my opinion.
>
> I guess, if you guys really want to save a couple of days an
> alternative could be to agree on Giraph 1.0.1 within a couple of weeks.
> That of course, will require cycles from whoever will be the 1.0.1.
>
> Finally, if we do spin a new RC, could we please follow an established
> ASF model where the tarball itself gets a name of the final artifact
> (in our case giraph-1.0.tar.gz) but the subdirectory name reflects the
> name of the RC. Here's an example of Hadoop 2.0.4 RC that the
> Hadoop community is voting on right now:
>      http://people.apache.org/~acmurthy/hadoop-2.0.4-alpha-rc2/
> as you can see the name of the artifact looks exactly  like the
> final product of the release.
>
> Thanks,
> Roman.