I do not personally count weekends in. I am also trying to be sensible with timezones. If the majority of people live in the US west / east coast I will give them extra time to respond etc.
On Wed, Oct 15, 2025 at 5:28 PM Mick <[email protected]> wrote: > > i usually give the minimum timeframe an extra 24 hours when it goes over a > weekend. > > as others have said, it's the timeframe for objections (vetoes) to be raised. > otherwise, beyond the window, we just wait til we've got enough votes. > > people are also free to ask for a hold/extension on the timeframe, if they > suspect a objection/veto but need time to verify and describe it. > > > > On 14 Oct 2025, at 20:34, 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 > >> > >> > >> >
