ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Zinoviev <zaleslaw....@gmail.com>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Tue, 23 Jul 2019 07:16:01 GMT
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 <dmagda@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 <daradurvs@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 Павлухин Иван <vololo100@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.goncharuk@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, Павлухин Иван <vololo100@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, Павлухин Иван <vololo100@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 <dmagda@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.goncharuk@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Denis,
> > > > > > > >
> > > > > > > > Are we ready to present the list to the user list?
> > > > > > > >
> > > > > > > > вт, 2 июл. 2019 г. в 00:27, Denis Magda <dmagda@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
<
> > dpavlov@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 <
> > av@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 <
> > > > > dmagda@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.goncharuk@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 <
> > > > > av@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.goncharuk@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.melnichuk@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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message