Ivan. > I suppose that I did not ever claim such thing
Thanks for clarifing :) > GitHub project outside any commercial company accounts, there all Apache > committers added as collaborators may work. > Sounds nice for me as well. +1 from me if it compatible with Apache policies. В Ср, 10/07/2019 в 14:59 +0300, Павлухин Иван пишет: > Nikolay, > > Why we should close H2 fork from Ignite commiters in the first place? > > I suppose that I did not ever claim such thing. I think we are > discussing various options. And ones might be simpler and others might > be harder. > > Dmitriy, > > To my shame I am not very competent in licensing and related > questions. I mostly think about how the problem can be solved > technically. If something is against Apache policies then we > definitely can go with it (would be great to get a reference to such > policies). > > > GitHub project outside any commercial company accounts, there all Apache > > committers added as collaborators may work. > > Sounds nice for me as well. > > And I would like to return to the beginning. > 1. What do we want? Improve SQL in Ignite. > 2. How do we want to do it? In the most convenient "legal" way. > > Perhaps there are other bright thoughts how to keep it simple? > > ср, 10 июл. 2019 г. в 14:18, Dmitriy Pavlov <dpav...@apache.org>: > > > > Wearing the hat of Apache Ignite PMC: > > I'm against starting with dependency on GridGain code in any case. Gridgain > > can do its own forks of both. > > > > We all know how much influence the company has on the community and adding > > one more (I remind there is gridgain:shmem) > > means the open-governed solution is dependent on closely-governed. Would > > you use something open-source if it depends on binaries? I don't care about > > license in that case. > > > > you can count on '-1' from my side. > > > > GitHub project outside any commercial company accounts, there all Apache > > committers added as collaborators may work. > > > > > > ср, 10 июл. 2019 г. в 13:28, Юрий <jury.gerzhedow...@gmail.com>: > > > > > Agree with Ivan. > > > > > > We can start work with H2 fork owned by GG and decide change it later in > > > case it will bring some issues to Ignite community. Currently I don't see > > > any issues here. > > > > > > I'm worried about the issue, with process to synchonize changes H2 fork > > > and > > > Ignite. As possible solution it could be as follow: > > > Ignite has dependency only to released version of H2 fork. > > > Then we could modify the fork in any time without compatibility issues. > > > When new feature is ready to use by Ignite need to modify code of Ignite > > > and change dependency version for H2 fork. > > > However H2 for in the case should be release more often than Ignite. > > > > > > WDYT? > > > > > > ср, 10 июл. 2019 г. в 13:08, Павлухин Иван <vololo...@gmail.com>: > > > > > > > Nikolay, > > > > > > > > Could you please elaborate why is it "closed source"? > > > > > > > > > What the difference for the Ignite community? > > > > > > > > The difference is similar to using version X and version Y of the same > > > > library. Version Y might be better. > > > > > > > > > I think all Ignite commiters should have write priveledges to H2 fork. > > > > > > > > I agree, it is quite natural. Actually, my only point is that we can > > > > do it at any point later, cannot we? > > > > > > > > ср, 10 июл. 2019 г. в 12:25, Nikolay Izhikov <nizhi...@apache.org>: > > > > > > > > > > Ivan > > > > > > > > > > We have closed source code dependency for now owned by H2 owners. > > > > > With new fork we will have the same closed dependency owned by Grid > > > > > > Gain. > > > > > > > > > > What the difference for the Ignite community? > > > > > > > > > > > 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. > > > > > > > > > > The question is - *Who can apply those changes*. > > > > > > > > > > I think all Ignite commiters should have write priveledges to H2 fork. > > > > > > > > > > В Ср, 10/07/2019 в 11:30 +0300, Павлухин Иван пишет: > > > > > > 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 > > > > > > > > > > > > > -- > > > Живи с улыбкой! :D > > > > > >
signature.asc
Description: This is a digitally signed message part
