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 >>> >>> >>> >
