Hi all, a quick note on CI usage, since it affects everyone’s build times. ASF projects share a CI budget, and a single Pulsar CI build uses roughly 10 hours of GitHub Runner VM time. Once we hit an invisible usage limit, builds get throttled for everyone: they don’t start immediately and are queued instead. Since the throttling is invisible, other ASF projects may also be spending the shared budget, so our usage isn’t the only cause. We just have to make sure we don’t cause overusage. A few things that help: • Keep WIP work in your fork’s “Personal CI” and open the PR to apache/pulsar only when it’s ready for review. • Open new PRs after your previous ones have been merged, so there are fewer WIP PRs open at once. • Prioritize your PRs so the most impactful ones get merged first. When overall activity is lower, that’s a good time to push more. • Address all open review comments at once before pushing. Separate commits in the PR branch are fine, but pushing them together triggers fewer builds. • Avoid leaving PRs open for a long time. They need origin/master merged in to make sure merging doesn’t introduce regressions, and that triggers another full build, which is another 10 hours of VM time. Reducing build times is also important for cutting spending, and the test time reduction PRs by @void-ptr974 will help a lot with this. Thanks, everyone, for helping keep CI healthy!

Okay, I finished the CI in my personal repo and then made the commit. However, I had accumulated many follow-up PRs and submitted them all at once, which indeed caused some issues. Sorry about that. I will change my approach to submit a few every two days instead of all at once. 😂