Folks, I would like to highlight a couple of points. 1. Perhaps it is not so crucial where is this fork located if the code is publicly available and can be cloned to another repository easily. We can relocate code and use it at any point in future. 2. Anyways some process must be established for merging changes requiring changes in h2 library. So, I suppose it should be review of changes in 2 repositories.
Now (and beforehand) we use original h2. And how many of us were ever interested what changes were made in h2? So, perhaps for the first time we can start with GG fork? And if later on some problems with that appear we can clone it and use that new fork without much trouble, can't we? ср, 10 июл. 2019 г. в 09:52, Nikolay Izhikov <nizhi...@apache.org>: > > Hello, Denis. > > > Nickolay, as for that fork which is in GG codebase - GridGain is a major > > contributor and maintainer but the others are welcomed to send > > pull-requests. > > Can we make this fork maintained by Ignite Community? > > With all respect to Grid Gain as an author of Apache Ignite I don't like when > some huge dependencies > (incompatible with community-driven analogue) belongs to the enterprise. > > This leads us to the situation when Grid Gain will decide which features will > be added to the SQL engine and which not. > > В Пн, 08/07/2019 в 13:51 -0700, Denis Magda пишет: > > Dmitry, > > > > To make this fully-vendor neutral even at the originating repository level, > > we can create and work with the H2 fork as a separate Github repo (separate > > project governed and maintained by Ignite community). That repo can't be > > part of Ignite due to license mismatch. Thus, during release times, we need > > to assemble a binary (maven artifact) from that fork. > > > > However, it's not clear to me how to use those sources during the dev time? > > It sounds like Ignite can use only the binary (Maven) artifact that has to > > be updated/regenerated if there are any changes. *SQL experts*, could you > > please step in? > > > > Nickolay, as for that fork which is in GG codebase - GridGain is a major > > contributor and maintainer but the others are welcomed to send > > pull-requests. > > > > - > > Denis > > > > > > On Thu, Jul 4, 2019 at 9:26 AM Dmitriy Pavlov <dpav...@apache.org> wrote: > > > > > Hi Denis, > > > > > > As you know, some time ago I've started a discussion about removing > > > dependence from gridgain:shmem. Ignite community seems to be not so much > > > interested in this removal, for now. So once added it could stay here > > > forever. Reverse dependency direction seems to be more natural. It is like > > > the open-core model. > > > > > > I feel more comfortable if all Ignite dependencies are released as part of > > > the Ignite code base, or some open governed project with a license from > > > Category A https://www.apache.org/legal/resolved.html. > > > > > > It is true that H2 has Category B license, so derivative can't be > > > committed > > > into ASF repository. > > > > > > What if we consult with le...@apache.org to find additional ways to donate > > > forked version into ASF codebase? We anyway need their approval because > > > gridgain/h2 has a non-standard license, so we should approve including > > > non-standard licensed component it the product. > > > > > > Sincerely, > > > Dmitriy Pavlov > > > > > > чт, 4 июл. 2019 г. в 18:57, Denis Magda <dma...@apache.org>: > > > > > > > Hi Igniters, > > > > > > > > As you know, Ignite SQL engine is tightly coupled with the H2 database > > > > > > that > > > > provides basic parsing and query execution capabilities. This synergy > > > > > > has > > > > worked well for a while until Ignite SQL engine got a much broader > > > > > > adoption > > > > for all sort of use cases. > > > > > > > > Presently, there is a list of impactful issues and limitations related > > > > to > > > > memory management, distributed engine optimization, and queries planning > > > > that require changes in H2. We've tried to contribute to H2 directly > > > > with > > > > no significant luck - what's needed for our distributed engine is of no > > > > interest to H2 community. At the same time, we can't leave the things as > > > > is, as long as these limitations keep Ignite SQL engine from gradual > > > > evolution. > > > > > > > > As a solution, we created an H2 fork [1] and did all of the required > > > > changes there. We would be happy to include the fork into Ignite source > > > > base, but H2's license (available under dual MPL 2.0 and EPL 1.0) is not > > > > compliant with Apache 2.0. However, if Ignite starts using our maven > > > > artifacts instead of the standard H2's ones, then the licensing issue is > > > > solved. > > > > > > > > Is the community ready to accept this solution and swap the standard H2 > > > > artifact with the one prepared by GridGain? Presently, all of those > > > > improvements are available to GridGain customers, but GridGain wants to > > > > make all of them be available for Ignite community. And that's the only > > > > legal way we've come up with... > > > > > > > > > > > > [1] https://github.com/gridgain/gridgain/tree/master/modules/h2 > > > > > > > > > > > > > > > > -- > > > > - > > > > Denis > > > > -- Best regards, Ivan Pavlukhin
