Hi Michael, Enrico
> The identifier is the name. The topics have `-DLQ` and `-RETRY`
> as suffixes, which makes them "special" (which reminds me of this
> thread [0]). We could choose to always make these non partitioned
> or to make them configurable in some other way.
I changed the design like
Sure, I will create a PR and update the issue when development is done
Asaf Mesika 于2023年5月31日周三 16:39写道：
> Pengcheng, would you be willing to be the inaugural PIP in our PIP
> submission process?
> Yesterday, we officially moved from the GitHub issue to a markdown file for
> PIP submissions.
>
pr is created: https://github.com/apache/pulsar/pull/20455
Pengcheng Jiang 于2023年6月1日周四 15:49写道：
> Sure, I will create a PR and update the issue when development is done
>
> Asaf Mesika 于2023年5月31日周三 16:39写道：
>
>> Pengcheng, would you be willing to be the inaugural PIP in our PIP
>> submission
I understand that you can't build a release process due to Apache
foundation rules, that makes it mandatory to release something you built on
your own machine.
On Wed, May 31, 2023 at 5:54 PM Enrico Olivelli wrote:
> Il giorno mer 31 mag 2023 alle ore 16:50 Michael Marshall
> ha scritto:
> >
>
> The best solution is to make the build repeatable. IIUC, that will let
us build all of the artifacts using CI instead of personal machines,
which removes this class of errors.
I don't think this issue is related to where the docker image was
built. It has nothing to do with caching and nothing t
Hi all,
I would like to propose releasing the Pulsar 3.0.1.
Currently, there are 95 new commits in branch-3.0:
https://github.com/apache/pulsar/compare/v3.0.0...branch-3.0
And we have found that there is an issue with the pulsar-all:3.0.0
image: https://lists.apache.org/thread/phcrm6czhyo7po6qnc
> The best solution is to make the build repeatable. IIUC, that will let
us build all of the artifacts using CI instead of personal machines,
which removes this class of errors.
I agree! But I don't know if Apache rules allow this operation, and if
so, I recommend using the CI to publish our proje
The ASF only counts the source releases the official releases. All binaries
including docker images should be for convenience only.
Even the image needs to go through a vote, you can of course build and
stage the image with any method in hand. The problem is where we can share
a build environment
I agree with Zike that the root cause of this specific case is that 3.0
changes the docker images artifacts and we don't update the process.
Before we correct the process to ensure that human can follow, automation
only automatically make mistakes.
tison 于2023年6月2日 周五00:53写道：
> The ASF only cou
Hi,
Here is some background - [1][2].
Briefly, @dave2wave and I agree on Enable "Always suggest updating pull
request branches" for pulsar-site GitHub repo. We did the same for the main
repo while reverting later. Now INFRA team members want to see an explicit
consensus among the community to do
Hi Pulsar Community,
I am writing to start the discussion on PIP 269 to add an epoch of cursor
to discard outdated reading to enable hostname
PR with PIP contents: https://github.com/apache/pulsar/pull/20469
Since there are some tables in the PIP text, you can see the content in the
issue https:
Thanks for driving this proposal!
nit - You don't need an issue to render the content, one can already
preview render markdown version in PR or on your branch.
Best,
tison.
Yubiao Feng 于2023年6月2日周五 10:01写道：
> Hi Pulsar Community,
>
> I am writing to start the discussion on PIP 269 to add an e
I committed a change directly to the main branch when I was expecting to be
forced to create a PR.
There are times when a quick commit can make life easier, but PRs make it
easier to follow changes.
Best,
Dave
Sent from my iPhone
> On Jun 1, 2023, at 6:12 PM, tison wrote:
>
> Hi,
>
> Here
> I committed a change directly to the main branch when I was expecting to
be forced to create a PR.
This seems a different topic.
What we're talking about is "Always suggest updating pull request branches
",
... while you're referring to "Require a pull request before merging".
Best,
tison.
While we can vote for these two simultaneously to ask for INFRA members to
enable them at once. I agree that it can help since PRs is more open than
commit only changes - I experience that even in a review after merge
pattern a PR is more easily to get comments and response while commits are
always
I think that INFRA would accept a DISCUSSION that looks for LAZY CONSENSUS.
Sent from my iPhone
> On Jun 1, 2023, at 7:18 PM, tison wrote:
>
> While we can vote for these two simultaneously to ask for INFRA members to
> enable them at once. I agree that it can help since PRs is more open than
Dear Pulsar Enthusiasts,
We are thrilled to announce the upcoming Apache Pulsar Meetup Japan #5 on
June 30th, a virtual(Zoom) event dedicated to Apache Pulsar. This event
aims to provide insights into the functionalities, features, use cases, and
best practices of Apache Pulsar through presentatio
Thanks for sharing this information! Looking forward to the event :D
Best,
tison.
Nozomi Kurihara 于2023年6月2日周五 11:04写道：
> Dear Pulsar Enthusiasts,
>
> We are thrilled to announce the upcoming Apache Pulsar Meetup Japan #5 on
> June 30th, a virtual(Zoom) event dedicated to Apache Pulsar. This e
OK. Let me share the updates to INFRA members then.
BTW, I saw this direct commit that may be better to go through a PR for
better visibility :D
-
https://github.com/apache/pulsar-site/commit/04d5b02c48a7a49f9159d8c6f5c82e2537ae2caa
Best,
tison.
Dave Fisher 于2023年6月2日周五 10:26写道：
> I think th
19 matches
Mail list logo
