ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@gridgain.com>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Wed, 24 Jul 2019 23:11:37 GMT
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