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