Hello, I agree with Tom on this one. Seeding the initial committer list of a split off project with those committers on the previous project is what we did during the Common/HDFS/MR project split, and I see no reason to deviate from that practice in this case.
In matters such as who should be on initial committer lists, when to move folks to emeritus status, etc., I've always been of the opinion that we should err on the side of being overly inclusive. We trust all of our committers to know their limitations, and not make modifications to the code base in areas where they are unfamiliar. If you're concerned with the hypothetical situation that some committer might make hasty changes to an area of YARN that they are unfamiliar with, then that person shouldn't be an MR committer either. The fact that an MR committer has earned our trust in that project indicates to me that they should be similarly trusted in the YARN project. In general, we should want more people, not fewer, who are able to review patches and fix up issues found in YARN/MR/etc. At the very least, if we were not going to seed the initial committer list with those from the MR project, we should have discussed that before creating a separate sub-project for YARN. If that had been a condition of YARN becoming a separate sub-project, I'm not sure I would have supported it. -- Aaron T. Myers Software Engineer, Cloudera On Tue, Aug 14, 2012 at 8:00 PM, Eric Baldeschwieler <eri...@hortonworks.com > wrote: > Hi Tom, > > Speaking as someone who is being excluded from the new list, this seems > fair to me. It seems like you are worrying about a hypothetical. Anyone > who feels they have contributed significantly to YARN need only identify > themselves. Others are welcome to do so and become committers via the > normal process. Seems meritocratic / appropriate. > > E14 > > > > On Jul 26, 2012, at 8:24 PM, Arun C Murthy wrote: > > > As we discussed in the previous thread, I'd like to call a vote to > establish YARN as a sub-project (it's the best *term* we have to describe > it in our current nomenclature) of Apache Hadoop along with Common, HDFS & > MapReduce. > > > > Specifically, > > # Create a separate top-level src folder hadoop-yarn, move it out of > hadoop-mapreduce-project in subversion at hadoop/common/trunk. > > # Create a separate YARN jira project and yarn-dev@ mailing-list. > > # Continue to co-release a single Hadoop release with Common, HDFS, YARN > & MapReduce. > > > > Please vote, the vote will run the normal 7 days. Obviously, I'm +1. > > > > thanks, > > Arun > > > >
