ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitriy Pavlov <dpav...@apache.org>
Subject Re: [discussion] using custom build of H2 for Ignite
Date Wed, 10 Jul 2019 21:03:33 GMT
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 <dmagda@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 Павлухин Иван <vololo100@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 <dpavlov@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 <nizhikov@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
> >
>

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