Also, thanks for the nudge - that triggered my attention. "At least 72
hours" is the way. The number of sub-projects means less concentrated
attention, so do call it out if you need eyeballs and votes to get to
the goal.
Kind regards,
Michael
On 10/15/25 08:25, Doug Rohrer wrote:
Thanks to everyone for validating the release - the vote passes with 5 Binding
and 4 non-binding +1s.
I'll click the release button and get the related Cassandra PRs rebased and
ready for commits.
Doug
On Oct 15, 2025, at 9:59 AM, Doug Rohrer <[email protected]> wrote:
Fair enough - I seem to run into this issue every time I end up doing a vote, because, of
course, 72 hours makes it easy to bleed into a weekend. I'll just generally consider
non-work days not part of the vote and just wait long enough to allow folks to check, but
to your point, calling out a specific time isn't great either... I suppose we could say
"The vote will be open for a minimum of 72 hours" in this case, which would
both cover the requirement and allow some wiggle room.
On Oct 14, 2025, at 2:34 PM, Brandon Williams <[email protected]> wrote:
I think 72 hours meets the minimum requirement, and beyond that the
Release Manager has discretion. I don't think calling out when the
vote ends is a great idea because you often need to let the votes run
longer in order to garner enough votes to pass, and you won't know you
need to do that until you get there.
Kind Regards,
Brandon
On Tue, Oct 14, 2025 at 1:29 PM Josh McKenzie <[email protected]> wrote:
Out of curiosity, do we happen to have a policy (or opinion) around calling a vote over a
weekend? Should we? Technically, I think "72 hours" ended on Sunday afternoon,
but seems wrong to assume folks have had a chance to look at email and validate a build
over a weekend.
I was thinking the same thing re: the gocql vote. We should probably just call out
something like "vote ends at time X" if it runs over a weekend or something?
On Tue, Oct 14, 2025, at 12:02 PM, Jeremiah Jordan wrote:
+1
On Oct 14, 2025 at 10:49:35 AM, Michael Shuler <[email protected]> wrote:
+1 thanks!
On 10/7/25 15:56, Doug Rohrer wrote:
Hey folks,
I'd like to propose a new release of the dtest-api that includes some
updates to make it easier for Cassandra maintainers to deal with some of
the jmx support classes, and for external consumers of the dtest api to
use the jmx client without having to jump through some somewhat ugly hoops.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
<https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git>
Candidate SHA:
https://github.com/apache/cassandra-in-jvm-dtest-api/
commit/421fe11b8fd862d82f89607c1ae2807657ba6578 <https://github.com/
apache/cassandra-in-jvm-dtest-api/
commit/421fe11b8fd862d82f89607c1ae2807657ba6578>
Tagged with 0.0.18
Artifacts:
https://repository.apache.org/content/repositories/
orgapachecassandra-1419/org/apache/cassandra/dtest-api/0.0.18/ <https://
repository.apache.org/content/repositories/orgapachecassandra-1419/org/
apache/cassandra/dtest-api/0.0.18/>
Key signature: 2C94EBA59C0BA7E0EDAAE142BF79EF32B05FB5CA
Changes since last release:
* CASSANDRA-20884 - Move JMX classes to the in-jvm-dtest API project
I have patches available for 4.0, 4.1, 5.0, and trunk Cassandra branches
to take advantage of these changes as well, which can be updated to use
this release and committed once the vote passes.
The vote will be open for 72 hours. Everyone who has tested the build
lis invited to vote. Votes by PMC members are considered binding. A vote
passes if there are at least three binding +1s.
See https://issues.apache.org/jira/browse/CASSANDRA-20884 <https://
issues.apache.org/jira/browse/CASSANDRA-20884> for branches of Cassandra
for testing the dtest-api change (which currently use a snapshot build
of this).
Thanks,
Doug Rohrer
