There are two separate things :
(a) voting a contributor as a committer
(b) committing to a contrib project.
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 to monitor changes to contrib as
thoroughly as we would monitor core changes. It is the responsibility of
contrib developers to make sure they are not breaking builds etc.
Contrib changes get reviewed by people interested in the project.
Voting takes place when a contributor is being blessed as a committer.
It involves some legal stuff as well. Although a committer has
permissions to commit to any part of a project, it is expected that they
don't misuse it. e.g. if I have a patch for core Map/Reduce, I would
certainly wait for a regular MR contributor to review it and possibly
commit it. It does not matter how many patches I might have contributed
to say HDFS.
Reason for (a) is simple scalability. We can not monitor everything. If
you or another PIG developer volunteers to commit zebra patches, we are
more than happy to let you do it. Please let us know. Or at any stage,
if you feel we may be violating normal conventions (like breaking builds
or committing some PIG changes).. please raise the issue. We have not
seen serious problems in this regd with any other project, I think we
should get benefit or doubt.
I have not addressed the reason for a new branch here. will pitch for it
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.
From: Raghu Angadi [mailto:rang...@yahoo-inc.com]
Sent: Monday, August 17, 2009 4:06 PM
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 committed to PIG trunk.
In short, Zebra is a table storage layer built for use in PIG and other
While we are stabilizing current version V1 in the trunk, we plan to add
more new features to it. We would like to create an svn branch for the
new features. We will be responsible for managing zebra in PIG trunk and
in the new branch. We will merge the branch when it is ready. We expect
the changes to affect only 'contrib/zebra' directory.
As a regular contributor to Hadoop, I will be the initial committer for
Zebra. As more patches are contributed by other Zebra developers, there
might be more commiters added through normal Hadoop/Apache procedure.
I would like to create a branch called 'zebra-v2' with approval from PIG