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
