Hi, Some comments: - It's not possible to veto a release (veto is only valid for code change). So -1 doesn't mean veto a release, the release can pass if you have more +1 binding than -1 binding (see https://www.apache.org/legal/release-policy.html#release-approval) - The 72 hours vote period on release is recommended ("Release votes SHOULD remain open for at least 72 hours."). With a clear statement, it's possible to reduce the voting period. Why not using the vote period as a freeze period then (that's the first intention) ?
I have a long discussion with Quarkus guys about the release process and vote (with Clement and Max). I think we can already "implement" the process without changing the recommended one, just use a 48h voting period. Regards JB On Mon, Jan 6, 2025 at 10:28 AM Peter Palaga <ppal...@redhat.com> wrote: > > Hi, > > me, Zineb and James would like to propose a new voting process for LTS > patch releases of Camel Quarkus. > > TL;DR: We propose to introduce an LTS branch freezing period for > reviews, testing and resolving upgrade issues related to new LTS micro > releases of Camel or Quarkus. Further, after the freezing period is > over, we propose, to have a quorum-based completion with the minimum of > three +1 votes for releasing the staging repository. Please read the > details below. > > *Scope* > > We would like to solely change the voting process of Camel Quarkus LTS > .z releases that come after .0. > > Our current aim is neither changing the voting process for other Camel > subprojects nor changing the voting process for the first .0 release in > the given LTS stream or other .z releases that are not LTS. > > Examples: > > Camel Quarkus 3.18.0: stays with 72 hrs voting, because it will not be > an LTS release > > Camel Quarkus 3.18.1: stays with 72 hrs voting, because it is not a part > of an LTS stream > > Camel Quarkus 3.20.0 LTS: stays with 72 hrs voting, because it is the > first release in an LTS stream > > Camel Quarkus 3.20.1 LTS, 3.20.2 LTS, ... : new voting process, because > those are releases in an LTS stream with z > 0 > > *Motivation* > > We see the importance of 72 hours voting periods for feature releases, > such as 3.18.0 or 3.19.0. They give everybody a chance to review an test > the release, as well as they help to establish consensus and trust > between various participants who may have different interests. > > While new features and major changes happen in minor and major releases, > the LTS streams are supposed to stay stable, delivering mostly and > primarily bug fixes and CVE fixes. New features in patch releases are > very rare and are still mostly motivated by fixing bugs (think a new > configuration flag allowing to fall back to an old, insecure or buggy > behavior for users not wanting to accept a backwards incompatibility > introduced by a fix). > > Camel Quarkus keeps high standards of code coverage, CI testing as well > as reviews of changes coming via pull requests. Direct pushing to main > and maintenance branches happens very rarely. > > Given the care of the maintainers and the conservativeness of the > backporting process for LTS branches, we believe, the need for testing > and establishing trust through a 72 hours voting period does not hold > much for patch LTS releases. The trust and stability of the code base is > much more and better guaranteed by those processes and good practices. > We actually strive to keep our main and maintenance branches releasable > (at least from the quality point of view) at any time. > > Last but not least, all end users of Camel Quarkus would benefit from > shorter voting period by getting the fixes faster. This is important not > only for security fixes but also for all other kinds of fixes, be it > regressions, performance issues or other common bugs. > > *The new voting mechanism* > > We would like to adhere to a stable release schedule with a branch > freeze period to ensure transparency, predictability and participation: > > Day D-1: the release plan is announced stating when the LTS branch > freeze starts and ends. > Day D: a 48 hours LTS branch freeze period starts. During that period > > * All interested parties are welcome to review and test the branch. > * Camel PMC members (binding) and other interested parties > (non-binding) may veto the release for any relevant reason, such as > quality, performance, etc. > * Only fixes of following kinds are allowed during the freeze period: > o Fixes related to vetos > o Fixes related to possibly expected Camel core or Quarkus > releases. Those releases may or may not happen around the time > of releasing Camel Quarkus. Camel Quarkus LTS patch releases > would be possible also without those. If there is no Camel or > Quarkus release expected, the branch freeze period may be shortened. > > Day D+2: Once the freeze period is over, all veto and/or upgrade issues > are resolved and after any expected Camel or Quarkus releases are out, > the Camel Quarkus release is staged and the voting is opened. > > Given the LTS branch freeze period and other process guarantees we > mentioned earlier, we would like to propose the the quorum-based > completion for discussion. Our proposal is that at least three binding > +1 votes would be required for a valid release and there would have to > be no unresolved -1 (veto) votes. > > We believe this proposal brings a sound process guaranteeing not only > faster delivery of the value to end users, but still ensuring > transparency and participation while by no means harming the quality of > our software. > > I kindly ask for your feedback. > > Thanks, > > Peter Palaga, James Netherton, Zineb Bendhiba >
