Hello, Answers inline.
Il giorno gio 9 gen 2025 alle ore 10:48 Guillaume Nodet <gno...@apache.org> ha scritto: > 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. > If I follow what the board and the release policy say, the reason why we have 72 hours period for vote is give the ability to members to test the release and build from source (staged). The freeze period doesn't provide, formally, any staged artifacts or source code. Just a branch. To me the workflow proposed in this thread makes sense, but I don't want to see the board complaints about the PMC behavior. It's not clear and it's a bit too subject to interpretations. > > 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 >
