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. 

Cos

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

Mime
View raw message