I'm not so sure. The start of the freeze period could determine the beginning of the voting period. If there are no code changes, I think that would be fine. As indicated on the board mailing list, the goal of the 72h period is to give sufficient time for every PMC member to review. A code freeze period does the same imho.
However, if there are code changes, such as upgrading Camel to a different minor version or a non-trivial fix, it would be hard to justify, as this is an important change that could have impacts. The original email of this thread states: > Only fixes of following kinds are allowed during the freeze period: > o Fixes related to vetos > I think it's the amount of code changed that warrants a release cancellation or not, not the fact that the problem was discovered during the release period. > 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. In the 72h period, a Camel core release cannot happen if it was not planned already (and even the vote started before). If the Camel core vote has started, then it is possible to point to the staged repository. Is the main problem with Quarkus releases ? Guillaume Le jeu. 9 janv. 2025 à 09:30, Andrea Cosentino <anco...@gmail.com> a écrit : > > Looking at the thread created by JB on board ML, it doesn't seem feasible > to implement this workflow. > > We could cut the vote time period only in special cases, like security > fixes or something like that. > > It cannot be a generalized approach. > > Il giorno mar 7 gen 2025 alle ore 14:57 Jean-Baptiste Onofré < > j...@nanthrax.net> ha scritto: > > > Hi > > > > If you announced 72h min voting period and you close the vote before > > 72h, that's a problem. > > If we clearly state (like security fix, etc) that the vote is 48h, > > it's totally fine. For instance, a bunch of ServiceMix Bundles > > releases have been made with 48h voting period. > > > > Let me discuss to update the voting page on the website clearly describing > > this. > > > > Regards > > JB > > > > On Tue, Jan 7, 2025 at 10:06 AM Andrea Cosentino <anco...@gmail.com> > > wrote: > > > > > > The last time we tried to close a release before 72 hours, Christoph Dutz > > > from the board reach out to us and told us we cannot cut the vote period > > > and we clearly stated that in the vote. > > > > > > So, there must be a clear direction or a clear statement, from the board, > > > about this. > > > > > > Otherwise, it will always be an interpretation of the rule. > > > > > > Il giorno mar 7 gen 2025 alle ore 10:00 Jean-Baptiste Onofré < > > > j...@nanthrax.net> ha scritto: > > > > > > > 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 > > > > > > > > > > > -- ------------------------ Guillaume Nodet
