Raghu,
Since most of the bugfixes to Pig happen in trunk, I (and several folks that
I know) tend to use pig trunk most often. It would be nice if I picked up
Zebra enhancements along the way, as well.
Since zebra.jar is not included in pig.jar (I hope not), I can still use
stable zebra jar
Milind A Bhandarkar wrote:
Since zebra.jar is not included in pig.jar (I hope not), I can still use
stable zebra jar (binary) with latest pig compiled in trunk.
The problem is that though the current version is expected to be
stable, it would still require some bug fixes. We essentially need
I would recommend that zebra wait for Pig 0.4.0 (a couple of weeks?). A
branch will be created for the 0.4.0 release and zebra will
automatically benefit.
Santhosh
-Original Message-
From: Raghu Angadi [mailto:rang...@yahoo-inc.com]
Sent: Tuesday, August 18, 2009 9:49 AM
To:
Right. I just noticed the mails on Pig.0.4.0. I joined pig-dev list just
yesterday. waiting for 0.4.0 might be good enough if it is just a couple
of weeks. will keep a watch on it.
I think we will wait for a few days and attach any new feature patches
to jiras. Those patches can certainly
I think we are creating unnecessary bureaucratic hurdles here by preventing
contrib project from having a branch. I don't see why zebra has to use pig
release branch, as the new pig release does not include it.
The decisions are supposed to help keeping things open, but this seems to be
forcing
Thanks to the PIG team, The first version of contrib project Zebra
(PIG-833) is committed to PIG trunk.
In short, Zebra is a table storage layer built for use in PIG and other
Hadoop applications.
While we are stabilizing current version V1 in the trunk, we plan to add
more new features
+1
-Original Message-
From: Raghu Angadi [mailto:rang...@yahoo-inc.com]
Sent: Monday, August 17, 2009 4:06 PM
To: pig-dev@hadoop.apache.org
Subject: Proposal to create a branch for contrib project Zebra
Thanks to the PIG team, The first version of contrib project Zebra
(PIG-833) is
My vote is -1
-Original Message-
From: Santhosh Srinivasan
Sent: Monday, August 17, 2009 4:38 PM
To: 'pig-dev@hadoop.apache.org'
Subject: RE: Proposal to create a branch for contrib project Zebra
Is there any precedence for such proposals? I am not comfortable with
extending committer
Is there any precedence for such proposals? I am not comfortable with
extending committer access to contrib teams. I would suggest that Zebra
be made a sub-project of Hadoop and have a life of its own.
Santhosh
-Original Message-
From: Raghu Angadi [mailto:rang...@yahoo-inc.com]
Sent:
Raghu is PMC member and as such already has committer rights to all
subprojects. So we are not breaking any new grounds here. The reasoning
is the same as for creating branches for Pig multiquery work that we did
in Pig.
Olga
-Original Message-
From: Santhosh Srinivasan
+1
On 8/18/09 7:11 AM, Olga Natkovich ol...@yahoo-inc.com wrote:
+1
-Original Message-
From: Raghu Angadi [mailto:rang...@yahoo-inc.com]
Sent: Monday, August 17, 2009 4:06 PM
To: pig-dev@hadoop.apache.org
Subject: Proposal to create a branch for contrib project Zebra
Thanks
IANAC, but my (non-binding) vote is also -1. I think all the improvements
and feature addition to zebra should be available through pig trunk. The
codebase is not big enough to justify creating a branch. If the reason is
Pig's dependence on a checked in hadoop jar, the shims proposal by Dmitry
On Aug 17, 2009, at 4:38 PM, Santhosh Srinivasan wrote:
Is there any precedence for such proposals? I am not comfortable with
extending committer access to contrib teams. I would suggest that
Zebra
be made a sub-project of Hadoop and have a life of its own.
There has been sufficient
That leaves us with contrib committers.
Can you point to earlier email threads that cover the topic of giving
committer access to contrib projects? Specifically, what does it
mean to
award someone committer privileges to a contrib project, what are the
access privileges that come with such
Hi Santosh,
There are two separate things :
(a) voting a contributor as a committer
(b) committing to a contrib project.
(b):
My experience with Hadoop is that Contrib by definition is very
loosely coupled with core. By convention, we as committers to core
(hdfs, mapred, etc) did not have
Raghu Angadi wrote:
Hi Santosh,
There are two separate things :
(a) voting a contributor as a committer
(b) committing to a contrib project.
[...]
Reason for (a) is simple scalability. We can not monitor everything. If
I meant to say Reason for (b) (why contrib commits are treated bit
16 matches
Mail list logo
