ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raúl Kripalani <raul....@evosent.com>
Subject Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Date Fri, 19 May 2017 11:08:42 GMT
Nice! Sorry for being out of touch lately. I'm glad to see GridGain donate
additional components to the Ignite ecosystem.


   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/


On Fri, May 19, 2017 at 2:36 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>

> 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 <rvs@apache.org> wrote:
> > On Wed, May 17, 2017 at 3:04 PM, Konstantin Boudnik <cos@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.
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message