> 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.
Followed Raul’s suggestion and initiated the VOTE as a part of different discussion: http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Accept-Contribution-of-Ignite-Persistent-Store-td17896.html Take your time to review the donation and vote once you’re ready. — Denis > On 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. >>> >>
