GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dmagda
Igniters,

GridGain, as one of the most active Apache Ignite contributors, has been developing a unique distributed persistent store specifically for Apache Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL compliant fault-tolerant solution.

The store transparently integrates with Apache Ignite as an optional disk layer (in addition to the existing RAM layer) via the new page memory architecture that to be released in Apache Ignite 2.0. This allows storing supersets of data on disk while having a subset in memory not worrying about that you forgot to preload (warmup) your caches!

Assuming that the storage goes to ASF as a part of Apache Ignite 2.1 release the following will be supported by Ignite out-of-the-box:

* SQL queries execution over the data that is both in RAM and on disk: no need to preload the whole data set in memory.

* Cluster instantaneous restarts: once your cluster ring is recovered after a restart your applications are fully operational even if they highly utilize SQL queries.

As for the use cases, it means that Apache Ignite will be possible to use as a distributed SQL database with memory-first concept.

And we decided at GridGain that this tremendous feature should be open source from the very beginning.

Guys, could you advise how I can start official donation process?


Denis


 

         
 
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dsetrakyan
Great news and I am glad that GridGain was finally able to open source such
an essential feature to Ignite. Given that I was deeply involved in the
development of this feature for the past year, I would add that one of the
main advantages here is that Ignite becomes fully operational from disk
(SSD or Flash) without any need to preload the data in memory.

With full SQL support available in Ignite, this feature will allow Ignite
serve as a distributed transactional database, both in memory and on disk,
while continuing to support all the existing use cases, including the
in-memory data grid.

Cos, can you point us to any legal paperwork that needs to be signed in
order to complete the donation?

D.

On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <[hidden email]> wrote:

> Igniters,
>
> GridGain, as one of the most active Apache Ignite contributors, has been
> developing a unique distributed persistent store specifically for Apache
> Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL
> compliant fault-tolerant solution.
>
> The store transparently integrates with Apache Ignite as an optional disk
> layer (in addition to the existing RAM layer) via the new page memory
> architecture that to be released in Apache Ignite 2.0. This allows storing
> supersets of data on disk while having a subset in memory not worrying
> about that you forgot to preload (warmup) your caches!
>
> Assuming that the storage goes to ASF as a part of Apache Ignite 2.1
> release the following will be supported by Ignite out-of-the-box:
>
> * SQL queries execution over the data that is both in RAM and on disk: no
> need to preload the whole data set in memory.
>
> * Cluster instantaneous restarts: once your cluster ring is recovered
> after a restart your applications are fully operational even if they highly
> utilize SQL queries.
>
> As for the use cases, it means that Apache Ignite will be possible to use
> as a distributed SQL database with memory-first concept.
>
> And we decided at GridGain that this tremendous feature should be open
> source from the very beginning.
>
> Guys, could you advise how I can start official donation process?
>
> —
> Denis
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Sergi
Nice! Finally Ignite from a "Middleware Solution" becoming an "All In One
Backend Solution".

Sergi

2017-04-18 5:46 GMT+03:00 Dmitriy Setrakyan <[hidden email]>:

> Great news and I am glad that GridGain was finally able to open source such
> an essential feature to Ignite. Given that I was deeply involved in the
> development of this feature for the past year, I would add that one of the
> main advantages here is that Ignite becomes fully operational from disk
> (SSD or Flash) without any need to preload the data in memory.
>
> With full SQL support available in Ignite, this feature will allow Ignite
> serve as a distributed transactional database, both in memory and on disk,
> while continuing to support all the existing use cases, including the
> in-memory data grid.
>
> Cos, can you point us to any legal paperwork that needs to be signed in
> order to complete the donation?
>
> D.
>
> On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <[hidden email]> wrote:
>
> > Igniters,
> >
> > GridGain, as one of the most active Apache Ignite contributors, has been
> > developing a unique distributed persistent store specifically for Apache
> > Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL
> > compliant fault-tolerant solution.
> >
> > The store transparently integrates with Apache Ignite as an optional disk
> > layer (in addition to the existing RAM layer) via the new page memory
> > architecture that to be released in Apache Ignite 2.0. This allows
> storing
> > supersets of data on disk while having a subset in memory not worrying
> > about that you forgot to preload (warmup) your caches!
> >
> > Assuming that the storage goes to ASF as a part of Apache Ignite 2.1
> > release the following will be supported by Ignite out-of-the-box:
> >
> > * SQL queries execution over the data that is both in RAM and on disk: no
> > need to preload the whole data set in memory.
> >
> > * Cluster instantaneous restarts: once your cluster ring is recovered
> > after a restart your applications are fully operational even if they
> highly
> > utilize SQL queries.
> >
> > As for the use cases, it means that Apache Ignite will be possible to use
> > as a distributed SQL database with memory-first concept.
> >
> > And we decided at GridGain that this tremendous feature should be open
> > source from the very beginning.
> >
> > Guys, could you advise how I can start official donation process?
> >
> > —
> > Denis
> >
> >
> >
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

christos
This is fantastic news guys!! Finally a real solution that can cater for BIG AND FAST data!
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

nivanov
Combining this with upcoming new SQL features should give Google Spanner a
run for its money...
--
Nikita Ivanov


On Tue, Apr 18, 2017 at 3:39 AM, christos <[hidden email]> wrote:

> This is fantastic news guys!! Finally a real solution that can cater for
> BIG
> AND FAST data!
>
>
>
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/GridGain-Donates-
> Persistent-Distributed-Store-To-ASF-Apache-Ignite-tp16788p16836.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dmagda
Igniters,

I would encourage everyone interested to share his/her opinion on this donation and if there are no objections I will kick off an official vote in a couple of ways.


Denis

> On Apr 18, 2017, at 4:11 AM, Nikita Ivanov <[hidden email]> wrote:
>
> Combining this with upcoming new SQL features should give Google Spanner a
> run for its money...
> --
> Nikita Ivanov
>
>
> On Tue, Apr 18, 2017 at 3:39 AM, christos <[hidden email]> wrote:
>
>> This is fantastic news guys!! Finally a real solution that can cater for
>> BIG
>> AND FAST data!
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-
>> developers.2346864.n4.nabble.com/GridGain-Donates-
>> Persistent-Distributed-Store-To-ASF-Apache-Ignite-tp16788p16836.html
>> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.
>>

Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Konstantin Boudnik-2
In reply to this post by dmagda
Great news indeed! Thanks for sharing!

Before we jump on the voting and all that, can we have a chance to learn more
about this new feature and its integration points with the rest of the
platform? A few questions come to mind immediately:

1. This is an "optional disk layer", so it could be turned off _completely_ and
   have no effect on those who don't want nor need to use it, right?
2. Does it have any performance implications on the in-memory operations?
3. When you say it is "fully ... ANSI-99 SQL compliant fault-tolerant" does it
   mean that _all_ SQL operations are now now supported through SQL or still
   some of them only available through the JAVA APIs? THe fault tolerance is
   for the data-center only as before, right? No new WAN-able HA has been
   introduced?
4. With addition of this new model, are there any backward compatibility
   issues that would affect Ignite's application developers?
5. Can we have a discussion about the design of this new layer so people here
   can understand better what's being offered, how to take the advantage of
   it, and - most importantly - to offer their own insights and improvements
   into this new subsystems before it's landed in the source code? And it
   would safe a lot of time on Q&A as well.

I am confused a little bit by these two slightly controversial statements:
- "GG... has been developing a unique distributed persistent store...for more
  than a year in-house"
- "we decided at GridGain that this tremendous feature should be open source
  from the very beginning"

So, it sounds like the code has been under the development for a while and it
isn't opened up "from the very beginning", unless there's a new meaning of the
word beginning I am not aware of just yet :) It feels like this could be a
significant amount of the code to be digested by the community.

Appreciate your thoughts on this! Thanks,
  Cos

On Mon, Apr 17, 2017 at 07:37PM, Denis Magda wrote:

> Igniters,
>
> GridGain, as one of the most active Apache Ignite contributors, has been
> developing a unique distributed persistent store specifically for Apache
> Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL
> compliant fault-tolerant solution.
>
> The store transparently integrates with Apache Ignite as an optional disk
> layer (in addition to the existing RAM layer) via the new page memory
> architecture that to be released in Apache Ignite 2.0. This allows storing
> supersets of data on disk while having a subset in memory not worrying about
> that you forgot to preload (warmup) your caches!
>
> Assuming that the storage goes to ASF as a part of Apache Ignite 2.1 release
> the following will be supported by Ignite out-of-the-box:
>
> * SQL queries execution over the data that is both in RAM and on disk: no
> need to preload the whole data set in memory.
>
> * Cluster instantaneous restarts: once your cluster ring is recovered after
> a restart your applications are fully operational even if they highly
> utilize SQL queries.
>
> As for the use cases, it means that Apache Ignite will be possible to use as
> a distributed SQL database with memory-first concept.
>
> And we decided at GridGain that this tremendous feature should be open
> source from the very beginning.
>
> Guys, could you advise how I can start official donation process?
>
> —
> Denis
>
>
>  
>
>
>  
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dsetrakyan
Cos, good questions! My answers are inline...

On Tue, Apr 18, 2017 at 4:17 PM, Konstantin Boudnik <[hidden email]> wrote:

> Great news indeed! Thanks for sharing!
>
> Before we jump on the voting and all that, can we have a chance to learn
> more
> about this new feature and its integration points with the rest of the
> platform? A few questions come to mind immediately:
>
> 1. This is an "optional disk layer", so it could be turned off
> _completely_ and
>    have no effect on those who don't want nor need to use it, right?
>

Yes


> 2. Does it have any performance implications on the in-memory operations?
>

No, as long as the persistence is turned off, the in-memory operations will
not be impacted.


> 3. When you say it is "fully ... ANSI-99 SQL compliant fault-tolerant"
> does it
>    mean that _all_ SQL operations are now now supported through SQL or
> still
>    some of them only available through the JAVA APIs? THe fault tolerance
> is
>    for the data-center only as before, right? No new WAN-able HA has been
>    introduced?
>

Well... I would say most SQL operations are going to be supported,
including CREATE, DROP, INSERT, UPDATE, DELETE, SELECT, and of course,
distributed joins.

And yes, you are right about the fault tolerance.


> 4. With addition of this new model, are there any backward compatibility
>    issues that would affect Ignite's application developers?
>

I don't think so. All incompatible changes should have been introduced in
2.0. I will let other community members comment here...


> 5. Can we have a discussion about the design of this new layer so people
> here
>    can understand better what's being offered, how to take the advantage of
>    it, and - most importantly - to offer their own insights and
> improvements
>    into this new subsystems before it's landed in the source code? And it
>    would safe a lot of time on Q&A as well.
>

Yes, good idea. Denis, do you have a high level architecture for the
proposed persistence?


>
> I am confused a little bit by these two slightly controversial statements:
> - "GG... has been developing a unique distributed persistent store...for
> more
>   than a year in-house"
> - "we decided at GridGain that this tremendous feature should be open
> source
>   from the very beginning"
>
> So, it sounds like the code has been under the development for a while and
> it
> isn't opened up "from the very beginning", unless there's a new meaning of
> the
> word beginning I am not aware of just yet :) It feels like this could be a
> significant amount of the code to be digested by the community.
>

Yes, you are right. Many of us wanted to open source this functionality
from the get go. In any case, this makes a great addition to the project. I
hope we will be able to provide enough documentation and feedback on the
dev list to ease up the digestion process.


>
> Appreciate your thoughts on this! Thanks,
>   Cos
>
> On Mon, Apr 17, 2017 at 07:37PM, Denis Magda wrote:
> > Igniters,
> >
> > GridGain, as one of the most active Apache Ignite contributors, has been
> > developing a unique distributed persistent store specifically for Apache
> > Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL
> > compliant fault-tolerant solution.
> >
> > The store transparently integrates with Apache Ignite as an optional disk
> > layer (in addition to the existing RAM layer) via the new page memory
> > architecture that to be released in Apache Ignite 2.0. This allows
> storing
> > supersets of data on disk while having a subset in memory not worrying
> about
> > that you forgot to preload (warmup) your caches!
> >
> > Assuming that the storage goes to ASF as a part of Apache Ignite 2.1
> release
> > the following will be supported by Ignite out-of-the-box:
> >
> > * SQL queries execution over the data that is both in RAM and on disk: no
> > need to preload the whole data set in memory.
> >
> > * Cluster instantaneous restarts: once your cluster ring is recovered
> after
> > a restart your applications are fully operational even if they highly
> > utilize SQL queries.
> >
> > As for the use cases, it means that Apache Ignite will be possible to
> use as
> > a distributed SQL database with memory-first concept.
> >
> > And we decided at GridGain that this tremendous feature should be open
> > source from the very beginning.
> >
> > Guys, could you advise how I can start official donation process?
> >
> > —
> > Denis
> >
> >
> >
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Roman Shaposhnik
In reply to this post by dmagda
On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <[hidden email]> wrote:

> Igniters,
>
> GridGain, as one of the most active Apache Ignite contributors, has been developing a unique distributed persistent store specifically for Apache Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL compliant fault-tolerant solution.
>
> The store transparently integrates with Apache Ignite as an optional disk layer (in addition to the existing RAM layer) via the new page memory architecture that to be released in Apache Ignite 2.0. This allows storing supersets of data on disk while having a subset in memory not worrying about that you forgot to preload (warmup) your caches!
>
> Assuming that the storage goes to ASF as a part of Apache Ignite 2.1 release the following will be supported by Ignite out-of-the-box:
>
> * SQL queries execution over the data that is both in RAM and on disk: no need to preload the whole data set in memory.
>
> * Cluster instantaneous restarts: once your cluster ring is recovered after a restart your applications are fully operational even if they highly utilize SQL queries.
>
> As for the use cases, it means that Apache Ignite will be possible to use as a distributed SQL database with memory-first concept.
>
> And we decided at GridGain that this tremendous feature should be open source from the very beginning.
>
> Guys, could you advise how I can start official donation process?

First of all, it really isn't a good thing that a major functionality
was developed
behind the firewall without any feedback from Apache Ignite community.

So the first question I'd like to ask is this: what was the reason for this
to be developed in such a way (and a follow up -- how can this be
avoided in the future)?

In my experience the only excuse for something like that is either a work
that was done before the project joined ASF or work that was done under
the draconian initial license agreement that can now be re-licensed under ASF.

Which brings me to my next point: any addition to the project that doesn't
go through the normal channels of small reversible commits that are easy
to scrutinize for IP issues needs to be vetted. Depending on the size of the
donation a separate SGA for ASF may be required.

Which brings me to my last point: where's the code? In order to have a
factual conversation about the next steps in the process I'd like to be
able to take a look at the code available to me under the Apache License.

On top of which, I would like to either have a full access to the commit
and authorship history of this code OR a statement from the current
overall copyright owner.

Please make it available and post the URL to this thread. Then we can
discuss the next steps.

Thanks,
Roman (wearing his ASF member hat).
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dsetrakyan
On Tue, Apr 18, 2017 at 11:17 PM, Roman Shaposhnik <[hidden email]>
wrote:

> On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <[hidden email]> wrote:
>
> First of all, it really isn't a good thing that a major functionality
> was developed
> behind the firewall without any feedback from Apache Ignite community.
>
> So the first question I'd like to ask is this: what was the reason for this
> to be developed in such a way (and a follow up -- how can this be
> avoided in the future)?
>
> In my experience the only excuse for something like that is either a work
> that was done before the project joined ASF or work that was done under
> the draconian initial license agreement that can now be re-licensed under
> ASF.
>

Completely agree and I would also personally prefer that all features are
developed in the open source community from the get go. In this case it was
not possible, as it initially was developed for one of the GridGain
customers and eventually evolved into something that could add value to the
community - hence the proposal to open source it.

The code is not complete yet, and will require additional development
before it can become a part of an official Ignite release. I would prefer
that the remaining development can happen openly in the Ignite community.


>
> Which brings me to my next point: any addition to the project that doesn't
> go through the normal channels of small reversible commits that are easy
> to scrutinize for IP issues needs to be vetted. Depending on the size of
> the
> donation a separate SGA for ASF may be required.
>

Correct. We will also be required to fill out the IP-Clearance form,
specifically designed for situations like this one, when a code is donated
into an existing code base:

http://incubator.apache.org/ip-clearance/


>
> Which brings me to my last point: where's the code? In order to have a
> factual conversation about the next steps in the process I'd like to be
> able to take a look at the code available to me under the Apache License.
>

Hm... I guess you are right, the code needs to be provided in a public GIT
repository for review. To my knowledge this has not been done yet.


> On top of which, I would like to either have a full access to the commit
> and authorship history of this code OR a statement from the current
> overall copyright owner.
>

Would a standard SGA suffice here?

I believe that ASF guidelines suggest that a discussion should happen
first. Once the community gets enough information, we will move to a PMC
vote. I was under the impression that once the PMC vote passes, then the
SGA should be provided. Or does GridGain need to provide a signed SGA right
away?


>
> Please make it available and post the URL to this thread. Then we can
> discuss the next steps.
>
> Thanks,
> Roman (wearing his ASF member hat).
>
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Roman Shaposhnik
On Tue, Apr 18, 2017 at 11:54 PM, Dmitriy Setrakyan
<[hidden email]> wrote:

> On Tue, Apr 18, 2017 at 11:17 PM, Roman Shaposhnik <[hidden email]>
> wrote:
>
>> On Mon, Apr 17, 2017 at 7:37 PM, Denis Magda <[hidden email]> wrote:
>>
>> First of all, it really isn't a good thing that a major functionality
>> was developed
>> behind the firewall without any feedback from Apache Ignite community.
>>
>> So the first question I'd like to ask is this: what was the reason for this
>> to be developed in such a way (and a follow up -- how can this be
>> avoided in the future)?
>>
>> In my experience the only excuse for something like that is either a work
>> that was done before the project joined ASF or work that was done under
>> the draconian initial license agreement that can now be re-licensed under
>> ASF.
>>
>
> Completely agree and I would also personally prefer that all features are
> developed in the open source community from the get go. In this case it was
> not possible, as it initially was developed for one of the GridGain
> customers and eventually evolved into something that could add value to the
> community - hence the proposal to open source it.

Fair enough.

> The code is not complete yet, and will require additional development
> before it can become a part of an official Ignite release. I would prefer
> that the remaining development can happen openly in the Ignite community.

You can most definitely keep refactoring it -- but that'll have to
happen in a branch.

>> Which brings me to my next point: any addition to the project that doesn't
>> go through the normal channels of small reversible commits that are easy
>> to scrutinize for IP issues needs to be vetted. Depending on the size of
>> the
>> donation a separate SGA for ASF may be required.
>>
>
> Correct. We will also be required to fill out the IP-Clearance form,
> specifically designed for situations like this one, when a code is donated
> into an existing code base:
>
> http://incubator.apache.org/ip-clearance/
>
>
>>
>> Which brings me to my last point: where's the code? In order to have a
>> factual conversation about the next steps in the process I'd like to be
>> able to take a look at the code available to me under the Apache License.
>>
>
> Hm... I guess you are right, the code needs to be provided in a public GIT
> repository for review. To my knowledge this has not been done yet.
>
>
>> On top of which, I would like to either have a full access to the commit
>> and authorship history of this code OR a statement from the current
>> overall copyright owner.
>>
>
> Would a standard SGA suffice here?

Is there a single copyright owner for the codebase? If there's is -- then yes
you can file an SGA.

> I believe that ASF guidelines suggest that a discussion should happen
> first. Once the community gets enough information, we will move to a PMC
> vote. I was under the impression that once the PMC vote passes, then the
> SGA should be provided. Or does GridGain need to provide a signed SGA right
> away?

You have to provide SGA and code base right away. Not making those available
will preclude any meaningful discussion and most certainly will preclude a vote.

Note that filing an SGA doesn't mean that the code will end up in ASF
-- it means
ASF (read its members) will have a right to scrutinize it without the
fear of being
exposed to questionable IP.

In order to file an SGA you will have to make the code available.

So here's a set of steps you need to do:
    1. make code available some place on GitHub
    2. file and SGA with ASF pointing at a tag in that repo
    3. once both of these are done -- restart the discussion thread

Thanks,
Roman.
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dmagda
In reply to this post by dsetrakyan
>> 5. Can we have a discussion about the design of this new layer so people
>> here
>>   can understand better what's being offered, how to take the advantage of
>>   it, and - most importantly - to offer their own insights and
>> improvements
>>   into this new subsystems before it's landed in the source code? And it
>>   would safe a lot of time on Q&A as well.
>>
>
> Yes, good idea. Denis, do you have a high level architecture for the
> proposed persistence?

It will be prepared right after Apache Ignite 2.0 release. Presently, don’t have time to wrap it up in a doc form.


Denis

> On Apr 18, 2017, at 10:44 PM, Dmitriy Setrakyan <[hidden email]> wrote:
>
> Cos, good questions! My answers are inline...
>
> On Tue, Apr 18, 2017 at 4:17 PM, Konstantin Boudnik <[hidden email] <mailto:[hidden email]>> wrote:
>
>> Great news indeed! Thanks for sharing!
>>
>> Before we jump on the voting and all that, can we have a chance to learn
>> more
>> about this new feature and its integration points with the rest of the
>> platform? A few questions come to mind immediately:
>>
>> 1. This is an "optional disk layer", so it could be turned off
>> _completely_ and
>>   have no effect on those who don't want nor need to use it, right?
>>
>
> Yes
>
>
>> 2. Does it have any performance implications on the in-memory operations?
>>
>
> No, as long as the persistence is turned off, the in-memory operations will
> not be impacted.
>
>
>> 3. When you say it is "fully ... ANSI-99 SQL compliant fault-tolerant"
>> does it
>>   mean that _all_ SQL operations are now now supported through SQL or
>> still
>>   some of them only available through the JAVA APIs? THe fault tolerance
>> is
>>   for the data-center only as before, right? No new WAN-able HA has been
>>   introduced?
>>
>
> Well... I would say most SQL operations are going to be supported,
> including CREATE, DROP, INSERT, UPDATE, DELETE, SELECT, and of course,
> distributed joins.
>
> And yes, you are right about the fault tolerance.
>
>
>> 4. With addition of this new model, are there any backward compatibility
>>   issues that would affect Ignite's application developers?
>>
>
> I don't think so. All incompatible changes should have been introduced in
> 2.0. I will let other community members comment here...
>
>
>> 5. Can we have a discussion about the design of this new layer so people
>> here
>>   can understand better what's being offered, how to take the advantage of
>>   it, and - most importantly - to offer their own insights and
>> improvements
>>   into this new subsystems before it's landed in the source code? And it
>>   would safe a lot of time on Q&A as well.
>>
>
> Yes, good idea. Denis, do you have a high level architecture for the
> proposed persistence?
>
>
>>
>> I am confused a little bit by these two slightly controversial statements:
>> - "GG... has been developing a unique distributed persistent store...for
>> more
>>  than a year in-house"
>> - "we decided at GridGain that this tremendous feature should be open
>> source
>>  from the very beginning"
>>
>> So, it sounds like the code has been under the development for a while and
>> it
>> isn't opened up "from the very beginning", unless there's a new meaning of
>> the
>> word beginning I am not aware of just yet :) It feels like this could be a
>> significant amount of the code to be digested by the community.
>>
>
> Yes, you are right. Many of us wanted to open source this functionality
> from the get go. In any case, this makes a great addition to the project. I
> hope we will be able to provide enough documentation and feedback on the
> dev list to ease up the digestion process.
>
>
>>
>> Appreciate your thoughts on this! Thanks,
>>  Cos
>>
>> On Mon, Apr 17, 2017 at 07:37PM, Denis Magda wrote:
>>> Igniters,
>>>
>>> GridGain, as one of the most active Apache Ignite contributors, has been
>>> developing a unique distributed persistent store specifically for Apache
>>> Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL
>>> compliant fault-tolerant solution.
>>>
>>> The store transparently integrates with Apache Ignite as an optional disk
>>> layer (in addition to the existing RAM layer) via the new page memory
>>> architecture that to be released in Apache Ignite 2.0. This allows
>> storing
>>> supersets of data on disk while having a subset in memory not worrying
>> about
>>> that you forgot to preload (warmup) your caches!
>>>
>>> Assuming that the storage goes to ASF as a part of Apache Ignite 2.1
>> release
>>> the following will be supported by Ignite out-of-the-box:
>>>
>>> * SQL queries execution over the data that is both in RAM and on disk: no
>>> need to preload the whole data set in memory.
>>>
>>> * Cluster instantaneous restarts: once your cluster ring is recovered
>> after
>>> a restart your applications are fully operational even if they highly
>>> utilize SQL queries.
>>>
>>> As for the use cases, it means that Apache Ignite will be possible to
>> use as
>>> a distributed SQL database with memory-first concept.
>>>
>>> And we decided at GridGain that this tremendous feature should be open
>>> source from the very beginning.
>>>
>>> Guys, could you advise how I can start official donation process?
>>>
>>> —
>>> Denis

Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Konstantin Boudnik-2
Thank you guys for quick feedback!

So I guess once this and the source code/SGA addressing concerns from Roman's
emails are available to all of us - we can reconvene for the constructive
discussion!

With regards,
  Cos

On Wed, Apr 19, 2017 at 04:46PM, Denis Magda wrote:

> >> 5. Can we have a discussion about the design of this new layer so people
> >> here
> >>   can understand better what's being offered, how to take the advantage of
> >>   it, and - most importantly - to offer their own insights and
> >> improvements
> >>   into this new subsystems before it's landed in the source code? And it
> >>   would safe a lot of time on Q&A as well.
> >>
> >
> > Yes, good idea. Denis, do you have a high level architecture for the
> > proposed persistence?
>
> It will be prepared right after Apache Ignite 2.0 release. Presently, don’t
> have time to wrap it up in a doc form.
>
> —
> Denis
>
> > On Apr 18, 2017, at 10:44 PM, Dmitriy Setrakyan <[hidden email]> wrote:
> >
> > Cos, good questions! My answers are inline...
> >
> > On Tue, Apr 18, 2017 at 4:17 PM, Konstantin Boudnik <[hidden email]
> > <mailto:[hidden email]>> wrote:
> >
> >> Great news indeed! Thanks for sharing!
> >>
> >> Before we jump on the voting and all that, can we have a chance to learn
> >> more
> >> about this new feature and its integration points with the rest of the
> >> platform? A few questions come to mind immediately:
> >>
> >> 1. This is an "optional disk layer", so it could be turned off
> >> _completely_ and
> >>   have no effect on those who don't want nor need to use it, right?
> >>
> >
> > Yes
> >
> >
> >> 2. Does it have any performance implications on the in-memory operations?
> >>
> >
> > No, as long as the persistence is turned off, the in-memory operations will
> > not be impacted.
> >
> >
> >> 3. When you say it is "fully ... ANSI-99 SQL compliant fault-tolerant"
> >> does it
> >>   mean that _all_ SQL operations are now now supported through SQL or
> >> still
> >>   some of them only available through the JAVA APIs? THe fault tolerance
> >> is
> >>   for the data-center only as before, right? No new WAN-able HA has been
> >>   introduced?
> >>
> >
> > Well... I would say most SQL operations are going to be supported,
> > including CREATE, DROP, INSERT, UPDATE, DELETE, SELECT, and of course,
> > distributed joins.
> >
> > And yes, you are right about the fault tolerance.
> >
> >
> >> 4. With addition of this new model, are there any backward compatibility
> >>   issues that would affect Ignite's application developers?
> >>
> >
> > I don't think so. All incompatible changes should have been introduced in
> > 2.0. I will let other community members comment here...
> >
> >
> >> 5. Can we have a discussion about the design of this new layer so people
> >> here
> >>   can understand better what's being offered, how to take the advantage of
> >>   it, and - most importantly - to offer their own insights and
> >> improvements
> >>   into this new subsystems before it's landed in the source code? And it
> >>   would safe a lot of time on Q&A as well.
> >>
> >
> > Yes, good idea. Denis, do you have a high level architecture for the
> > proposed persistence?
> >
> >
> >>
> >> I am confused a little bit by these two slightly controversial statements:
> >> - "GG... has been developing a unique distributed persistent store...for
> >> more
> >>  than a year in-house"
> >> - "we decided at GridGain that this tremendous feature should be open
> >> source
> >>  from the very beginning"
> >>
> >> So, it sounds like the code has been under the development for a while and
> >> it
> >> isn't opened up "from the very beginning", unless there's a new meaning of
> >> the
> >> word beginning I am not aware of just yet :) It feels like this could be a
> >> significant amount of the code to be digested by the community.
> >>
> >
> > Yes, you are right. Many of us wanted to open source this functionality
> > from the get go. In any case, this makes a great addition to the project. I
> > hope we will be able to provide enough documentation and feedback on the
> > dev list to ease up the digestion process.
> >
> >
> >>
> >> Appreciate your thoughts on this! Thanks,
> >>  Cos
> >>
> >> On Mon, Apr 17, 2017 at 07:37PM, Denis Magda wrote:
> >>> Igniters,
> >>>
> >>> GridGain, as one of the most active Apache Ignite contributors, has been
> >>> developing a unique distributed persistent store specifically for Apache
> >>> Ignite for more than a year in-house. It’s a fully ACID and ANSI-99 SQL
> >>> compliant fault-tolerant solution.
> >>>
> >>> The store transparently integrates with Apache Ignite as an optional disk
> >>> layer (in addition to the existing RAM layer) via the new page memory
> >>> architecture that to be released in Apache Ignite 2.0. This allows
> >> storing
> >>> supersets of data on disk while having a subset in memory not worrying
> >> about
> >>> that you forgot to preload (warmup) your caches!
> >>>
> >>> Assuming that the storage goes to ASF as a part of Apache Ignite 2.1
> >> release
> >>> the following will be supported by Ignite out-of-the-box:
> >>>
> >>> * SQL queries execution over the data that is both in RAM and on disk: no
> >>> need to preload the whole data set in memory.
> >>>
> >>> * Cluster instantaneous restarts: once your cluster ring is recovered
> >> after
> >>> a restart your applications are fully operational even if they highly
> >>> utilize SQL queries.
> >>>
> >>> As for the use cases, it means that Apache Ignite will be possible to
> >> use as
> >>> a distributed SQL database with memory-first concept.
> >>>
> >>> And we decided at GridGain that this tremendous feature should be open
> >>> source from the very beginning.
> >>>
> >>> Guys, could you advise how I can start official donation process?
> >>>
> >>> —
> >>> Denis
>
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Konstantin Boudnik-2
In reply to this post by dsetrakyan
On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
>
> Would a standard SGA suffice here?
>
> I believe that ASF guidelines suggest that a discussion should happen
> first. Once the community gets enough information, we will move to a PMC
> vote. I was under the impression that once the PMC vote passes, then the
> SGA should be provided. Or does GridGain need to provide a signed SGA right
> away?

That reminds me of that Pelosi's self-inflicted conundrum of "In order
to see the bill, we should pass the bill" ;)

Cos

Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dsetrakyan
On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <[hidden email]> wrote:

> On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
> >
> > Would a standard SGA suffice here?
> >
> > I believe that ASF guidelines suggest that a discussion should happen
> > first. Once the community gets enough information, we will move to a PMC
> > vote. I was under the impression that once the PMC vote passes, then the
> > SGA should be provided. Or does GridGain need to provide a signed SGA
> right
> > away?
>
> That reminds me of that Pelosi's self-inflicted conundrum of "In order
> to see the bill, we should pass the bill" ;)
>

Haha :)

SGA != code. In my view, the code should be provided to the community for a
review. But I am struggling to see why should an SGA be signed prior to the
community accepting the donation.

Having said that, this is just a technicality, and I believe that GridGain
will be able to proceed with the code donation either way.

D.
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Roman Shaposhnik
On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
<[hidden email]> wrote:

> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <[hidden email]> wrote:
>
>> On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
>> >
>> > Would a standard SGA suffice here?
>> >
>> > I believe that ASF guidelines suggest that a discussion should happen
>> > first. Once the community gets enough information, we will move to a PMC
>> > vote. I was under the impression that once the PMC vote passes, then the
>> > SGA should be provided. Or does GridGain need to provide a signed SGA
>> right
>> > away?
>>
>> That reminds me of that Pelosi's self-inflicted conundrum of "In order
>> to see the bill, we should pass the bill" ;)
>>
>
> Haha :)
>
> SGA != code. In my view, the code should be provided to the community for a
> review. But I am struggling to see why should an SGA be signed prior to the
> community accepting the donation.

There's no such thing as SGA without a reference to a code base.

Also, as I explained -- as a community member I would refuse to look
at the code base that doesn't have a proper licensing attached to it.
SGA established this kind of proper licensing.

Now, SGA is deinetly not the only way to do so, but it is the easiest
and since you'd have to do it anyway the most convenient for the
community.

Thanks,
Roman.
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Konstantin Boudnik
While no one is suggesting an IP trap laid out in the non-SGA'ed code
in this particular case, we don't want to setup a precedent like this.

From the overall ASF perspective I +1 what Roman has just said.

Thanks,
--
  Take care,
Konstantin (Cos) Boudnik


On Wed, Apr 19, 2017 at 11:41 PM, Roman Shaposhnik <[hidden email]> wrote:

> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
> <[hidden email]> wrote:
>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <[hidden email]> wrote:
>>
>>> On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
>>> >
>>> > Would a standard SGA suffice here?
>>> >
>>> > I believe that ASF guidelines suggest that a discussion should happen
>>> > first. Once the community gets enough information, we will move to a PMC
>>> > vote. I was under the impression that once the PMC vote passes, then the
>>> > SGA should be provided. Or does GridGain need to provide a signed SGA
>>> right
>>> > away?
>>>
>>> That reminds me of that Pelosi's self-inflicted conundrum of "In order
>>> to see the bill, we should pass the bill" ;)
>>>
>>
>> Haha :)
>>
>> SGA != code. In my view, the code should be provided to the community for a
>> review. But I am struggling to see why should an SGA be signed prior to the
>> community accepting the donation.
>
> There's no such thing as SGA without a reference to a code base.
>
> Also, as I explained -- as a community member I would refuse to look
> at the code base that doesn't have a proper licensing attached to it.
> SGA established this kind of proper licensing.
>
> Now, SGA is deinetly not the only way to do so, but it is the easiest
> and since you'd have to do it anyway the most convenient for the
> community.
>
> Thanks,
> Roman.
Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dmagda
Folks,

The repository with the donation is ready and available for review:
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

The SGA will be signed and sent on Monday.

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

*Roman S.*, *Cos*, could you help me with this by granting karma or committing the form from under your account?


Denis

> On Apr 25, 2017, at 9:56 AM, Konstantin Boudnik <[hidden email]> wrote:
>
> While no one is suggesting an IP trap laid out in the non-SGA'ed code
> in this particular case, we don't want to setup a precedent like this.
>
> From the overall ASF perspective I +1 what Roman has just said.
>
> Thanks,
> --
>  Take care,
> Konstantin (Cos) Boudnik
>
>
> On Wed, Apr 19, 2017 at 11:41 PM, Roman Shaposhnik <[hidden email]> wrote:
>> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
>> <[hidden email]> wrote:
>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <[hidden email]> wrote:
>>>
>>>> On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
>>>>>
>>>>> Would a standard SGA suffice here?
>>>>>
>>>>> I believe that ASF guidelines suggest that a discussion should happen
>>>>> first. Once the community gets enough information, we will move to a PMC
>>>>> vote. I was under the impression that once the PMC vote passes, then the
>>>>> SGA should be provided. Or does GridGain need to provide a signed SGA
>>>> right
>>>>> away?
>>>>
>>>> That reminds me of that Pelosi's self-inflicted conundrum of "In order
>>>> to see the bill, we should pass the bill" ;)
>>>>
>>>
>>> Haha :)
>>>
>>> SGA != code. In my view, the code should be provided to the community for a
>>> review. But I am struggling to see why should an SGA be signed prior to the
>>> community accepting the donation.
>>
>> There's no such thing as SGA without a reference to a code base.
>>
>> Also, as I explained -- as a community member I would refuse to look
>> at the code base that doesn't have a proper licensing attached to it.
>> SGA established this kind of proper licensing.
>>
>> Now, SGA is deinetly not the only way to do so, but it is the easiest
>> and since you'd have to do it anyway the most convenient for the
>> community.
>>
>> Thanks,
>> Roman.

Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

dmagda
The receipt of the software grant (the persistent store) was acknowledged by Craig Russel.

Now, we need to move on with this

> 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
>
> *Roman S.*, *Cos*, could you help me with this by granting karma or committing the form from under your account?

Roman, Cos, could you help with this?

*Alex G.*, please add Apache 2.0 copyrights to all source files that are going to be donated. Presently there is no copyright at all.

Everyone interested please spend some time exploring the store's docs and sources shared in my previous email. If no one has any concerns I will proceed with the donation formalities.


Denis

> On May 12, 2017, at 2:59 PM, Denis Magda <[hidden email]> wrote:
>
> Folks,
>
> The repository with the donation is ready and available for review:
> 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
>
> The SGA will be signed and sent on Monday.
>
> 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
>
> *Roman S.*, *Cos*, could you help me with this by granting karma or committing the form from under your account?
>
> —
> Denis
>
>> On Apr 25, 2017, at 9:56 AM, Konstantin Boudnik <[hidden email]> wrote:
>>
>> While no one is suggesting an IP trap laid out in the non-SGA'ed code
>> in this particular case, we don't want to setup a precedent like this.
>>
>> From the overall ASF perspective I +1 what Roman has just said.
>>
>> Thanks,
>> --
>> Take care,
>> Konstantin (Cos) Boudnik
>>
>>
>> On Wed, Apr 19, 2017 at 11:41 PM, Roman Shaposhnik <[hidden email]> wrote:
>>> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
>>> <[hidden email]> wrote:
>>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <[hidden email]> wrote:
>>>>
>>>>> On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
>>>>>>
>>>>>> Would a standard SGA suffice here?
>>>>>>
>>>>>> I believe that ASF guidelines suggest that a discussion should happen
>>>>>> first. Once the community gets enough information, we will move to a PMC
>>>>>> vote. I was under the impression that once the PMC vote passes, then the
>>>>>> SGA should be provided. Or does GridGain need to provide a signed SGA
>>>>> right
>>>>>> away?
>>>>>
>>>>> That reminds me of that Pelosi's self-inflicted conundrum of "In order
>>>>> to see the bill, we should pass the bill" ;)
>>>>>
>>>>
>>>> Haha :)
>>>>
>>>> SGA != code. In my view, the code should be provided to the community for a
>>>> review. But I am struggling to see why should an SGA be signed prior to the
>>>> community accepting the donation.
>>>
>>> There's no such thing as SGA without a reference to a code base.
>>>
>>> Also, as I explained -- as a community member I would refuse to look
>>> at the code base that doesn't have a proper licensing attached to it.
>>> SGA established this kind of proper licensing.
>>>
>>> Now, SGA is deinetly not the only way to do so, but it is the easiest
>>> and since you'd have to do it anyway the most convenient for the
>>> community.
>>>
>>> Thanks,
>>> Roman.
>

Reply | Threaded
Open this post in threaded view
|

Re: GridGain Donates Persistent Distributed Store To ASF (Apache Ignite)

Alexey Goncharuk
Denis,

Headers are updated, RAT check is passing now.

2017-05-16 2:37 GMT+03:00 Denis Magda <[hidden email]>:

> The receipt of the software grant (the persistent store) was acknowledged
> by Craig Russel.
>
> Now, we need to move on with this
>
> > 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
> >
> > *Roman S.*, *Cos*, could you help me with this by granting karma or
> committing the form from under your account?
>
> Roman, Cos, could you help with this?
>
> *Alex G.*, please add Apache 2.0 copyrights to all source files that are
> going to be donated. Presently there is no copyright at all.
>
> Everyone interested please spend some time exploring the store's docs and
> sources shared in my previous email. If no one has any concerns I will
> proceed with the donation formalities.
>
> —
> Denis
>
> > On May 12, 2017, at 2:59 PM, Denis Magda <[hidden email]> wrote:
> >
> > Folks,
> >
> > The repository with the donation is ready and available for review:
> > 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
> >
> > The SGA will be signed and sent on Monday.
> >
> > 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
> >
> > *Roman S.*, *Cos*, could you help me with this by granting karma or
> committing the form from under your account?
> >
> > —
> > Denis
> >
> >> On Apr 25, 2017, at 9:56 AM, Konstantin Boudnik <[hidden email]>
> wrote:
> >>
> >> While no one is suggesting an IP trap laid out in the non-SGA'ed code
> >> in this particular case, we don't want to setup a precedent like this.
> >>
> >> From the overall ASF perspective I +1 what Roman has just said.
> >>
> >> Thanks,
> >> --
> >> Take care,
> >> Konstantin (Cos) Boudnik
> >>
> >>
> >> On Wed, Apr 19, 2017 at 11:41 PM, Roman Shaposhnik <
> [hidden email]> wrote:
> >>> On Wed, Apr 19, 2017 at 6:21 PM, Dmitriy Setrakyan
> >>> <[hidden email]> wrote:
> >>>> On Wed, Apr 19, 2017 at 6:00 PM, Konstantin Boudnik <[hidden email]>
> wrote:
> >>>>
> >>>>> On Tue, Apr 18, 2017 at 11:54PM, Dmitriy Setrakyan wrote:
> >>>>>>
> >>>>>> Would a standard SGA suffice here?
> >>>>>>
> >>>>>> I believe that ASF guidelines suggest that a discussion should
> happen
> >>>>>> first. Once the community gets enough information, we will move to
> a PMC
> >>>>>> vote. I was under the impression that once the PMC vote passes,
> then the
> >>>>>> SGA should be provided. Or does GridGain need to provide a signed
> SGA
> >>>>> right
> >>>>>> away?
> >>>>>
> >>>>> That reminds me of that Pelosi's self-inflicted conundrum of "In
> order
> >>>>> to see the bill, we should pass the bill" ;)
> >>>>>
> >>>>
> >>>> Haha :)
> >>>>
> >>>> SGA != code. In my view, the code should be provided to the community
> for a
> >>>> review. But I am struggling to see why should an SGA be signed prior
> to the
> >>>> community accepting the donation.
> >>>
> >>> There's no such thing as SGA without a reference to a code base.
> >>>
> >>> Also, as I explained -- as a community member I would refuse to look
> >>> at the code base that doesn't have a proper licensing attached to it.
> >>> SGA established this kind of proper licensing.
> >>>
> >>> Now, SGA is deinetly not the only way to do so, but it is the easiest
> >>> and since you'd have to do it anyway the most convenient for the
> >>> community.
> >>>
> >>> Thanks,
> >>> Roman.
> >
>
>
12