+1 on combining committers list for common + hdfs + mapreduce. It is mostly the same set of users who contribute to all three projects.
thanks, dhruba On Mon, Aug 9, 2010 at 11:47 AM, Konstantin Boudnik <[email protected]> wrote: > +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 > -- Connect to me at http://www.facebook.com/dhruba
