incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <humbed...@apache.org>
Subject Re: [VOTE] Graduate Apache Geode (incubating)
Date Tue, 08 Nov 2016 22:42:51 GMT
On 11/08/2016 11:14 PM, Roman Shaposhnik wrote:
> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen <rbowen@rcbowen.com> wrote:
>>
>>
>> On 11/07/2016 10:05 PM, Niall Pemberton wrote:
>>> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno <humbedooh@apache.org> wrote:
>>>
>>>>> I was looking at Snoot, and some figures jumped at me.
>>>>>
>>>>> Is the Podling (and the IPMC) satisfied that there is no concern with
>>>>> people affiliated with a single company providing more than 90% of all
>>>>> commits over the past year and, as far as I can tell, the vast majority
>>>>> of tickets and email, as well as a 73% stake in the proposed PMC?
>>>>>
>>>>> Is the IPMC satisfied that, should this company opt to not further spend
>>>>> resources on this project, that the project would still be as viable?
>>>>>
>>> Hi Daniel,
>>>
>>> I've observed this project since it joined the incubator and they've worked
>>> hard to create an open and welcoming community and to fix all the issues
>>> raised that could be barriers to their graduation.
>>>
>>> In terms of percentages, these things have been debated previously in
>>> graduation of projects such as Ignite, Flume, Tez etc and I'm not going to
>>> repeat the arguments from those discussions. Geode would be better with
>>> served with a wider community, but I think what matters is 1) have they
>>> demonstrated the behaviors we expect and 2) are they moving in the right
>>> direction. Geode is a great community and a pleasure to be involved with
>>> and I would say yes to both of these. I believe they are going in the right
>>> direction to make this project less dependent on one company and except to
>>> change the percentages you've pointed out, theres no purpose left for them
>>> being in the incubator. They've shown that they can manage themselves and
>>> theres enough independent oversight to mitigate concerns which is why I
>>> think we should vote for them to graduate.
>>
>> Given the discussions around single-vendor projects that are raging on
>> board@ I would have to agree with Daniel's concerns here. Projects that
>> are heavily dominated by a single vendor/company/organization
>> historically cause problems over time.
> 
> I think that other discussion addresses a very different set of problems.
> 
>> Is there a huge rush to get this project graduated?
> 
> I'd rather flip your argument around and say: at this point sitting in the
> Incubator adds no value to the project nor does it teach anything
> new or useful to its PPMC or a community at large.

If it turns the project into a more diverse/dispersed community, I'd say
that's added value. We can argue all night whether that's up to the
IPMC, the project or the board to figure out, I'm not sure we'll agree
there :)

> 
>> Surely we serve the
>> Foundation, and this project, better, by ensuring that this problem
>> (and, yes, it's a problem) is addressed before we grant them TLP status?
> 
> I disagree. The Incubator is a place to make sure that the community
> (regardless of its composition) truly understands and practices the
> "Apache Way". As has been suggested on this thread by a number of
> votes from project's mentors and IPMC members embedded in the
> Geode community that mission has been accomplished.
> 
> I see no reason to hold the project hostage over the diversity requirement
> simply because it is pointless for IPMC, project and the foundation.

Except it's not pointless for the foundation, we've seen that. we're
seeing that right now with several projects that either die completely
or take a very wrong turn because someone higher up the food chain
thinks otherwise about the project(s), and that also hurts the
foundation - let's not pretend that never happens. I can't say whether
this would be true for Geode (how would I know?), but a 96+% chunk of
all contributions coming from people affiliated with a single company is
worrisome to me.

> 
>> I'm personally less concerned with the sustainability of the project
>> should the company opt out of working on the project, and more concerned
>> with the kind of monoculture "we own it" problems that we're starting to
>> see crop up in other projects that were allowed to graduate without
>> building the community first.
> 
> Then you really should be voting "yes" on this thread. There's a good number
> of us on IPMC who believe that "we own it" is really not a problem with this
> community.

I'd say Rich should vote what he feels is right, not what "a good number
of us" think is right. That's not how consensus works.

You'll notice that I haven't just said "-1, I don't like it". But I also
haven't heard any compelling arguments as to why this isn't a problem,
save a "we're sure it's not a problem" reply.

If I were to look purely at contributions to the codebase, there is no
indication that this issue is at all being worked on, on the contrary,
if you look at contributions over time, the percentage that is purely
pivotal keeps going up and up, and now sits at >96% in the past 6 months.

Voting in new committers is one thing, but if it doesn't lead to some
sort of dispersion of who has a deciding role in the project, then I
don't believe the current strategy is working.

Furthermore, there is little to no recognition that this is even a
potential issue. I'd love to see people at least *acknowledging* that
this is something they have to work on, that'll give us something
tangible to relate to when deciding on a vote.
> 
> Thanks,
> Roman.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


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


Mime
View raw message