Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop, mail # general - [VOTE] - Establish YARN as a sub-project of Apache Hadoop


Copy link to this message
-
Re: [VOTE] - Establish YARN as a sub-project of Apache Hadoop
Aaron T. Myers 2012-08-16, 20:38
On Thu, Aug 16, 2012 at 11:27 AM, Suresh Srinivas <[EMAIL PROTECTED]>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