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. > > > > > >
