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