>>>Did I correctly understand that: we need to revert the previous
patch, update it with the deprecation, and submit it again to master?
Not sure at all. For what? The patch could be improved. But it is
independent, brings new features with documented limitations. If we want
to deprecate somet
Changing my vote to +1, as long as we address the issue of the broken
service metrics as a whole (it requires several code changes as well as
documentation updates).
Details in the discussion thread:
https://lists.apache.org/thread/plbdrq800jts0m8kfjomc7hdsj9rtkzs
-Val
On Thu, Jan 20, 2022 at 11
Vladimir,
Agreed. My point is that the actual issue we want to fix is broken metrics.
Thus, we should have a single ticket/patch *about the broken metrics* that
incorporates all required changes, as well as relevant documentation
updates.
I don't think we need a vote. I will also change mine to +
Sure. This is a simple change. These 2 fixes could go together. And
the doc already has notes of service statistics traits. Ok, might be
even better.
I'm not sure whether we need extra voting for deprecating
'service()' and, as earlier and making 'serviceProxy()' return proxy
every ti
Hi Maksim,
Which patch are you referring to?
-Val
On Mon, Jan 24, 2022 at 10:36 AM Maksim Timonin
wrote:
> Hi guys,
>
> > If we already agreed to deprecate the service() method, then I'm ok with
> the change
>
> As I can see in the previous discussion that Vladimir mentioned [1], there
> was a
Hi guys,
> If we already agreed to deprecate the service() method, then I'm ok with
the change
As I can see in the previous discussion that Vladimir mentioned [1], there
was a proposal for deprecating by Vladimir and Denis Mekhanikov, but there
wasn't a final decision. So I tried to see the `#ser
