incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Franklin, Matthew B." <>
Subject RE: Flume Graduation (was Re: June reports in two weeks)
Date Tue, 05 Jun 2012 21:22:15 GMT
>-----Original Message-----
>From: Arvind Prabhakar []
>Sent: Tuesday, June 05, 2012 3:22 PM
>Subject: Re: Flume Graduation (was Re: June reports in two weeks)
>On Tue, Jun 5, 2012 at 11:42 AM, Patrick Hunt <> wrote:
>> On Tue, Jun 5, 2012 at 11:01 AM, Marvin Humphrey
>> wrote:
>> > On Tue, Jun 5, 2012 at 9:53 AM, Patrick Hunt <> wrote:
>> >> Isn't this why we vote. To come to a decision when consensus can't be
>> >> reached and allow people to move on.
>> >
>> > When diversity concerns were raised in the ManifoldCF podling by Jukka,
>> > graduation was delayed to address them.
>> >
>> > When diversity concerns were raised in the Lucy podling by Torsten Curdt,
>> > graduation was delayed to address them.
>> >
>> > When diversity concerns were raised with regards to Flume, a VOTE was
>> called.
>> >
>> I think that's an oversimplification that ignores the work and good
>> faith the Flume community has done to address the concerns raised.
>> Extensive discussion ensued and afaict Ralph's concerns were
>> addressed. He raised issues and the community worked to resolve them.
>> (ie promoting committers to pmc as part of graduation).

Based on some digging, I think what you are mostly facing is a battle of perception.  As not
everyone has read or is privy to  the private list discussions, what they see is that you
have a standing -1 vote from a mentor who has expressed concerns on this list and the dev
list as to whether or not the diversity requirement has been met.  It looks (and looked to
me initially) like an incubator project that is dominated by a single company was trying to
push itself through the incubation process at whatever cost and before it was ready; something
that most IPMC members would likely resist.  If this type of misperception happened at the
incubator, what does the foundation and flume community see?      

With the additional background I have read, it seems that the community is much healthier
than it appears and is acting on a lot of communication and consensus that was driven on the
private list.  IMO, it would have been better to ask Ralph if he was comfortable retracting
his -1 prior to pushing the general@ VOTE and if he was not, then participate in the diversity
discussion on general@ until some consensus has been reached. 

At this point, my recommendation would be to discuss how the wrong impression was given and
what the PPMC could do to better communicate its intentions and policy changes to the community
and foundation.  Meanwhile, participate in the diversity discussion and see if the isn't a
consensus that can be reached that would allow the graduation process to continue.  Until
these two things are resolved, I am personally a +0 for graduation.    

>It was only after I saw the following response from Jukka that we moved to
>the next steps:
>>> On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting <
>>>> Do you think this is a problem for the community? If yes, how do you
>>>> plan to fix it? If not, why?
>>> I don't think this is a problem because while most Cloudera committers
>>> the luxury of working on the project during regular working hours, others
>>> do that during their off hours. Hence the majority of contributions
>>> from Cloudera.
>> OK, fair enough.
>> Such a scenario exists or has existed also in other Apache projects
>> like Jackrabbit that I'm most familiar with. It can be a tricky
>> balance to maintain a level playing field in such cases, for example
>> by making sure that all relevant project discussions happen out in the
>> open and that some committers don't feel like "junior partners" with
>> less ability to influence the project.
>> It sounds like you have a reasonably good handle on that, so I'm not
>> too worried, but my instinct suggests that the strict RTC model and
>> distinction between committers and (P)PMC members may be structural
>> factors that could easily end up tripping that balance. Are these
>> really essential tools for the project or could you live without them?
>> Other solutions to the RTC model include separate maintenance branches
>> with stricter review and testing requirements, and the only cases
>> where I really see a need for the committer/(P)PMC separation is with
>> umbrella projects or special cases like GSoC students or co-operation
>> across project boundaries.
>We took these suggestions and discussed them extensively within
>flume-private and reached consensus on promoting the current committers
>PMC on graduation to address Ralph's concern. Had we not reached
>we would not have proceeded with the VOTE.  The characterization that the
>project is attempting to override a mentor is incorrect at best.
>Arvind Prabhakar

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

View raw message