On Thu, Aug 16, 2012 at 11:27 AM, Suresh Srinivas <sur...@hortonworks.com>wrote:
> Some have voiced opinion that they would not have supported YARN becoming a > sub-project if they knew committer list is going to change. YARN was voted > as a sub-project on the merit of it being a distinct functionality from > rest of existing Hadoop. Your vote for YARN becoming a sub-project should > have nothing to do with the commiter list. > Take a look at the original DISCUSS thread on this subject. In it, Arun attempted to enumerate all of the changes that this proposal would include. Nowhere in it did it say that the committer list of YARN would be pared down in an exclusive fashion. Given that this is an issue for some, I think it should have been mentioned. > > A team of people have worked for a long time (more than 1.5 years) on YARN. > They understand the code and the design context well enough to be > committers. I am not sure how having a long inclusive list of committers > helps YARN. Do we expect the folks who have not contributed to YARN and > might not understand YARN code well enough to do a good job as committers? > That is the reason why I do not mind not being included in the list of > committers. Further Arun has been more inclusive by incorporating Tom's > feedback. > How will having an inclusive list of grandfathered-in MR committers hurt YARN? The only reason I've heard so far is the concern that someone may make changes to an area of the codebase that they're not very familiar with. In my experience, this has never been a problem in the Hadoop community, so I don't understand why we're trying to account for this hypothetical problematic situation. > > We, as the Hadoop PMC, decided to vote committers to sub-projects instead > of whole of Hadoop. To ensure someone who works heavily on one sub-project > from committing code the core parts of other sub-projects. Why do we want > to make an exception for YARN? > No one is suggesting that the committer lists should be permanently the same. The only question is the composition of the initial YARN committer list. When we split the project into Common, HDFS, and MR, we grandfathered in all existing committers to be committers on those subprojects. I don't know why we should make an exception for YARN in this respect. I think Eli summed up the issue very well: "No reason moving the yarn directory up one level in the repo means we need to revisit all this now. Let's get back to work and revisit this at TLP time." -- Aaron T. Myers Software Engineer, Cloudera
