ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Date Mon, 22 May 2017 21:58:30 GMT
>   4) I believe the VOTE to accept the donation should be *decoupled* from
> any VOTEs –or decisions– on *what* to do with the donation and *when* to do
> it. Although it's sane and healthy to discuss the future of the donation
> inside its new home, ultimately there should be no time pressure by the
> donor with regards to the ultimate destination of their donation.

Followed Raul’s suggestion and initiated the VOTE as a part of different discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Accept-Contribution-of-Ignite-Persistent-Store-td17896.html

Take your time to review the donation and vote once you’re ready.

—
Denis

> On May 19, 2017, at 4:08 AM, Raúl Kripalani <raul.asf@evosent.com> wrote:
> 
> Nice! Sorry for being out of touch lately. I'm glad to see GridGain donate
> additional components to the Ignite ecosystem.
> 
> IIUC:
> 
>   1) GG implemented PDS for a commercial customer, but it is now being
> donated to the community => I assume GG has obtained clearance from that
> customer first.
> 
>   2) It appears that PDS is a module of Ignite, but changes are required
> to the core in the existing codebase for the integration to work => Correct?
> 
>   3) We use SemVer [1], and there have been talks about potentially
> merging this into 2.1, rather than 3.x. => Is it safe to assume that
> integrating the PDS will not lead to any *breaking changes* in APIs?
> 
>   4) I believe the VOTE to accept the donation should be *decoupled* from
> any VOTEs –or decisions– on *what* to do with the donation and *when* to do
> it. Although it's sane and healthy to discuss the future of the donation
> inside its new home, ultimately there should be no time pressure by the
> donor with regards to the ultimate destination of their donation.
> 
>   5) Normally the code belonging to the donation is first put in
> "quarantine" inside the codebase, i.e. a separate repo or a separate
> branch, where the community can review, test, peruse, integrate, etc. In
> this sense, I agree with Dmitriy. The natural fit seems to be a branch in
> this case.
> 
> If we just focus on whether to accept the donation and place the code into
> a separate branch –without pressure to release for 2.1, just a vision to do
> so– would there be consensus?
> 
> [1] http://semver.org/
> 
> Cheers,
> Raúl.
> 
> 
> On Fri, May 19, 2017 at 2:36 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
> wrote:
> 
>> Cos, Roman,
>> 
>> This has nothing to do with any deadlines, but rather with an easier and
>> more efficient process.
>> 
>> I am not sure how keeping the code in a separate code base is better for
>> the community than keeping it in a separate Apache Ignite branch, where we
>> can integrate it into Ignite CI process, run tests, stabilize, all while
>> the community is getting familiar with it. Keeping the code base outside of
>> Apache Ignite GIT makes it much more difficult to integrate or stabilize.
>> Moreover, if the code is in a separate Ignite branch, we can get the
>> community help to work on it and discuss issues on the dev list.
>> 
>> I would propose to move the code to a separate branch in Apache Ignite
>> right now, especially given that the paperwork has already been taken care
>> of. We can still decide within the Ignite community not to accept it down
>> the road, in which case we can toss away the branch.
>> 
>> Would you agree with this approach?
>> 
>> D.
>> 
>> On Wed, May 17, 2017 at 5:01 PM, Roman Shaposhnik <rvs@apache.org> wrote:
>> 
>>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <cos@apache.org>
>>> wrote:
>>>> Well, here's the issue with "simple move from private repo". This is a
>>>> huge chunk of code. And while employees of Gridgain are quite familiar
>>>> with it (or so I presume), the rest of the community is not. I, for
>>>> one, don't consider that the fact it has been tested and integrated
>>>> with AI 2.0 and, effectively, outside of AI 2.0 is a reasonable "go"
>>>> criteria.
>>> 
>>> Cos is absolutely correct here. Strong +1 to the above.
>>> 
>>>> I am sorry that I have to repeat this after 1.5 years after project's
>>>> graduation from the Incubator. However, I, personally and otherwise,
>>>> feel like a community process of creating software should be thought
>>>> through in the spirit of the community, rather than "release dates" or
>>>> "feature richness". Which means that the community has to be on board
>>>> with the decisions like this. And "on board" doesn't mean "majority of
>>>> the votes" as we, fortunately, aren't playing in democracy @apache.
>>>> Release dates are relevant to an entity, building and selling
>>>> products. in Apache we're are working on projects, and while releases
>>>> are important here, they convey a very different meaning.
>>> 
>>> Which brings me to a related question: what exactly needs to be released
>>> on this aggressive schedule and who is a beneficiary of this release?
>>> 
>>> What I am trying to say is this: if GirdGain has a product delivery
>>> deadline -- the
>>> company can go ahead and release its product with whatever features it
>>> needs to.
>>> 
>>> But I'm with Cos -- the community has to be given time to get comfortable
>>> with
>>> the code base if for nothing else but for licensing implications.
>>> 
>>> Thanks,
>>> Roman.
>>> 
>> 


Mime
View raw message