Thanks for the clarification, will try to vote чт, 25 июл. 2019 г. в 04:11, Denis Magda <dma...@gridgain.com>:
> Alexey, > > I've changed format on the wiki so that every community member can cast +1 > and -1 vote explaining his/her stance. This should help us to filter out > those integrations that everyone agrees to discontinue vs. those that are > controversial. Please, *everyone interested* share your opinion by putting > a name and +1/-1 in these tables: > > - Integrations for discontinuation: > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation > - APIs for removal: > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval > > > > 1. Exclude Spatial Indexes from API for removal (I don't know internal > > issues, but is I'd like this kind of index) > > > Both spatial and full-text search indexes provide limit support and not > integrated with Ignite's memory architecture. It's better for us to remove > them in Ignite 3.0 (that will go with a new API to be proposed soon by Alex > Goncharuk) and rebuild from scratch in 3.1/3.2. > > > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation > > because I've ready to try support them (or dive in this question) I think > > no so many work to support them or move to the separate module like > > BigDataTools Integrations > > > Why don't we have them as separate Github projects that can be updated both > by the community members and independent developers? I just don't want this > to be a burden of the community to test and maintain it for every release. > > 3. Annotations based configuration of SQL - we should be careful with that, > > I suppose it's useful feature > > > Alex Goncharuk should propose a new API for 3.0 soon. > > 4. Ignite Messaging should be combined together with Kafka/different MQ > > integration into one module for messaging support > > > I wouldn't do this because 3rd party MQs go with their own versions that > start conflicting over the time. For instance, we already have several > modules for Hibernate and Spring Data integrations. To fix that, we just > need to store integrations in separate repos and do forks if a new > conflicting version has to be supported but there is still significant > usage of the old one. > > -- > Denis Magda > > > On Tue, Jul 23, 2019 at 3:16 AM Alexey Zinoviev <zaleslaw....@gmail.com> > wrote: > > > I have a few ideas, maybe somebody will support me > > 1. Exclude Spatial Indexes from API for removal (I don't know internal > > issues, but is I'd like this kind of index) > > 2. Exclude Storm, Flume, Flink from Integrations for Discontinuation > > because I've ready to try support them (or dive in this question) I think > > no so many work to support them or move to the separate module like > > BigDataTools Integrations > > 3. Annotations based configuration of SQL - we should be careful with > that, > > I suppose it's useful feature > > 4. Ignite Messaging should be combined together with Kafka/different MQ > > integration into one module for messaging support > > > > What do you think guys? > > > > пн, 22 июл. 2019 г. в 22:51, Denis Magda <dma...@apache.org>: > > > > > Igniters, > > > > > > I did the first run through the wishlist and selected integrations and > > APIs > > > for discontinuation. My suggestion would be to use IEP-36 > > (Modularization) > > > page for the final list that we'll send to the user list for feedback: > > > > > > - Integrations for discontinuation: > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-IntegrationsforDiscontinuation > > > - APIs for removal: > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-36%3A+Modularization#IEP-36:Modularization-APIsforRemoval > > > > > > Please check those lists and let us know if you have any arguments > > against > > > discontinuation/removal of X. Also, if you believe that something > listed > > in > > > the wishlist should be added to the EIP then let's discuss that. > > > Personally, I see the whishlist as a page with ideas while the IEP a > > final > > > plan for action. > > > > > > > > > - > > > Denis > > > > > > > > > On Mon, Jul 22, 2019 at 12:05 AM Vyacheslav Daradur < > daradu...@gmail.com > > > > > > wrote: > > > > > > > I think all agreed items should be marked @Deprecated in the code > > > > base, so we will be able to remove them transparently for the > > > > end-users. > > > > > > > > On Mon, Jul 22, 2019 at 9:32 AM Павлухин Иван <vololo...@gmail.com> > > > wrote: > > > > > > > > > > Alex, > > > > > > > > > > I already added a couple of items to wishlist [1]. > > > > > > > > > > Yes, I agree that the process should be iterative. But I am > confused > > > > > on what stage we are in a current interation? I suppose that Denis > is > > > > > going to present a list of removal candidates which we as > developers > > > > > agreed on. And should not we have that list already available > > > > > somewhere as a document? Now I see an infromation scattered in this > > > > > thread and the wishlist [1]. And it is not easy to me to realize > > where > > > > > we are now. > > > > > > > > > > [1] > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > > > > > > > > > > чт, 18 июл. 2019 г. в 18:14, Alexey Goncharuk < > > > > alexey.goncha...@gmail.com>: > > > > > > > > > > > > Ivan, > > > > > > > > > > > > The list is not final, we can still discuss and add more points > to > > be > > > > > > cleaned in 3.0. The more clear and understandable the API will > be, > > > the > > > > > > better. This thread was intended to draft the removal scope for > 3.0 > > > > and to > > > > > > understand which portions will be definitely removed. > > > > > > > > > > > > > > > > > > ср, 17 июл. 2019 г. в 15:26, Павлухин Иван <vololo...@gmail.com > >: > > > > > > > > > > > > > Also, I did not quite get the point about JSR107 (JCache). From > > > time > > > > > > > to time I see on user-list threads where Ignite is used along > > with > > > > > > > Spring annotation-based cache integration. I suppose it > requires > > > > > > > JCache interfaces. What is crucially wrong with supporting it? > > > > > > > > > > > > > > ср, 17 июл. 2019 г. в 15:19, Павлухин Иван < > vololo...@gmail.com > > >: > > > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > > > > > Sorry if I am repeating something. I checked a page [1] and > > have > > > > not > > > > > > > > found several items. > > > > > > > > 1. I thought that there was an agreement of dropping OLD > > service > > > > grid, > > > > > > > > was not it? > > > > > > > > 2. Also IndexingSpi seems to me as a candidate for removal. > > > > > > > > > > > > > > > > Should I add those items to the page? Or is there another > page > > > > > > > > containing items to be removed that we agreed on? > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0+Wishlist > > > > > > > > > > > > > > > > ср, 17 июл. 2019 г. в 02:00, Denis Magda <dma...@apache.org > >: > > > > > > > > > > > > > > > > > > Alex, Igniters, sorry for a delay. Got swamped with other > > > duties. > > > > > > > > > > > > > > > > > > Does it wait till the next week? I'll make sure to dedicate > > > some > > > > time > > > > > > > for > > > > > > > > > that. Or if we'd like to run faster then I'll appreciate if > > > > someone > > > > > > > else > > > > > > > > > steps in and prepares a list this week. I'll help to review > > and > > > > > > > solidify it. > > > > > > > > > > > > > > > > > > - > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jul 16, 2019 at 7:58 AM Alexey Goncharuk < > > > > > > > alexey.goncha...@gmail.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Denis, > > > > > > > > > > > > > > > > > > > > Are we ready to present the list to the user list? > > > > > > > > > > > > > > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda < > dma...@apache.org > > >: > > > > > > > > > > > > > > > > > > > > > I wouldn't kick off dozens of voting discussions. > > Instead, > > > > the > > > > > > > content on > > > > > > > > > > > the wiki page needs to be cleaned and rearranged. This > > will > > > > make > > > > > > > the > > > > > > > > > > > content readable and comprehensible. I can do that. > > > > > > > > > > > > > > > > > > > > > > Next, let's ask the user community for an opinion. > After > > > > reviewing > > > > > > > and > > > > > > > > > > > incorporating the latter we can do one more dev list > > > > discussion > > > > > > > with the > > > > > > > > > > > last call for opinions. Next, will be the voting time. > If > > > > there is > > > > > > > a > > > > > > > > > > > feature someone from the dev list is against of > removing, > > > > then we > > > > > > > can > > > > > > > > > > start > > > > > > > > > > > a separate vote for it later. But let's get into those > > > cases > > > > first. > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jul 1, 2019 at 1:47 AM Dmitriy Pavlov < > > > > dpav...@apache.org> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > I propose each removal should have separated formal > > vote > > > > thread > > > > > > > with > > > > > > > > > > > > consensus approval (since it is code modification). > > > > > > > > > > > > > > > > > > > > > > > > This means a single binding objection with > > justification > > > > is a > > > > > > > blocker > > > > > > > > > > for > > > > > > > > > > > > removal. > > > > > > > > > > > > > > > > > > > > > > > > We need separation to let community members pick up > an > > > > > > > interesting > > > > > > > > > > topic > > > > > > > > > > > > from email subject. Not all members reading carefully > > > each > > > > post > > > > > > > in > > > > > > > > > > > > mile-long threads. > > > > > > > > > > > > > > > > > > > > > > > > пн, 1 июл. 2019 г. в 11:17, Anton Vinogradov < > > > > a...@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > > > +1 to email survey with following types of votes > > > > > > > > > > > > > - silence (agree with all proposed removals) > > > > > > > > > > > > > - we have to keep XXX because ... > > > > > > > > > > > > > > > > > > > > > > > > > > As a result, will gain lists > > > > > > > > > > > > > "to be removed" - no one objected > > > > > > > > > > > > > "can be removed" - single objection > > > > > > > > > > > > > "should be kept" - multi objections > > > > > > > > > > > > > > > > > > > > > > > > > > Denis or Dmitry Pavlov, could you please lead this > > > > thread? > > > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Jun 29, 2019 at 12:27 AM Denis Magda < > > > > > > > dma...@apache.org> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Alex, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would do an email survey to hear an opinion of > > why > > > > someone > > > > > > > > > > > believes a > > > > > > > > > > > > > > feature A has to stay. It makes sense to ask > about > > > the > > > > APIs > > > > > > > to be > > > > > > > > > > > > removed > > > > > > > > > > > > > > as well as integrations to go out of community > > > support > > > > [1] > > > > > > > in the > > > > > > > > > > > same > > > > > > > > > > > > > > thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Has everyone expressed an opinion? If yes, I can > go > > > > ahead and > > > > > > > > > > format > > > > > > > > > > > > the > > > > > > > > > > > > > > wishlist page and make it structured for the user > > > > thread. > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-Modularization-td42486.html > > > > > > > > > > > > > > - > > > > > > > > > > > > > > Denis > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 28, 2019 at 8:54 AM Alexey Goncharuk > < > > > > > > > > > > > > > > alexey.goncha...@gmail.com> > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anton, good point. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you have any idea how we can keep track of > the > > > > voting? > > > > > > > Should > > > > > > > > > > we > > > > > > > > > > > > > > launch > > > > > > > > > > > > > > > a google survey or survey monkey? Voting by > > email? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > пт, 28 июн. 2019 г. в 11:24, Anton Vinogradov < > > > > > > > a...@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Alexey, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank's for keeping an eye on page updates. > > > > > > > > > > > > > > > > Near Caches is not a bad feature, but it > should > > > be > > > > used > > > > > > > with > > > > > > > > > > > > caution. > > > > > > > > > > > > > > > > At least we have to explain how it works on > > > > readme.io, > > > > > > > why and > > > > > > > > > > > > when > > > > > > > > > > > > > it > > > > > > > > > > > > > > > > should be used because usage can drop the > > > > performance > > > > > > > instead > > > > > > > > > > of > > > > > > > > > > > > > > > increasing > > > > > > > > > > > > > > > > it. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anyway, I added near caches because I never > > heard > > > > > > > someone used > > > > > > > > > > > them > > > > > > > > > > > > > > > > meaningfully, not like a silver bullet. > > > > > > > > > > > > > > > > So, that's just a proposal :) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also, I'd like to propose to have some voting > > > > about full > > > > > > > list > > > > > > > > > > > later > > > > > > > > > > > > > to > > > > > > > > > > > > > > > gain > > > > > > > > > > > > > > > > "must be removed", "can be removed" and > "should > > > be > > > > kept" > > > > > > > lists. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 27, 2019 at 1:03 PM Alexey > > Goncharuk > > > < > > > > > > > > > > > > > > > > alexey.goncha...@gmail.com> > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Anton, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to pull-up the discussion > > > regarding > > > > the > > > > > > > near > > > > > > > > > > > caches > > > > > > > > > > > > - > > > > > > > > > > > > > I > > > > > > > > > > > > > > > > cannot > > > > > > > > > > > > > > > > > agree this is a feature that needs to be > > > > removed. Near > > > > > > > caches > > > > > > > > > > > > > provide > > > > > > > > > > > > > > > > > significant read performance improvements > > and, > > > > to the > > > > > > > best of > > > > > > > > > > > my > > > > > > > > > > > > > > > > knowledge, > > > > > > > > > > > > > > > > > are used in several cases in production. > Can > > > you > > > > > > > elaborate on > > > > > > > > > > > the > > > > > > > > > > > > > > > > > shortcomings you faced? Maybe we can > improve > > > both > > > > > > > internal > > > > > > > > > > code > > > > > > > > > > > > and > > > > > > > > > > > > > > > user > > > > > > > > > > > > > > > > > experience? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > пт, 21 июн. 2019 г. в 10:42, Dmitry > > Melnichuk < > > > > > > > > > > > > > > > > > dmitry.melnic...@nobitlost.com>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dmitry, > > > > > > > > > > > > > > > > > > As a Python thin client developer, I > think > > > that > > > > > > > separate > > > > > > > > > > > > > repository > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > > > > a truly great idea! > > > > > > > > > > > > > > > > > > On Tue, 2019-06-18 at 21:29 +0300, > Dmitriy > > > > Pavlov > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > - Move to separate repositories: thin > > > > clients (at > > > > > > > least > > > > > > > > > > > > > non-Java > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ones) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Best regards, > > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Best regards, > > > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Best regards, > > > > > Ivan Pavlukhin > > > > > > > > > > > > > > > > -- > > > > Best Regards, Vyacheslav D. > > > > > > > > > >
