Hi Yes I would support a shorter voting period for a patch release on an existing LTS branch for Camel Quarkus. With the intent to deliver bug fixes and CVEs quicker in the hands of the end users.
On Tue, Jan 7, 2025 at 10:00 AM Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > 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 > > > -- Claus Ibsen ----------------- @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
