That may be true. None the less my -0 really liittle impact. My concern is
making sure that should Microsoft GitHub disappear in 20 years we can still
comprehend this discussion. That is all.
Best,
Dave
Sent from my iPhone
> On May 15, 2023, at 10:55 PM, Enrico Olivelli wrote:
>
> Dave,
> I
Dave,
I don't think that we are dropping the discussion on the mailing list.
In that case I would cast a -1.
Enrico
Il giorno mar 16 mag 2023 alle ore 06:27 Dave Fisher
ha scritto:
>
> -0 (binding) having discussions on the mailing list makes it much easier to
> understand decisions years in th
-0 (binding) having discussions on the mailing list makes it much easier to
understand decisions years in the future. Just yesterday I reviewed email
threads in another project from 16 years ago.
Best,
Dave
Sent from my iPhone
> On May 10, 2023, at 3:52 AM, Asaf Mesika wrote:
>
> Hi,
>
> I
+1 binding
Thanks,
Haiting
On Tue, May 16, 2023 at 10:53 AM Zike Yang wrote:
>
> +1 (non-binding)
>
> BR,
> Zike Yang
>
> On Tue, May 16, 2023 at 9:20 AM wrote:
> >
> > +1 (binding)
> >
> > Best,
> > Mattison
> > On May 15, 2023, 15:38 +0800, Enrico Olivelli , wrote:
> > > +1 (binding)
> > >
>
+1 (non-binding)
BR,
Zike Yang
On Tue, May 16, 2023 at 9:20 AM wrote:
>
> +1 (binding)
>
> Best,
> Mattison
> On May 15, 2023, 15:38 +0800, Enrico Olivelli , wrote:
> > +1 (binding)
> >
> > The proposal makes sense to me.
> > Let's try
> >
> > Thanks for carrying on with this initative
> > Enric
Close this vote by
3 binding +1s
* Nozomi
* Penghui
* Mattison
2 non-binding +1s
* Baodi
* Yuto
Thanks,
Yunze
On Tue, May 16, 2023 at 6:58 AM Yunze Xu wrote:
>
> Hi Mattison,
>
> It's not a blocker. It's just because the version of the GTest
> dependency you installed is too high. We can suppo
+1 to me
Thanks,
Yunze
On Sun, May 14, 2023 at 9:28 PM Dave Fisher wrote:
>
> Hi -
>
> I have not looked at all your links but I think this is a great idea. This
> will help everyone pay attention better.
>
> Best,
> Dave
>
> Sent from my iPhone
>
> > On May 14, 2023, at 12:33 AM, tison wrote:
+1 (binding)
Best,
Mattison
On May 15, 2023, 15:38 +0800, Enrico Olivelli , wrote:
> +1 (binding)
>
> The proposal makes sense to me.
> Let's try
>
> Thanks for carrying on with this initative
> Enrico
>
> Il giorno lun 15 mag 2023 alle ore 05:23 Max Xu ha
> scritto:
> >
> > +1 (non-binding)
> >
Hi Mattison,
It's not a blocker. It's just because the version of the GTest
dependency you installed is too high. We can support configuring the
C++ standard with a higher version (e.g. 14, 17) in future.
Thanks,
Yunze
On Mon, May 15, 2023 at 11:08 PM wrote:
>
> I found an issue here. https://g
Hi Penghui,
>> And for the Admin API, we have several supported params
Good point regarding the stats/internal-stats params. I think we can pass
option-map into below GET API for stats so, we can easily enhance if more
options would be added in future and each option data-type can be
documented i
I found an issue here. https://github.com/apache/pulsar-client-cpp/issues/268
Could you help confirm if it is a problem?
+1 (binding)
• Build from source code on MacOS (12.5) with (Intel Core i7)
• Ran pulsar-tests under the tests/ dir
Best,
Mattison
On May 15, 2023, 18:43 +0800, PengHui Li , w
It looks good to me.
Just a minor suggestion about the name of the configuration.
managedLedgerInfoCompressionSizeThreshold ->
managedLedgerInfoCompressionThresholdInBytes
managedCursorInfoCompressionSizeThreshold
-> managedCursorInfoCompressionThresholdInBytes
And is it better to introduce a mi
I think the topic name will not be transmitted to the broker.
The client side used the class generated by the protobuf message.
Or, we can create another class to avoid coupling issues, but it
will introduce more changes and copy data from one structure
to another. For the long-term, I think it sho
I have no strong objection. Just a few questions.
How do we handle the stats/internal-stats of a partitioned topic?
As I understand, the client side will combine the stats/internal-stats
of the partitions? It's better to clarify in the proposal.
Do we need a compatibility section to clarify the b
Hi Asaf,
I have updated the wiki page.
Thanks,
Penghui
On Wed, May 10, 2023 at 12:53 AM Asaf Mesika wrote:
> Who can help me update in https://github.com/apache/pulsar/wiki
> that it has passed?
>
>
> On Tue, May 9, 2023 at 5:01 PM Asaf Mesika wrote:
>
> > The vote has passed with 4 of bindin
+1 (binding)
- Checked the signature
- Build from source codes on MacOS (13.3.1) with (M2 Pro)
- Ran pulsar-tests under the tests/ dir
Regards,
Penghui
On Thu, May 11, 2023 at 6:43 PM Nozomi Kurihara wrote:
> +1 (binding)
>
> - verified signature and checksum
> - built from source codes on Cen
Well useful fields really depend on the applications and different usecases
require different fields and it can eventually end up covering all.
Therefore, we should try to create a protocol which can transport
stats/internal and client should be able to represent that data to
applications in a stan
+1 (binding)
The proposal makes sense to me.
Let's try
Thanks for carrying on with this initative
Enrico
Il giorno lun 15 mag 2023 alle ore 05:23 Max Xu ha scritto:
>
> +1 (non-binding)
>
> Thanks for driving this helpful proposal!
>
> Best,
> Max Xu
>
>
> On Wed, May 10, 2023 at 6:52 PM Asaf M
Asaf,
thanks for contributing in this area.
Metrics are a fundamental feature of Pulsar.
Currently I find it very awkward to maintain metrics, and also I see
it as a problem to support only Prometheus.
Regarding your proposal, IIRC in the past someone else proposed to
support other metrics system
I understand the need for this PIP and I support it, but I have some
questions/open points.
I wonder if we should define a smaller subset of the stats/internal
stats to serve to the clients using this new Request/Response.
Maybe it is better to serve only the minimal amount of data that is useful.
20 matches
Mail list logo
