ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nikolay Izhikov <nizhi...@apache.org>
Subject Re: [discussion] using custom build of H2 for Ignite
Date Wed, 10 Jul 2019 11:12:54 GMT
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 Павлухин Иван <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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message