+1 to having a single committer list for Common, HDFS, and MapReduce. The projects are currently closely aligned and there have been cases where a committer couldn't commit what was logically a single patch because it was split between Common and MapReduce.
I think we should make this change regardless of whether we ultimately split the projects into TLPs, we merge them back into a single project, or we keep them as three subprojects within the Hadoop TLP (as they are now). I would also suggest that the question of what to do about the project split, although related, probably deserves a separate discussion. Tom On Fri, Aug 6, 2010 at 2:02 PM, Chris Douglas <[email protected]> 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 >
