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 Thu, 25 Jul 2019 08:20:54 GMT
Thanks for the clarification, will try to vote

чт, 25 июл. 2019 г. в 04:11, Denis Magda <dmagda@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.sin@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 <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