> 3. Ensure this label does not exist when starting a vote.
I think we can add a link about the "release/blocker" label in the
VOTE template.
And for anyone who is voting, can open the link and check if there is
a release blocker.
Thanks,
Haiting
On Thu, Apr 27, 2023 at 3:29 PM Yunze Xu wrote:
Yes, it should be documented how we should use the "release/blocker" label.
1. Add this label for the PR that should be included in the release candidate.
2. After it's merged, cherry-pick it into the release branch and
remove the label.
3. Ensure this label does not exist when starting a vote.
Th
Good catch!
I'll trigger a new RC.
For the future we need to have a procedure to not allow this kind of issues.
Maybe we should remove "release/blocker" labels once they are merged
into the release branch and ensure there are 0 "release/blocker"
before cutting the release ?
Le jeu. 27 avr. 2023 à
-1 (binding)
There was a fix [1] for a regression that was not cherry-picked into
branch-3.0 and here [2] is an example failure that was affected by the
regression. This PR was labeled as "release/blocker" so I
cherry-picked it into branch-3.0. Then we need to trigger another
candidate release.
[
+1
Checked signatures, standalone & docker images.
--
Matteo Merli
On Tue, Apr 25, 2023 at 7:38 AM Christophe Bornet
wrote:
> This is the third release candidate for Apache Pulsar, version 3.0.0.
>
> It fixes the following issues:
> https://github.com/apache/pulsar/milestone/34?closed=1
>
>
