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
A very interesting point, Chris (and great quotes!).

As a non-PMC 3-years old committer of Hadoop I'd say that the split-line of
'PMC vs. committers' was always a very touchy-feely issue for the community. It
almost felt in times that only those who behave along a "party" lines (in some
definition of a party) are allowed into the sacred temple of PMC.

And I am totally agree with Hen's point: flatter the ratio between the two -
more healthier the community and more vibrant the project. I am coming from a
slightly different perspective here, because I never seen a truly successful
anything that is lead by a central authority.

At any rate, I would like to voice my opinion here and ask not to include me
to the list of initial YARN committers (if the grandfather'ing is accepted
instead of say incubating), because I haven't contributed to the project at
all. I argut that it isn't an honest way of becoming an official project
committer just because you happen to be around of the grandfathering
community.

Just my opinion, non binding apparently.

Cos

 On Thu, Aug 16, 2012 at 08:41PM, Mattmann, Chris A (388J) wrote:
> Hi Eli,
>
> On Aug 16, 2012, at 1:21 PM, Eli Collins wrote:
> >>> [...snip...]
> >>
> >> Keeping code in the same repository with a PMC with different sets of
> >> permissions in that repository *is* the sign of a distinct community.
> >> Doesn't matter if you want the code there together, and allowing patches,
> >> and testing and releasing and whatever. Those are technical issues.
> >> Having code with *different* rules for *the same* community members
> >> is not what I know as "community over code" and the Apache way.
> >> And ultimately it's the reason why this email thread won't die. There's
> >> an elephant in the room here (pun intended).
> >
> > For the PMC the permissions are the same across all the subprojects
> > and it is the same community. The question here is around committers.
>
> Trying to distinguish between the 2 (PMC and committers) leads you to this.
> I guess the Hadoop PMC is interested in the overhead of managing different
> lists of people with different permissions who release different things. That
> seems like an awfully lot of worthless overhead to me, and discussions
> around topics that pretty much wouldn't matter at all if you adopted a flatter
> organizational structure.
>
> See 2 of my favorite quotes from former ASF Director Hen Yandell:
>
> https://twitter.com/flamefew/statuses/36352411593351168
> https://twitter.com/flamefew/statuses/36352484263858176
>
> So whether you are talking about "PMC" or "committers" here, is really
> moot on whether or not this is a community issue. It is. No matter how
> you spin it.
>
> >
> > We already have a working model where the various subprojects have
> > their own committers and people are trusted to commit across project
> > boundaries when it makes sense.
>
> Depends on what you consider to be working. Sure if the Hadoop PMC
> wants to take on the overhead in a centralized fashion that is normally
> distributed amongst projects and their own distinct PMCs that's fine.
> Just doesn't seem to be a scalable solution that's all. Because if you
> look back at most of the Apache projects that did this (e.g., umbrella
> projects) they don't work out. That's b/c having a single PMC that has
> merit across all of the sub-projects usually doesn't work because not
> every person on that PMC rightly should have an equal VOTE on
> those sub-projects that they have no merit in. This can easily be
> the case when you have things like e.g., YARN, or new things come
> along that you guys yourself try and bless instead of just realizing
> that it's a distinct community.
>
>
> > I think everyone is in agreement that
> > yarn, like the other subprojects, will have it's own set of
> > committers, the only open question here as I understand it is whether
> > or not we grandfather in the existing MR committers (since that's
> > where YARN used to live).