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 <dpav...@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 <a...@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 <dma...@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.goncha...@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 <a...@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.goncha...@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.melnic...@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) > > > > > > > > > > > > > > > > > > > > > > > > > > > >
