ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)
Date Thu, 18 May 2017 03:03:37 GMT
Cos, Roman,

Your concerns sound reasonable to me. However, that’s my personal point of view and not
of the overall community. Personally, I accustomed to lean on the notion of releases and deadlines.
Not sure that it contradicts ASF principles or can’t be applied to Apache projects. In any
case it’s up to the community to decide how to proceed. I’m just trying to form a sort
of process ;)

In general, I would avoid all the arguments and look at the storage collaboratively and constructively.
I didn’t consider to rush you. Just forwarded you the message so that you can spot it among
many falling in your inbox. Take whatever time you need.

In the meanwhile, I’ve prepared the IP Clearance page referring to the template below but
failed to commit the changes to ASF repo:
http://incubator.apache.org/ip-clearance/ip-clearance-template.html <http://incubator.apache.org/ip-clearance/ip-clearance-template.html>

Could any of you grant me karma or commit the changes from your accounts?

> We also have this documented contribution process [1]. Is there a good
> reason to circumvent it in this particular case?
> [1] https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-1.CreateGitHubpull-request
Cos, the IP Clearance/grant process was followed and the following artifacts were prepared
as a part of it (if you prefer the pull-request then it should be possible to do it):

The repository with the donation is ready and available for review:
https://github.com/agoncharuk/ignite/tree/pds-donate <https://github.com/agoncharuk/ignite/tree/pds-donate>

Big and main part of the sources is aggregated in “modules/pds”. The rest, that connects
Apache Ignite memory architecture and SQL engine is under “core” and “indexing” modules.
Alex Goncharuk should be able to point to specific files or commits if required.

Here is a description:
* Persistent Store Overview: https://cwiki.apache.org/confluence/display/IGNITE/Persistent+Store+Overview
* Persistent Store Internal Design: https://cwiki.apache.org/confluence/display/IGNITE/Persistent+Store+Internal+Design


> On May 17, 2017, at 8: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