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 Thu, 11 Jul 2019 08:06:23 GMT
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 <dpavlov@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 <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