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 <dpav...@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 <dpav...@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 <dma...@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 Павлухин Иван <vololo...@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 <dpav...@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 <nizhi...@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 <dpav...@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.gerzhedow...@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, Павлухин Иван < > >> vololo...@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 < > >> > nizhi...@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 < > >> > > > nizhi...@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 < > >> > > > > > > > >> > > > > > > dpav...@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 le...@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 < > >> > > > dma...@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 > >> > > >> > > >
