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). > 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
