hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nigel Daley <nda...@mac.com>
Subject Re: [DISCUSSION] Combine committer lists in Common/HDFS/MapReduce
Date Wed, 11 Aug 2010 04:02:54 GMT
+1 on merging the committer lists for now.  I think separating them was trying to solve for
problems that we don't actually have in our community.  We can always separate them again
later if needed.


On Aug 6, 2010, at 2:02 PM, Chris Douglas wrote:

> Hadoop developers tend to specialize in either HDFS or MapReduce, but
> given that:
> 0) Granting karma to Common is routine for a committer in either
> space; there are no Common-only committers
> 1) The majority of committers have been grandfathered into committer
> roles in all three projects
> 2) Many patches to Common require corresponding commits to both HDFS
> and MapReduce
> 3) Review-then-commit is usually sufficient notice for interested
> parties to comment
> 4) There have been few problems with committers pushing in patches
> without consulting someone more directly involved
> 5) Everyone on the PMC gets commit rights to all subprojects, anyway
> Perhaps it would make sense to give up on separate committer roles
> until the projects are separate TLPs.
> On the other hand:
> 0) Nobody has been independently added to both HDFS and MapReduce
> since the projects were separated
> 1) It could exacerbate the focus on MapReduce in HDFS, at the expense
> of other projects (like HBase).
> 2) HDFS and MapReduce are mostly independent communities and
> codebases; expertise in one does not imply fluency in the other
> 3) Granting veto power across projects can lead to deadlock despite
> consensus within that community
> 4) TLP status for either project may require untangling HDFS/MR roles
> that could be distinguished now
> Personally, I'm in favor of combining the roles. I trust all six of
> the committers made since the project split no less than those made
> earlier. Further, version control is sufficient for recovering from
> most, foreseeable issues. I have some concerns about "harmless"
> commits pushed through without an audit by the subproject's
> maintainers (a few in recent memory caused downtime in Y! clusters),
> but combining the roles seems like a worthwhile experiment.
> Thoughts? -C

View raw message