incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: Flume Graduation (was Re: June reports in two weeks)
Date Thu, 24 May 2012 07:19:45 GMT
The ONLY issue I see for Flume to graduate is diversity.  No one will convince me that the
current makeup constitutes diversity of any kind.  

Perhaps I shouldn't have brought up the mailing list issues as that was only meant in the
spirit of trying to offer some advice on how more diversity could be achieved.  Flume is really
the only community I participate in that contains Cloudera employees so I do find myself wondering
if the way the project is run is because that is the way all projects with a large number
of Cloudera employees are run.  That might make all of those participants comfortable but
might create a barrier to others.

In any case - I'm not insisting that the way the project is run needs to change. I'm simply
saying I cannot support graduation with the current makeup of the committers and PMC. I don't
have a hard and fast ratio - gaining 10 new unaffiliated committers who don't do much isn't
nearly as good as 2 or 3 who are very active.  Ultimately the project needs to figure out
how to solve this.


On May 23, 2012, at 11:48 PM, Eric Sammer wrote:

> I appreciate your position Ralph and I don't want anyone to feel like they
> can't contribute. As we've talked about before, we've been quick to nurture
> new contributors to committer status successfully in a few cases. It's true
> that some of the more active committers are from Cloudera, but it's not to
> the exclusion of anyone. Others aren't from Cloudera. Those of us that work
> together are also very strict about abiding to the "if it's not on the
> mailing list, it didn't happen" rule (where "mailing list" can mean JIRA or
> other ASF infrastructure as well).
> I'm happy to take your guidance as a mentor, but you also need to
> understand that some of the ways the Flume project has elected to operate
> are just a matter of taste. They were proposed, discussed, voted on (and
> not as a block by Cloudera employees, IIRC - pretty sure I was -0), and put
> in place and do not violate the Apache Way (like RTC vs. CTR). They aren't
> unheard of and they do not work to the exclusion of contributors (RTC, for
> instance, only impacts committers). I think the vote that was started was
> only to gauge community opinion as a first step (although I'm not
> completely well versed in the graduation process, to be honest).
> If there are concrete things we can do to improve diversity, in your
> opinion, I am extremely open to hearing them. We already do many of the
> (excellent) things listed earlier in the thread. JIRA noise withstanding
> (again, it's a matter of taste - I use the email frequently as I find
> trolling through JIRA slow) I'm definitely open to ideas. Of course, if
> Flume simply needs to remain in the incubator until we develop greater
> diversity, that's fine too. If we're not ready, we're just not ready.
> On Wed, May 23, 2012 at 11:18 PM, Ralph Goers <>wrote:
>> On May 23, 2012, at 10:48 PM, Patrick Hunt wrote:
>>> On Wed, May 23, 2012 at 10:36 PM, Ralph Goers
>>> <> wrote:
>>>> On May 23, 2012, at 10:15 PM, Benson Margulies wrote:
>>>>> On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
>>>>> <> wrote:
>>>>>> Right after I read Jukka's email that started this thread and I
>> posted my reply and discovered to my shock that they had started a
>> graduation vote.  I am shocked because I have pointed out repeatedly the
>> project's complete lack of diversity.  Virtually all the active PMC members
>> and committers work for the same employer.  I have told them several times
>> that I would actually like to participate in the project but the way the
>> project works is very different then every other project I am involved with
>> at the ASF and the barriers to figure out what is actually going on is very
>> high. Almost nothing is discussed directly on the dev list - it is all done
>> through Jira issues or the Review tool.  While all the Jira issue updates
>> and reviews are sent to the dev list most of that is just noise.  Feel free
>> to review the dev list archives to see what I am talking about.
>>>>> I don't follow flume, but I'd propose to soften your objection only
>>>>> slightly. I've met other groups of people who like a JIRA centric view
>>>>> of the world. I suspect that if they did a bunch of other good things
>>>>> called out below, you or others would find the JIRA business
>>>>> digestible. Also, on the other hand, I fear that the co-employed
>>>>> contributors are collaborating in the hallway, and the lack of the
>>>>> context in JIRA or on the list is contributing to the problem.
>>>> I have reason to doubt the collaboration in the hallway aspect and I
>> certainly do not doubt everyone's good intent.  I'm not objecting to the
>> collaboration style as an issue preventing graduation. I'm just saying I
>> find it difficult to participate with that style and that simply makes me
>> wonder if that is making it harder to attract new committers.  I fully
>> realize that that issue might just be with me, but the fact remains that
>> there is practically no diversity in the project and I cannot in good
>> conscience recommend graduation for a project in that situation.
>>> Hi Ralph, Benson, et. al., some background:
>>> Flume is similar to Hadoop and other related projects in that it is
>>> very jira heavy for development activity. No slouch in terms of
>>> mailing list traffic either though (1200 last month):
>> Sorry I didn't include this in my prior post but here you are making my
>> point exactly.  I participate in several other Apache projects. Wading
>> through 1200+ emails per month that are largely Jira/Review noise makes it
>> very difficult for me to find posts that have any value. As a consequence I
>> am largely forced to simply delete everything generated by he Review tool
>> and Jira.  And I'm a mentor. I just don't see how newcomers are going to
>> find this style welcoming.
>> Ralph
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> -- 
> Eric Sammer
> twitter: esammer
> data:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message