> > > Le ven. 10 janv. 2025 à 15:46, Peter Palaga <ppal...@redhat.com> a écrit :
> Thanks everybody, for the constructive discussion. > > To sum up, there are voices expressing concerns about the viability of > the new process from the side of the ASF board. > There are suggestions to adjust the original proposal to become more in > line with ASF rules (no veto votes, rename the freeze period to vote > period, provide zipped maven repos for Camel Quarkus and Quarkus for > local testing). > And most importantly there are no voices against the new process per se. > > I think the best way forward would be to go to ask the ASF board about > the process once we agree about it here. WDYT? > > Here is my second attempt to formulate the new process, with > improvements brought by folks participating in this discussion. I kindly > ask for your comments again. > > -- Peter > > ------>8------- > > we, Apache Camel project PMC members, Committers and contributors signed > below, would like to implement a new voting process for LTS patch releases. > > This process is currently intended only for use with Apache Camel > Quarkus. We may decide to apply it to other subprojects of Apache Camel > in the future if it proves to be useful and viable. > > 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 the traditional 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 (or earlier): the release plan is announced stating when the LTS > branch freeze and voting starts and ends. > If we have a regular schedule, it would be nice to mention when the next ones are planned to at some point in the process. > Day D: a 48 hours LTS branch freeze and a 48+ hours voting period starts. > > * The announcement message contains the following information: > o Optional: a link to a staging repository containing a new Camel > LTS patch release currently under vote, if Camel Quarkus LTS > branch depends on it > o The SHA1 of the tip of the Camel Quarkus LTS branch > + A link to a CI build from that SHA1 where the following > archives can be downloaded for local testing: > + Zipped Maven repository containing the Camel Quarkus artifacts > + Optional: Zipped Maven repository containing Quarkus > artifacts built from its LTS branch, if a Quarkus release is > expected shortly and its LTS branch is frozen for release > < > https://github.com/quarkusio/quarkus/wiki/3.15-LTS-Release-Planning>. > So, if no other changes happen during code freeze, the release would be the same, apart from the mechanism to change the artifact versions from snapshot to the actual release ? i.e. the maven-release-plugin commit which actually performs the release. Correct ? > > * During that period > o All interested parties are welcome to review and test the branch > directly or using the artifacts mentioned above. > o Camel PMC members (binding) and other interested parties > (non-binding) may cast their -1 votes for the release for any > relevant reason, such as quality, performance, etc. > o Only changes of following kinds are allowed during the freeze > period: > + Fixes resolving -1 votes > + Upgrades to expected Camel core or Quarkus patch 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. > o Minor fixes and expected Camel or Quarkus micro-upgrades do not > prolong nor cancel the voting. > o Substantial changes require re-starting the release process. > o Each change is announced via e-mail on the voting thread with a > new link to a CI Build containing the zipped repositories as > mentioned above. > o All interested parties are encouraged to cast their +1 votes > towards the end of the period, when possibly all issues are > solved and a staging repository is created for Camel Quarkus. > > Day D+2: Once the freeze period is over, possibly all negative votes > and/or all upgrade issues are resolved and possibly after the expected > Quarkus release are out, the Camel Quarkus release is staged and the > voting is opened for +1 votes. > "for votes" is enough, especially as people can vote -1 ;-). Or is that on purpose ? > > 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 votes. > One of the reasons that a release cannot be vetoed is to make sure an individual cannot hold the PMC hostage and not be able to do any release at all. The rule is thus that there is a need for at least 3 +1s and more +1s than -1s. Of course, as a community, if someone votes -1 and expresses a concern, it should be addressed. But it can be overruled. An example could be that during testing: someone finds a bug and votes -1. But if the bug is an old one, other PMC members could object that it can be deferred to the next patch release. So I think this should be reworded slightly. > > 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. > > We kindly ask for your feedback. > > Signed Apache Camel project members. > > ------>8------- > > Thanks, > > > > On 09/01/2025 11:30, Guillaume Nodet wrote: > > It has also been mentioned in the board thread that some projects do > recut > > the release during the voting period without extending the voting period. > > So minor bug fixes and micro version upgrades could follow that path. > > That would mean: > > * start the voting period in a more traditional way with a staged > release > > that people can vote on > > * if a minor bug fix or micro dependency upgrade is needed, cut another > > release without extending the vote period > > > > > > Le jeu. 9 janv. 2025 à 11:12, Andrea Cosentino<anco...@gmail.com> a > écrit : > > > >> 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 > >>> > > > -- ------------------------ Guillaume Nodet
