ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Mon, 22 Jul 2019 19:51:13 GMT
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