Congratulations Nicolo!
Best,
Dave
> On Jan 20, 2023, at 6:57 AM, tison wrote:
>
> Congrats Nico! And well deserved :)
>
> Best,
> tison.
>
>
> Christophe Bornet 于2023年1月20日周五 22:39写道：
>
>> Congrats, Nicolo !
>>
>> Le ven. 20 janv. 2023 à 14:27, Enrico Olivelli a
>> écrit :
>>
>>>
My primary concern with making this the new default is that the cost
of calculating the size is in the synchronization on the managed
ledger, which interrupts writes and reads through that managed ledger
and potentially others in some cases.
If the primary motivation for this PR is to avoid
Hi all,
There's an improved code coverage collection solution in place for the
apache/pulsar master branch. In the past, there were several problems
with the code coverage collection and reporting solution:
- Codecov results were unreliable because of failed uploads
- The Codecov comments on
Congrats Nico! And well deserved :)
Best,
tison.
Christophe Bornet 于2023年1月20日周五 22:39写道：
> Congrats, Nicolo !
>
> Le ven. 20 janv. 2023 à 14:27, Enrico Olivelli a
> écrit :
>
> > Congratulations !
> >
> > Enrico
> >
> > Il giorno ven 20 gen 2023 alle ore 13:36 Lari Hotari
> > ha scritto:
>
Congrats, Nicolo !
Le ven. 20 janv. 2023 à 14:27, Enrico Olivelli a
écrit :
> Congratulations !
>
> Enrico
>
> Il giorno ven 20 gen 2023 alle ore 13:36 Lari Hotari
> ha scritto:
> >
> > Dear Community,
> >
> > We are thrilled to announce that Nicolò Boschi
> > (https://github.com/nicoloboschi)
Congratulations !
Enrico
Il giorno ven 20 gen 2023 alle ore 13:36 Lari Hotari
ha scritto:
>
> Dear Community,
>
> We are thrilled to announce that Nicolò Boschi
> (https://github.com/nicoloboschi) has been invited and has accepted the
> role of member of the Apache Pulsar Project Management
Dear Community,
We are thrilled to announce that Nicolò Boschi
(https://github.com/nicoloboschi) has been invited and has accepted the
role of member of the Apache Pulsar Project Management Committee (PMC).
Nicolò Boschi has been a vital asset to our community, consistently
demonstrating his
>From my understanding we should follow PIP-175.
Actually it has not been officially voted on but we can address that easily.
Following PIP-175, we have to provide the first LTS release which will be
3.0.
The code freeze should happen 3 weeks before the target date.
If we target 3 months from now
Hello community,
I'm starting the VOTE for PIP-236: Record schema in the request and carry
to the broker when subscribing with AUTO_CONSUME schema.
PIP link:
https://github.com/apache/pulsar/issues/19113
Discuss thread:
https://lists.apache.org/thread/v7p88h7grqnbzocw34g6jvxjfw962kfd
We could create the release branch some days after the Chinese holidays.
The idea is to not wait too long before starting the release activities.
Especially since 2.11 has taken so long to release.
Le ven. 20 janv. 2023 à 03:41, Dave Fisher a écrit :
> Christophe,
>
> Given the Chinese New Year
>
>
>
> 2.11 has just been released and the release cycle is set to 3 months.
>
The release cycle wasn't really respected for 2.11...
We already have 5 months worth of features on the master branch and nothing
tells us that the release of 2.12 won't take 5 more months. And if we add 3
months to
> I think the `updateServiceUrl` is not the initial purpose of exposing to the
> Client API.
I agree. We might need an API like
```java
ClientBuilder serviceUrlProvider(ServiceUrlProvider
serviceUrlProvider, Duration interval)
```
But not only the service URL, as you can see, the
+1 (binding)
* verify checksum and signatures
* build from source (Ubuntu 20.04 WSL)
* verify artifacts on Windows (`pulsar.dll` and `pulsarWithDeps.a` for
both x86 and x64 architectures)
* verify rpm, deb, apk packages in x86_64 architecture (`libpulsar.so`
and `libpulsarwithdeps.a`)
All the
13 matches
Mail list logo
