ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: [DISCUSSION] Ignite 3.0 and to be removed list
Date Tue, 16 Jul 2019 14:58:27 GMT
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)
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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