Re: [DISCUSS] Revisit PIP voting max time

I have similar concerns for it. Some PIPs might not get enough attention. Generally I agree with the proposal that a PIP should be treated as "approved" if - there is at least 1 binding +1 vote - there is no binding -1 vote - the vote has started for over a month Additionally, if a PMC member gave

Re: [DISCUSS] PIP-381: Handle large PositionInfo state

>> I am sorry I haven't followed up andI am not able to spend much time. I don't want to block your proposal Rajan. I totally understand and I am sure it was not intentional by you to block this PR. However, there are multiple other PRs related to key-shared sub, stats, cursor performance, and ot

[DISCUSS] Revisit PIP voting max time

Hi, I have created this PIP a few months back and it is having relatively a simple and non-breaking change, and voting is open for a while but this PIP still has not received the required number of binding VOTE to move forward. Another recent example is PIP-271 which is a very useful and simple ap

Re: [VOTE] PIP-381: Handle large PositionInfo state

+1 (binding) Enrico Il Lun 23 Set 2024, 19:41 Andrey Yegorov ha scritto: > Hi, > > I'd like to start the voting thread for PIP-381: Handle large PositionInfo > state. > > Proposal PR: https://github.com/apache/pulsar/pull/23328 > Discussion thread: > https://lists.apache.org/thread/8sm0h804v591

Re: [DISCUSS] PIP-381: Handle large PositionInfo state

vote thread: https://lists.apache.org/thread/q31fx0rox9tdt34xsmo1ol1l76q8vk99 On Mon, Sep 23, 2024 at 10:37 AM Andrey Yegorov wrote: > Thank you all for the feedback. > > My take from this is the feature is needed and the general consensus is to > proceed with it. > I'll start a vote thread. > >

[VOTE] PIP-381: Handle large PositionInfo state

Hi, I'd like to start the voting thread for PIP-381: Handle large PositionInfo state. Proposal PR: https://github.com/apache/pulsar/pull/23328 Discussion thread: https://lists.apache.org/thread/8sm0h804v5914zowghrqxr92fp7c255d -- Andrey

Re: [DISCUSS] PIP-381: Handle large PositionInfo state

Thank you all for the feedback. My take from this is the feature is needed and the general consensus is to proceed with it. I'll start a vote thread. Compression of the state (already used if enabled) and a more compact serialization format (as in Rajan's PR) alone are partial solutions that move

Re: [DISCUSS] gRPC & Protobuf library upgrades (related to addressing CVE-2023-32732)

I've created https://github.com/apache/pulsar/issues/23341 to track the work to address CVE-2024-7254 . -Lari On 2024/09/23 11:56:50 Lari Hotari wrote: > Protobuf contains a new high-level CVE, described in > https://github.com/advisories/GHSA-735f-pc8j-v9w8. > > The problem in Pulsar is that

Re: [DISCUSS] gRPC & Protobuf library upgrades (related to addressing CVE-2023-32732)

Protobuf contains a new high-level CVE, described in https://github.com/advisories/GHSA-735f-pc8j-v9w8. The problem in Pulsar is that Protobuf cannot be upgraded unless it's first upgraded in Bookkeeper. I have made a PR to the Bookkeeper master branch: https://github.com/apache/bookkeeper/pull

[VOTE] Pulsar Client Go Release 0.14.0 Candidate 1

Hi everyone, Please review and vote on the release candidate #1 for the version 0.14.0, as follows: [ ] +1, Approve the release [ ] -1, Do not approve the release (please provide specific comments) This is the first release candidate for Apache Pulsar Go client, version 0.14.0. It fixes the follo

[DISCUSS] BookieRackAffinityMapping revert into sync way to avoid broker lost rack information issue

Hi all, Pulsar new version may lose bookie rack information. The problem does not occur in pulsar-2.9, but occurs after pulsar-2.10. I raise two issues to analyze the problem, https://github.com/apache/pulsar/issues/23282, https://github.com/apache/pulsar/issues/23330. There are two different case