The graduation requirements say 

"The project is considered to have a diverse community when it is not highly 
dependent on any single contributor (there are at least 3 legally independent 
committers and there is no single company or entity that is vital to the 
success of the project). Basically this means that when a project mostly 
consists of contributors from one company, this is a sign of not being diverse 
enough.".

This doesn't specify a hard number. In fact, Roy responded to this thread 
saying he doesn't believe there even is a diversity requirement  -

"There is no diversity requirement for graduating from the incubator. In many 
ways, incubation hinders community growth. The requirement is that the project 
makes decisions as an Apache project, not in private, which is harder to get 
used to doing if a lot of people share the same office."

So I am left a bit confused. If I go by the what the graduation page says 
literally, then all the statistics that have been generated would seem to show 
that Cloudera is vital to the success of the project. Although Arvind is a bit 
of the driving force, I'm sure if something terrible were to happen to him 
Cloudera would insure his energy was replaced. However, if something terrible 
happened to Cloudera I suspect we would have several Apache projects in 
trouble, not just Flume.

While I clearly don't like some of the ways the project has chosen to organize 
itself, all those decisions were done properly and in public. Again, while I 
don't like that little discussion happens on the dev list, it does happen in 
Jira issues and in the review board, all of which is routed to the dev list, so 
again, most, if not all, of the development is done in public.

So my answer to the question is really that I am finding it hard to reconcile 
whether we actually have or should have a diversity requirement. From what I've 
been told privately Flume would certainly not be the first project to graduate 
from the incubator in a similar situation. 

The other thing I find interesting is that I am also the only non-Cloudera 
mentor on the project. I find it a bit odd that while the incubator has the 
requirement for graduation it doesn't have any such requirement for a codling's 
mentors.  That said, IMO every one of the mentors on the project has been doing 
a good job.

One other disclaimer. My employer is a customer of Cloudera specifically for 
paid support for Flume, so I also have a vested interest in seeing both the 
project and Cloudera succeed.  However, with regards to Flume's graduation, I 
haven't even discussed this issue with anyone in by $dayjob.

So again - if the basis we are to use is whether a single company or entity is 
vital to a project then I don't believe Flume is quite there. OTOH I am not 
completely necessary that that is vital for graduation, in which case the 
section in the graduation requirements needs to be changed. So at this point 
the best I can do is say I'm not really sure how to vote.

Ralph





On Jun 5, 2012, at 6:49 AM, Alan Gates wrote:

> 
> On Jun 5, 2012, at 2:19 PM, Marvin Humphrey wrote:
> 
>> On Sat, May 26, 2012 at 11:44 PM, Ralph Goers
>> <ralph.go...@dslextreme.com> wrote:
>>> Another way of  looking at these same statistics:
>>> Cloudera - 217
>>> Other - 16
>>> 
>>> That means Cloudera is responsible for over 93% of the Jira issues.  It is
>>> great that Cloudera is doing so much work but those stats hardly prove
>>> diversity.
>> 
>> I was surprised to see the IPMC Flume graduation VOTE today -- I don't recall
>> seeing another situation like it in the last couple years, where the 
>> community
>> graduation VOTE was contended.
>> 
>> I checked the Flume dev list archives and I don't see a message from Ralph
>> indicating that he thinks the latest measures address the concerns that have
>> been raised.
>> 
> 
> Agreed.  It's hard to vote for graduation for a podling when one of the 
> mentors feels strongly that the podling is not ready.
> 
> Alan.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Reply via email to