[discussion] using custom build of H2 for Ignite

[Denis Magda <dm...@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

Re: [discussion] using custom build of H2 for Ignite

[Denis Magda <dm...@apache.org>]

Dmitry,

Let's not flood this discussion with topics unrelated to the subj. Please
find my notes on some of your statements below. If you believe the notes
don't solve your concerns, please start or restart another discussion.

Overall, it seems that a separate vendor-neutral Github repository is a
good solution for our community. Any other thoughts before we proceed?




The notes:


> We already have locked in relation to
> - DEB/RPM package release (I don't know if PMC knows how to prepare it),
> - we have Node.js packages without releasing procedure.
>

Instructions for Node.JS/Python/PHP were shared by contributors over email,
and we forgot to put them on wiki. As both of us know, Igor Sapego agreed
to move everything to wiki. DEB/RPM instructions are to be provided by
another GridGain contributor - Peter Ivanov. I believe the work is in
progress.

Please, for the sake of efficiency and to finish 2.7.5 post-release
procedures, swap your ASF hat with a GridGain for a moment to follow up
with Igor and Peter to expedite the resolution. It might be a matter of a
short verbal conversation and as a result, the Ignite community will have
all the instructions documented.

- we have some gridgain:shmem with unclear reasoning behind,


Please see my previous response on this matter. The source code belongs to
Ignite and anybody can rebuild this library and name it the way the
community likes. With my GridGain hat on for a minute, the company is not
ready to invest its time on artifact renaming just because of "gridgain"
name in it. If other contributors that have no affiliation with GridGain
would like to do that please go ahead:
http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-ignite-core-dependecies-tp41096p41132.html

-
Denis


On Thu, Jul 11, 2019 at 1:06 AM Dmitriy Pavlov <dp...@apache.org> wrote:

> Denis, Igniters,
>
> I want to add 2 cents to make it as clear as possible
>
> Every contributor and committer (whatever company he is working for) is
> appreciated and I encourage all GridGain'ers to participate.
>
> Everyone participates as an individual. So if someone provides some tool in
> his or her own GitHub - it may be ok in some cases. We're still using
> abbrev plugin hosted in my public individual GitHub repository.
>
> But once we have something which is prepared and released for Ignite
> outside of the project, by any company - we may face a situation that
> - the release is not possible because we need a release of dependency first
> - a company changed its priorities, the company does not consider this
> project is strategic anymore. This happens from time to time in OpenSource.
>
> And if release is not possible - what is the point? what's the point to
> discuss, to contribute code? It won't reach users.  Impossibility to
> release Ignite = shortest way to the Attic.
>
> Ignite PMC members should prevent such outside locks, and protect the
> project from commercial interests influence. This helps to increase
> diversity and community building, as well.
>
> We already have locked in relation to
> - DEB/RPM package release (I don't know if PMC knows how to prepare it),
> - we have some gridgain:shmem with unclear reasoning behind,
> - we have Node.js packages without releasing procedure.
>
> I hope we will overcome it soon and we don't need to start the healing
> process.
>
> Nevertheless, we will not add new (dead)locks. I hope it is enough
> justification for -1.
>
> Sincerely,
> Dmitriy Pavlov
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
> чт, 11 июл. 2019 г. в 00:03, Dmitriy Pavlov <dp...@apache.org>:
>
> > Denis, I'm not negative in relation to  GridGain, if Sberbank will
> suggest
> > Ignite (or any other Apache project I'm involved too) code to be
> dependent
> > on
> > 'com.sberbank.whatsoever.coollibrary'
> > binary, they can count on my veto, as well.
> >
> > There is no difference in company suggesting this: 'com.microsoft',
> > 'com.intel' - I see no difference there.
> >
> > Disclaimer: Opinions expressed in this email are those of the author,
> > and do not necessarily represent the views of any company the author
> > might be affiliated with at the moment of writing.
> >
> > ср, 10 июл. 2019 г. в 23:13, Denis Magda <dm...@apache.org>:
> >
> >> Ok, folks, let's create a separate Github repo for the H2 fork and
> ensure
> >> the binaries of that fork are used by Ignite. As for the discussion with
> >> ASF legal, nobody suggested any alternatives and I'm signing off that
> >> discussion:
> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Place-for-MPL-2-0-EPL-1-0-source-code-in-ASF-ecosystem-td42604.html#a42621
> >>
> >> Dmitriy, I don't fully understand your negative attitude towards
> GridGain.
> >> That's just one of the biggest contributors to Ignite because of
> >> historical
> >> reasons - Ignite was donated by this vendor and GridGain is trying to
> make
> >> this community diversified allocating its own time and resources. I'm
> >> pretty sure that many ASF projects are in the same situation - that has
> to
> >> be a first vendor who does most of the technological changes and helps
> to
> >> grow the community. Luckily, these days another vendor supports Ignite
> >> which is Sberbank, hopefully, more vendors to come. Personally, I do
> >> believe that most of successful open source projects depend on vendors
> who
> >> invest $$$ and let their employees work on open source daily.
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Wed, Jul 10, 2019 at 8:03 AM Павлухин Иван <vo...@gmail.com>
> >> wrote:
> >>
> >> > Dmitriy,
> >> >
> >> > Thank you for sharing your vision.
> >> >
> >> > Actually I think that an agreement within the community is the most
> >> > important thing.
> >> >
> >> > ср, 10 июл. 2019 г. в 17:44, Dmitriy Pavlov <dp...@apache.org>:
> >> > >
> >> > > Hi Ivan,
> >> > >
> >> > >
> >> > >
> >> > > I don’t need a policy to clearly understand that the Apache project
> >> stops
> >> > > to be healthy once it is controlled by one entity. This is related
> to
> >> > > governance, not to OSI approved license (if a lib is open-source or
> >> not).
> >> > >
> >> > >
> >> > >
> >> > > Apache mission - Create software for the public good.
> >> > >
> >> > > Apache project is:
> >> > >
> >> > > - Open Source, commercial-friendly Licence,
> >> > >
> >> > > - Open Governance (clear, documented leader election),
> >> > >
> >> > > - Open Brand (Brand owner is always ASF, it is a non-profit, charity
> >> > > organization).
> >> > >
> >> > >
> >> > >
> >> > > And once community adds a dependency to any vendor-controlled and
> >> > released
> >> > > artifact I suppose it is not anymore for the public good, it is for
> >> good
> >> > of
> >> > > vendor. A goal can be to be advertized using this open-source
> project
> >> and
> >> > > the Apache brand. Vendor in some cases want just Apache brand, and
> >> rarely
> >> > > shares Apache principles and Apache Way.
> >> > >
> >> > >
> >> > >
> >> > > Maybe Konstantin could explain better than me, why the community
> >> should
> >> > not
> >> > > accept vendor-provided dependencies.
> >> > >
> >> > >
> >> > > Hopefully, Cos can also evaluate idea separate GitHub repository
> with
> >> > full
> >> > > control from PMC (root credentials is placed to private SVN + clear
> >> > release
> >> > > procedure).
> >> > >
> >> > >
> >> > >
> >> > > Sincerely,
> >> > >
> >> > > Dmitriy Pavlov
> >> > >
> >> > > Disclaimer: Opinions expressed in this email are those of the
> author,
> >> > > and do not necessarily represent the views of any company the author
> >> > > might be affiliated with at the moment of writing.
> >> > >
> >> > > ср, 10 июл. 2019 г. в 15:06, Nikolay Izhikov <ni...@apache.org>:
> >> > >
> >> > > > 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 <dpavlov@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.gerzhedowich@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, Павлухин Иван <
> >> vololo100@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 <
> >> > nizhikov@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 <
> >> > > > nizhikov@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 <
> >> > > > > > >
> >> > > > > > > dpavlov@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 legal@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 <
> >> > > > dmagda@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
> >> > > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> >
> >> >
> >> >
> >> > --
> >> > Best regards,
> >> > Ivan Pavlukhin
> >> >
> >>
> >
>

Re: [discussion] using custom build of H2 for Ignite

[Dmitriy Pavlov <dp...@apache.org>]

Denis, Igniters,

I want to add 2 cents to make it as clear as possible

Every contributor and committer (whatever company he is working for) is
appreciated and I encourage all GridGain'ers to participate.

Everyone participates as an individual. So if someone provides some tool in
his or her own GitHub - it may be ok in some cases. We're still using
abbrev plugin hosted in my public individual GitHub repository.

But once we have something which is prepared and released for Ignite
outside of the project, by any company - we may face a situation that
- the release is not possible because we need a release of dependency first
- a company changed its priorities, the company does not consider this
project is strategic anymore. This happens from time to time in OpenSource.

And if release is not possible - what is the point? what's the point to
discuss, to contribute code? It won't reach users.  Impossibility to
release Ignite = shortest way to the Attic.

Ignite PMC members should prevent such outside locks, and protect the
project from commercial interests influence. This helps to increase
diversity and community building, as well.

We already have locked in relation to
- DEB/RPM package release (I don't know if PMC knows how to prepare it),
- we have some gridgain:shmem with unclear reasoning behind,
- we have Node.js packages without releasing procedure.

I hope we will overcome it soon and we don't need to start the healing
process.

Nevertheless, we will not add new (dead)locks. I hope it is enough
justification for -1.

Sincerely,
Dmitriy Pavlov

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

чт, 11 июл. 2019 г. в 00:03, Dmitriy Pavlov <dp...@apache.org>:

> Denis, I'm not negative in relation to  GridGain, if Sberbank will suggest
> Ignite (or any other Apache project I'm involved too) code to be dependent
> on
> 'com.sberbank.whatsoever.coollibrary'
> binary, they can count on my veto, as well.
>
> There is no difference in company suggesting this: 'com.microsoft',
> 'com.intel' - I see no difference there.
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
> ср, 10 июл. 2019 г. в 23:13, Denis Magda <dm...@apache.org>:
>
>> Ok, folks, let's create a separate Github repo for the H2 fork and ensure
>> the binaries of that fork are used by Ignite. As for the discussion with
>> ASF legal, nobody suggested any alternatives and I'm signing off that
>> discussion:
>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Place-for-MPL-2-0-EPL-1-0-source-code-in-ASF-ecosystem-td42604.html#a42621
>>
>> Dmitriy, I don't fully understand your negative attitude towards GridGain.
>> That's just one of the biggest contributors to Ignite because of
>> historical
>> reasons - Ignite was donated by this vendor and GridGain is trying to make
>> this community diversified allocating its own time and resources. I'm
>> pretty sure that many ASF projects are in the same situation - that has to
>> be a first vendor who does most of the technological changes and helps to
>> grow the community. Luckily, these days another vendor supports Ignite
>> which is Sberbank, hopefully, more vendors to come. Personally, I do
>> believe that most of successful open source projects depend on vendors who
>> invest $$$ and let their employees work on open source daily.
>>
>> -
>> Denis
>>
>>
>> On Wed, Jul 10, 2019 at 8:03 AM Павлухин Иван <vo...@gmail.com>
>> wrote:
>>
>> > Dmitriy,
>> >
>> > Thank you for sharing your vision.
>> >
>> > Actually I think that an agreement within the community is the most
>> > important thing.
>> >
>> > ср, 10 июл. 2019 г. в 17:44, Dmitriy Pavlov <dp...@apache.org>:
>> > >
>> > > Hi Ivan,
>> > >
>> > >
>> > >
>> > > I don’t need a policy to clearly understand that the Apache project
>> stops
>> > > to be healthy once it is controlled by one entity. This is related to
>> > > governance, not to OSI approved license (if a lib is open-source or
>> not).
>> > >
>> > >
>> > >
>> > > Apache mission - Create software for the public good.
>> > >
>> > > Apache project is:
>> > >
>> > > - Open Source, commercial-friendly Licence,
>> > >
>> > > - Open Governance (clear, documented leader election),
>> > >
>> > > - Open Brand (Brand owner is always ASF, it is a non-profit, charity
>> > > organization).
>> > >
>> > >
>> > >
>> > > And once community adds a dependency to any vendor-controlled and
>> > released
>> > > artifact I suppose it is not anymore for the public good, it is for
>> good
>> > of
>> > > vendor. A goal can be to be advertized using this open-source project
>> and
>> > > the Apache brand. Vendor in some cases want just Apache brand, and
>> rarely
>> > > shares Apache principles and Apache Way.
>> > >
>> > >
>> > >
>> > > Maybe Konstantin could explain better than me, why the community
>> should
>> > not
>> > > accept vendor-provided dependencies.
>> > >
>> > >
>> > > Hopefully, Cos can also evaluate idea separate GitHub repository with
>> > full
>> > > control from PMC (root credentials is placed to private SVN + clear
>> > release
>> > > procedure).
>> > >
>> > >
>> > >
>> > > Sincerely,
>> > >
>> > > Dmitriy Pavlov
>> > >
>> > > Disclaimer: Opinions expressed in this email are those of the author,
>> > > and do not necessarily represent the views of any company the author
>> > > might be affiliated with at the moment of writing.
>> > >
>> > > ср, 10 июл. 2019 г. в 15:06, Nikolay Izhikov <ni...@apache.org>:
>> > >
>> > > > 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 <dp...@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.gerzhedowich@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, Павлухин Иван <
>> vololo100@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 <
>> > nizhikov@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 <
>> > > > nizhikov@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 <
>> > > > > > >
>> > > > > > > dpavlov@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 legal@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 <
>> > > > dmagda@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
>> > > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Ivan Pavlukhin
>> >
>>
>

Re: [discussion] using custom build of H2 for Ignite

[Dmitriy Pavlov <dp...@apache.org>]

Denis, I'm not negative in relation to  GridGain, if Sberbank will suggest
Ignite (or any other Apache project I'm involved too) code to be dependent
on
'com.sberbank.whatsoever.coollibrary'
binary, they can count on my veto, as well.

There is no difference in company suggesting this: 'com.microsoft',
'com.intel' - I see no difference there.

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

ср, 10 июл. 2019 г. в 23:13, Denis Magda <dm...@apache.org>:

> Ok, folks, let's create a separate Github repo for the H2 fork and ensure
> the binaries of that fork are used by Ignite. As for the discussion with
> ASF legal, nobody suggested any alternatives and I'm signing off that
> discussion:
>
> http://apache-ignite-developers.2346864.n4.nabble.com/Place-for-MPL-2-0-EPL-1-0-source-code-in-ASF-ecosystem-td42604.html#a42621
>
> Dmitriy, I don't fully understand your negative attitude towards GridGain.
> That's just one of the biggest contributors to Ignite because of historical
> reasons - Ignite was donated by this vendor and GridGain is trying to make
> this community diversified allocating its own time and resources. I'm
> pretty sure that many ASF projects are in the same situation - that has to
> be a first vendor who does most of the technological changes and helps to
> grow the community. Luckily, these days another vendor supports Ignite
> which is Sberbank, hopefully, more vendors to come. Personally, I do
> believe that most of successful open source projects depend on vendors who
> invest $$$ and let their employees work on open source daily.
>
> -
> Denis
>
>
> On Wed, Jul 10, 2019 at 8:03 AM Павлухин Иван <vo...@gmail.com> wrote:
>
> > Dmitriy,
> >
> > Thank you for sharing your vision.
> >
> > Actually I think that an agreement within the community is the most
> > important thing.
> >
> > ср, 10 июл. 2019 г. в 17:44, Dmitriy Pavlov <dp...@apache.org>:
> > >
> > > Hi Ivan,
> > >
> > >
> > >
> > > I don’t need a policy to clearly understand that the Apache project
> stops
> > > to be healthy once it is controlled by one entity. This is related to
> > > governance, not to OSI approved license (if a lib is open-source or
> not).
> > >
> > >
> > >
> > > Apache mission - Create software for the public good.
> > >
> > > Apache project is:
> > >
> > > - Open Source, commercial-friendly Licence,
> > >
> > > - Open Governance (clear, documented leader election),
> > >
> > > - Open Brand (Brand owner is always ASF, it is a non-profit, charity
> > > organization).
> > >
> > >
> > >
> > > And once community adds a dependency to any vendor-controlled and
> > released
> > > artifact I suppose it is not anymore for the public good, it is for
> good
> > of
> > > vendor. A goal can be to be advertized using this open-source project
> and
> > > the Apache brand. Vendor in some cases want just Apache brand, and
> rarely
> > > shares Apache principles and Apache Way.
> > >
> > >
> > >
> > > Maybe Konstantin could explain better than me, why the community should
> > not
> > > accept vendor-provided dependencies.
> > >
> > >
> > > Hopefully, Cos can also evaluate idea separate GitHub repository with
> > full
> > > control from PMC (root credentials is placed to private SVN + clear
> > release
> > > procedure).
> > >
> > >
> > >
> > > Sincerely,
> > >
> > > Dmitriy Pavlov
> > >
> > > Disclaimer: Opinions expressed in this email are those of the author,
> > > and do not necessarily represent the views of any company the author
> > > might be affiliated with at the moment of writing.
> > >
> > > ср, 10 июл. 2019 г. в 15:06, Nikolay Izhikov <ni...@apache.org>:
> > >
> > > > 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 <dp...@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, Юрий <ju...@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, Павлухин Иван <
> vololo100@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 <
> > nizhikov@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 <
> > > > nizhikov@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 <
> > > > > > >
> > > > > > > dpavlov@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 legal@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 <
> > > > dmagda@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
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best regards,
> > Ivan Pavlukhin
> >
>

Re: [discussion] using custom build of H2 for Ignite

[Denis Magda <dm...@apache.org>]

Ok, folks, let's create a separate Github repo for the H2 fork and ensure
the binaries of that fork are used by Ignite. As for the discussion with
ASF legal, nobody suggested any alternatives and I'm signing off that
discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Place-for-MPL-2-0-EPL-1-0-source-code-in-ASF-ecosystem-td42604.html#a42621

Dmitriy, I don't fully understand your negative attitude towards GridGain.
That's just one of the biggest contributors to Ignite because of historical
reasons - Ignite was donated by this vendor and GridGain is trying to make
this community diversified allocating its own time and resources. I'm
pretty sure that many ASF projects are in the same situation - that has to
be a first vendor who does most of the technological changes and helps to
grow the community. Luckily, these days another vendor supports Ignite
which is Sberbank, hopefully, more vendors to come. Personally, I do
believe that most of successful open source projects depend on vendors who
invest $$$ and let their employees work on open source daily.

-
Denis


On Wed, Jul 10, 2019 at 8:03 AM Павлухин Иван <vo...@gmail.com> wrote:

> Dmitriy,
>
> Thank you for sharing your vision.
>
> Actually I think that an agreement within the community is the most
> important thing.
>
> ср, 10 июл. 2019 г. в 17:44, Dmitriy Pavlov <dp...@apache.org>:
> >
> > Hi Ivan,
> >
> >
> >
> > I don’t need a policy to clearly understand that the Apache project stops
> > to be healthy once it is controlled by one entity. This is related to
> > governance, not to OSI approved license (if a lib is open-source or not).
> >
> >
> >
> > Apache mission - Create software for the public good.
> >
> > Apache project is:
> >
> > - Open Source, commercial-friendly Licence,
> >
> > - Open Governance (clear, documented leader election),
> >
> > - Open Brand (Brand owner is always ASF, it is a non-profit, charity
> > organization).
> >
> >
> >
> > And once community adds a dependency to any vendor-controlled and
> released
> > artifact I suppose it is not anymore for the public good, it is for good
> of
> > vendor. A goal can be to be advertized using this open-source project and
> > the Apache brand. Vendor in some cases want just Apache brand, and rarely
> > shares Apache principles and Apache Way.
> >
> >
> >
> > Maybe Konstantin could explain better than me, why the community should
> not
> > accept vendor-provided dependencies.
> >
> >
> > Hopefully, Cos can also evaluate idea separate GitHub repository with
> full
> > control from PMC (root credentials is placed to private SVN + clear
> release
> > procedure).
> >
> >
> >
> > Sincerely,
> >
> > Dmitriy Pavlov
> >
> > Disclaimer: Opinions expressed in this email are those of the author,
> > and do not necessarily represent the views of any company the author
> > might be affiliated with at the moment of writing.
> >
> > ср, 10 июл. 2019 г. в 15:06, Nikolay Izhikov <ni...@apache.org>:
> >
> > > 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 <dp...@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, Юрий <ju...@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, Павлухин Иван <vololo100@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 <
> nizhikov@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 <
> > > nizhikov@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 <
> > > > > >
> > > > > > dpavlov@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 legal@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 <
> > > dmagda@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
> > > > > >
> > > >
> > > >
> > > >
> > >
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: [discussion] using custom build of H2 for Ignite

[Павлухин Иван <vo...@gmail.com>]

Dmitriy,

Thank you for sharing your vision.

Actually I think that an agreement within the community is the most
important thing.

ср, 10 июл. 2019 г. в 17:44, Dmitriy Pavlov <dp...@apache.org>:
>
> Hi Ivan,
>
>
>
> I don’t need a policy to clearly understand that the Apache project stops
> to be healthy once it is controlled by one entity. This is related to
> governance, not to OSI approved license (if a lib is open-source or not).
>
>
>
> Apache mission - Create software for the public good.
>
> Apache project is:
>
> - Open Source, commercial-friendly Licence,
>
> - Open Governance (clear, documented leader election),
>
> - Open Brand (Brand owner is always ASF, it is a non-profit, charity
> organization).
>
>
>
> And once community adds a dependency to any vendor-controlled and released
> artifact I suppose it is not anymore for the public good, it is for good of
> vendor. A goal can be to be advertized using this open-source project and
> the Apache brand. Vendor in some cases want just Apache brand, and rarely
> shares Apache principles and Apache Way.
>
>
>
> Maybe Konstantin could explain better than me, why the community should not
> accept vendor-provided dependencies.
>
>
> Hopefully, Cos can also evaluate idea separate GitHub repository with full
> control from PMC (root credentials is placed to private SVN + clear release
> procedure).
>
>
>
> Sincerely,
>
> Dmitriy Pavlov
>
> Disclaimer: Opinions expressed in this email are those of the author,
> and do not necessarily represent the views of any company the author
> might be affiliated with at the moment of writing.
>
> ср, 10 июл. 2019 г. в 15:06, Nikolay Izhikov <ni...@apache.org>:
>
> > 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 <dp...@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, Юрий <ju...@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, Павлухин Иван <vo...@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 <nizhikov@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 <
> > nizhikov@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 <
> > > > >
> > > > > dpavlov@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 legal@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 <
> > dmagda@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
> > > > >
> > >
> > >
> > >
> >



-- 
Best regards,
Ivan Pavlukhin

Re: [discussion] using custom build of H2 for Ignite

[Dmitriy Pavlov <dp...@apache.org>]

Hi Ivan,



I don’t need a policy to clearly understand that the Apache project stops
to be healthy once it is controlled by one entity. This is related to
governance, not to OSI approved license (if a lib is open-source or not).



Apache mission - Create software for the public good.

Apache project is:

- Open Source, commercial-friendly Licence,

- Open Governance (clear, documented leader election),

- Open Brand (Brand owner is always ASF, it is a non-profit, charity
organization).



And once community adds a dependency to any vendor-controlled and released
artifact I suppose it is not anymore for the public good, it is for good of
vendor. A goal can be to be advertized using this open-source project and
the Apache brand. Vendor in some cases want just Apache brand, and rarely
shares Apache principles and Apache Way.



Maybe Konstantin could explain better than me, why the community should not
accept vendor-provided dependencies.


Hopefully, Cos can also evaluate idea separate GitHub repository with full
control from PMC (root credentials is placed to private SVN + clear release
procedure).



Sincerely,

Dmitriy Pavlov

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.

ср, 10 июл. 2019 г. в 15:06, Nikolay Izhikov <ni...@apache.org>:

> 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 <dp...@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, Юрий <ju...@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, Павлухин Иван <vo...@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 <nizhikov@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 <
> nizhikov@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 <
> > > >
> > > > dpavlov@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 legal@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 <
> dmagda@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
> > > >
> >
> >
> >
>

Re: [discussion] using custom build of H2 for Ignite

[Nikolay Izhikov <ni...@apache.org>]

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 <dp...@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, Юрий <ju...@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, Павлухин Иван <vo...@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 <ni...@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 <ni...@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 <
> > > 
> > > dpavlov@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 legal@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 <dm...@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
> > > 
> 
> 
> 

Re: [discussion] using custom build of H2 for Ignite

[Павлухин Иван <vo...@gmail.com>]

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 <dp...@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, Юрий <ju...@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, Павлухин Иван <vo...@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 <ni...@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 <ni...@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 <
> > dpavlov@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 legal@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 <dm...@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
> >



-- 
Best regards,
Ivan Pavlukhin

Re: [discussion] using custom build of H2 for Ignite

[Dmitriy Pavlov <dp...@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, Юрий <ju...@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, Павлухин Иван <vo...@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 <ni...@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 <ni...@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 <
> dpavlov@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 legal@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 <dm...@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
>

Re: [discussion] using custom build of H2 for Ignite

[Юрий <ju...@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, Павлухин Иван <vo...@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 <ni...@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 <ni...@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 <dp...@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 legal@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 <dm...@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

Re: [discussion] using custom build of H2 for Ignite

[Nikolay Izhikov <ni...@apache.org>]

Ivan.

> Could you please elaborate why is it "closed source"?

This fork sources will changed on the purpose and willness of Grid Gain not
Ignite community.

> Actually, my only point is that we can do it at any point later, cannot
we?

Why we should close H2 fork from Ignite commiters in the first place?
Please, name one reason to do it?

ср, 10 июля 2019 г., 13:08 Павлухин Иван <vo...@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 <ni...@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 <ni...@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 <dp...@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 legal@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 <dm...@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
>

Re: [discussion] using custom build of H2 for Ignite

[Павлухин Иван <vo...@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 <ni...@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 <ni...@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 <dp...@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 legal@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 <dm...@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

Re: [discussion] using custom build of H2 for Ignite

[Nikolay Izhikov <ni...@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 <ni...@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 <dp...@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 legal@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 <dm...@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
> > > > > 
> 
> 
> 

Re: [discussion] using custom build of H2 for Ignite

[Павлухин Иван <vo...@gmail.com>]

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 <ni...@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 <dp...@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 legal@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 <dm...@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

Re: [discussion] using custom build of H2 for Ignite

[Nikolay Izhikov <ni...@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 <dp...@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 legal@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 <dm...@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
> > > 

Re: [discussion] using custom build of H2 for Ignite

[Dmitriy Pavlov <dp...@apache.org>]

Denis, thank you for the reply, making this vendor-neutral separate project
and repository where Apache committers are in sync with GitHub
collaborators could work for me.

I still suggest legal@apache.org approve this once we agree on this.

And I'm sorry for hijacking this topic, but as Apache-fanatic I prefer
Apache projects, and I pretty sure most of us know about
https://calcite.apache.org/
 can we consider it as it keeps out the project in the Apache ecosystem?

Sincerely,

пн, 8 июл. 2019 г. в 23:51, Denis Magda <dm...@apache.org>:

> 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 <dp...@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 legal@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 <dm...@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
> > >
> >
>

Re: [discussion] using custom build of H2 for Ignite

[Denis Magda <dm...@apache.org>]

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 <dp...@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 legal@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 <dm...@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
> >
>

Re: [discussion] using custom build of H2 for Ignite

[Nikolay Izhikov <ni...@apache.org>]

Hello, Denis.

Who can contribute to gridgain/h2?

Who are commiters of gridgain/h2?


В Чт, 04/07/2019 в 19:26 +0300, Dmitriy Pavlov пишет:
> 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 legal@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 <dm...@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
> > 

Re: [discussion] using custom build of H2 for Ignite

[Dmitriy Pavlov <dp...@apache.org>]

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 legal@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 <dm...@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
>