incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <>
Subject Re: [VOTE] Graduate Apache Geode (incubating)
Date Tue, 08 Nov 2016 23:30:09 GMT
On 11/09/2016 12:26 AM, Niall Pemberton wrote:
> On Tue, Nov 8, 2016 at 10:42 PM, Daniel Gruno <> wrote:
>> On 11/08/2016 11:14 PM, Roman Shaposhnik wrote:
>>> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen <> wrote:
>>>> On 11/07/2016 10:05 PM, Niall Pemberton wrote:
>>>>> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno <>
>> wrote:
>>>>>>> I was looking at Snoot, and some figures jumped at me.
>>>>>>> Is the Podling (and the IPMC) satisfied that there is no concern
>>>>>>> people affiliated with a single company providing more than 90%
>> 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
>>>>>>> Is the IPMC satisfied that, should this company opt to not further
>> spend
>>>>>>> resources on this project, that the project would still be as
>>>>> 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
>>>>> 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.
> Perhaps you could re-read my first post, because I believe did acknowledge
> it.

I didn't read it as such, but this does help towards that :) Thanks.

With regards,

> Niall
>>> Thanks,
>>> Roman.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

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

View raw message