Hi Raul, thanks for jumping in! I agree on all points. On Fri, May 19, 2017 at 4:08 AM, Raúl Kripalani <raul....@evosent.com> wrote:
> Nice! Sorry for being out of touch lately. I'm glad to see GridGain donate > additional components to the Ignite ecosystem. > > IIUC: > > 1) GG implemented PDS for a commercial customer, but it is now being > donated to the community => I assume GG has obtained clearance from that > customer first. > > 2) It appears that PDS is a module of Ignite, but changes are required > to the core in the existing codebase for the integration to work => > Correct? > > 3) We use SemVer [1], and there have been talks about potentially > merging this into 2.1, rather than 3.x. => Is it safe to assume that > integrating the PDS will not lead to any *breaking changes* in APIs? > > 4) I believe the VOTE to accept the donation should be *decoupled* from > any VOTEs –or decisions– on *what* to do with the donation and *when* to do > it. Although it's sane and healthy to discuss the future of the donation > inside its new home, ultimately there should be no time pressure by the > donor with regards to the ultimate destination of their donation. > > 5) Normally the code belonging to the donation is first put in > "quarantine" inside the codebase, i.e. a separate repo or a separate > branch, where the community can review, test, peruse, integrate, etc. In > this sense, I agree with Dmitriy. The natural fit seems to be a branch in > this case. > > If we just focus on whether to accept the donation and place the code into > a separate branch –without pressure to release for 2.1, just a vision to do > so– would there be consensus? > > [1] http://semver.org/ > > Cheers, > Raúl. > > > On Fri, May 19, 2017 at 2:36 AM, 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. > > > > > >