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
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 G
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.microso
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-
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 :
>
> Hi Ivan,
>
>
>
> I don’t need a policy to clearly understand that the Apache project stops
> to be healthy once it is
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 proj
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
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
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
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 firs
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
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 agr
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,
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
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 lik
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 le...@apache.org approve this once we agree on this.
And I'm sorry for hijacking this topic, but as Apache-fa
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 time
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 muc
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
th
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
20 matches
Mail list logo
