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 <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.
