+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
pgpNOwhkmYQ8H.pgp
Description: PGP signature
