Sounds good to me. To keep all of you in the loop, eventually, the *IP clearance vote* has been initiated on @incubator-general. Here is the form: http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html <http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html>
— Denis > On May 19, 2017, at 5:08 PM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > > Hm... I think I misunderstood the issue. > > In this case, since there is no disagreement, I would propose the following > steps then: > > 1. We should merge the code into a separate Ignite branch and start > stabilizing it. > 2. Let's start the VOTE to accept the donation once the code is merged. > As Raul suggested, let's keep the VOTE to accept the donation separate from > any decision on what to do with the donation or when to release it. > 3. I am hoping that once the donation is accepted, all the discussions > about the new code, moving it to Ignite standards, stabilizing it, and > eventually releasing it should happen on the dev list, which should allow > everyone in the community to familiarize themselves with it. > > Does this sound like an agreeable process to move forward? > > D. > > On Fri, May 19, 2017 at 11:53 AM, Konstantin Boudnik <c...@boudnik.org> > wrote: > >> 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 ;) >> >> Cos >> >> >> -- >> Take care, >> Konstantin (Cos) Boudnik >> >> >> On Thu, May 18, 2017 at 6:36 PM, Dmitriy Setrakyan >> <dsetrak...@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 <r...@apache.org> >> wrote: >>> >>>> On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <c...@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. >>>> >>
