Hi Guillaume, inline...
On 10/01/2025 17:52, Guillaume Nodet wrote:
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.
Yeah, I agree, the releases that can pre predicted, should be announced
upfront.
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 ?
Yes, that would be the ideal case: no Java code changes, just changes in
pom.xml files and perhaps some minor changes of the version string in
the docs.
* 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 ?
Yeah, you are right, folks should be able to send -1 votes during that
time. My original idea was to encourage -1 votes early and +1 rather late.
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.
Yes, thanks that sounds very reasonable.
Thanks a lot for your feedback Guillaume!
I'd adapt the text, unless there are other comments?
-- Peter
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