hadoop-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: [DISCUSSION] Combine committer lists in Common/HDFS/MapReduce
Date Mon, 09 Aug 2010 18:47:53 GMT
+1 on combining the committer roles in one (as Doug has mentioned elsewhere,
all three are feel like a single project and are released as such, therefore
it doesn't make much sense to split committers). In effect, MR testing that
pulls in "external" HDFS dependencies works as a poor-man integration testing.

-1 on combining the projects back together. While having them separated might
cause an extra maintenance burden, the same separation forces more clean
design decisions. 


On Fri, Aug 06, 2010 at 02:02PM, 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