On Fri, Apr 12, 2013 at 3:56 PM, Avery Ching <ach...@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.