All great points, thank you Raúl! +1 -- Take care, Konstantin (Cos) Boudnik 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
Disclaimer: Opinions expressed in this email are those of the author, and do not necessarily represent the views of any company the author might be affiliated with at the moment of writing. 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. >> > >>
