IMHO, the Apache Voting Rules (and the Apache Way) imply that the community works in a good faith. There would be reasons the release vote does not consider binding -1 vote as veto, but I'd avoid interpreting the rule as more +1 than -1 wins the game. It's a collaborative effort - there are also "post release" efforts to happen after the major/minor release - we need marketing/devrel to make the release be blessed enough.
I totally agree that there was no issue with RC3 voting, from the voting rule perspective, especially the rule specifying that the release manager is a decision maker taking responsibility for the decision. But given it's a collaborate effort, IMHO the below should have happened ideally: 1. A new ticket is filed with "blocker" priority instead of "critical" to be very clear about intention - this is important now, because we have a bunch of critical tickets and we almost ignore it - we fail to catch up with downgrading the severity even if the severity is marked by the reporter who isn't committer+. This is also something we need to put some effort into, but that needs dedicated effort and it's uneasy to keep up. 2. When voter casts -1 and refers to a ticket, voter also describes the impact of not including the issue in this release as well, so that the release manager does not need to read through the issue and interpret the severity by themselves. If there is a conflict on interpretation of severity, it is expected to debate it within the VOTE thread, and VOTE shouldn't be concluded as passed if conflict isn't resolved. It becomes much harder for the release manager to make a judgement on the severity, since we now have a bunch of components. Each voter is expected to help the release manager to make a right decision - still, in the rule, the release manager is still the decision maker of the vote, not the voter, so voters would love to put some effort into describing the impact in a way easier to understand, and persuading the release manager. 3. Release manager is open to spare more time (may imply more release candidates) to include fixes for all blockers unless there is no conflict on severity. Release manager is open to discuss severity if there are blocker tickets (even the case where we had blocker tickets before RC0 to begin with), and be respectful to the component owners for justification of severity rather than trying to justify severity by themselves if the component is out of their knowledge/expertise. I hope this makes sense to everyone. Thanks, Jungtaek Lim (HeartSaVioR) On Thu, Dec 18, 2025 at 2:53 AM Mark Hamstra <[email protected]> wrote: > > 4. During an RC vote, new blockers may still be raised if they are > confirmed regressions. > > I will take issue with this if it is interpreted as "if and only if > they are confirmed regressions." Sufficiently significant issues > should always be capable of blocking a release regardless of whether > or not they are strictly regressions. Of course, there are judgements > to be made as to whether an issue is "sufficiently significant" and > therefore is actually a blocker. An issue being a regression is one > good indication that it is a blocker, but it is not the only one, and > an issue not being a regression should not always exclude it from > being a blocker. For example, if a significant security issue is > discovered during a release process, that release train should halt > until we have a fix for the issue or some other compromise has been > thoroughly discussed and voted on. Similarly, other claimed blockers > should get at least some acknowledgement, discussion and evaluation, > not just a curt dismissal along the lines of "it's not a regression, > therefore we are moving on." > > --------------------------------------------------------------------- > To unsubscribe e-mail: [email protected] > >
