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

Reply via email to