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. >>
