ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Boudnik <...@apache.org>
Subject Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Date Fri, 19 May 2017 18:55:21 GMT
Dmitriy,

no one has ever suggested to keep the code in a separate repository
(once the grant issues were sorted out). Not sure where you get this
impression. I don't think there's anything to argue about ;)
--
  Take care,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Thu, May 18, 2017 at 6:36 PM, 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