Guys, As discussed, pushed the branch being stabilized to ignite-5267 (and created the corresponding ticket).
2017-05-21 6:48 GMT+03:00 Denis Magda <dma...@apache.org>: > 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. > >>>> > >> > >
