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) > > > > > > > > > > > > > > > > > > > > >
