>-----Original Message-----
>From: Arvind Prabhakar [mailto:arv...@apache.org]
>Sent: Tuesday, June 05, 2012 3:22 PM
>To: general@incubator.apache.org
>Subject: Re: Flume Graduation (was Re: June reports in two weeks)
>
>On Tue, Jun 5, 2012 at 11:42 AM, Patrick Hunt <ph...@apache.org> wrote:
>
>> On Tue, Jun 5, 2012 at 11:01 AM, Marvin Humphrey
><mar...@rectangular.com>
>> wrote:
>> > On Tue, Jun 5, 2012 at 9:53 AM, Patrick Hunt <ph...@apache.org> 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 <jukka.zitt...@gmail.com
>>wrote:
>>>> 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
>have
>>> the luxury of working on the project during regular working hours, others
>>> do that during their off hours. Hence the majority of contributions
>coming
>>> 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
>to
>PMC on graduation to address Ralph's concern. Had we not reached
>consensus,
>we would not have proceeded with the VOTE.  The characterization that the
>project is attempting to override a mentor is incorrect at best.
>
>Regards,
>Arvind Prabhakar

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to