On 11/09/2016 12:26 AM, Niall Pemberton wrote: > On Tue, Nov 8, 2016 at 10:42 PM, Daniel Gruno <humbed...@apache.org> wrote: > >> On 11/08/2016 11:14 PM, Roman Shaposhnik wrote: >>> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen <rbo...@rcbowen.com> wrote: >>>> >>>> >>>> On 11/07/2016 10:05 PM, Niall Pemberton wrote: >>>>> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno <humbed...@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. >> > > 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, Daniel. > > Niall > > > >>> >>> Thanks, >>> Roman. >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
