I agree there’s probably some value captured in having ccm tests, but I suspect
not in most of the python tests we have, which are all but unmaintained at this
point. When I looked at them last I was surprised at how rubbish many of them
were.
I think we need a plan to maintain them properly, a
+1
On Tue, Jan 28, 2025 at 8:36 AM Štefan Miklošovič
wrote:
> Proposing the test build of Cassandra 5.0.3 for release.
>
> sha1: b0226c8ea122c3e5ea8680efb0744d33924fd732
> Git: https://github.com/apache/cassandra/tree/5.0.3-tentative
> Maven Artifacts:
> https://repository.apache.org/content/rep
+1
On Tue, Jan 28, 2025 at 8:36 AM Štefan Miklošovič
wrote:
> Proposing the test build of Cassandra 4.1.8 for release.
>
> sha1: 044727aabafeab2f6fef74c52d349d55c8732ef5
> Git: https://github.com/apache/cassandra/tree/4.1.8-tentative
> Maven Artifacts:
> https://repository.apache.org/content/rep
.
The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
Checked
- signing correct
- checksums correct
- source a
+1
On Tue, Jan 28, 2025 at 8:35 AM Štefan Miklošovič
wrote:
> Proposing the test build of Cassandra 4.0.16 for release.
>
> sha1: c989c02be66411991c8536ca00ee6481f43e642e
> Git: https://github.com/apache/cassandra/tree/4.0.16-tentative
> Maven Artifacts:
> https://repository.apache.org/content/r
Hi dev@,
Looks like it's been about 10 days since the last message here. Are there any
other comments before I put it up for a vote?
Thanks,
Blake
> On Jan 18, 2025, at 12:33 PM, Blake Eggleston wrote:
>
> That's an interesting idea. Basically allow for a window of uncertainty
> between the
.
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
+1
Checked
- signing correct
- checksums are correct
- s
I have not checked Jenkins, but we see this in another environment…
For python upgrades have we actually audited the runtime to see that the time
spent is doing real work? Josh and I have spent a ton of time trying to fix
(and failing) an issue where the python driver blocks the test and we wai
.
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
+1
Checked
- signing correct
- checksums are correct
- so
> We revisit this basically every year and so I’m sort of inclined to keep the
> status quo which really amounts to basically doing whatever we end up
> deciding arbitrarily before we actually cut a release.
>
> Before discussing at length a new policy we’ll only immediately break
It's painful
My opinion? Our revealed preferences don’t match whatever ideal is being chased
whenever we discuss a policy.
.
Ignoring the tick-tick debacle the community has done basically the same thing
every release, only with a drift towards stricter QA and compatibility
expectations with maturity.
That
replies inline…
.
We have far fewer (and more effective?) JVM Upgrade DTests.
> There we only need 8x medium (3 cpu, 5GB ram) servers
>
> Does anyone have a strong understanding of the coverage and value offered
> by the python upgrade dtests vs. the in-jvm dtests? I don't, but I
> intuitively h
Won't comment directly on the compatibility window (although I lean toward
the status quo and just requiring upgrades from the latest patch version of
a major release), but I think I've also arrived at a point where I'm not
convinced running the Python upgrade tests pre-commit is an efficient use
o
We revisit this basically every year and so I’m sort of inclined to keep the
status quo which really amounts to basically doing whatever we end up deciding
arbitrarily before we actually cut a release.
Before discussing at length a new policy we’ll only immediately break, if the
motivation is
> Python Upgrade DTests today requires 192x large (7 cpu, 14GB ram) servers
> We have far fewer (and more effective?) JVM Upgrade DTests.
> There we only need 8x medium (3 cpu, 5GB ram) servers
Does anyone have a strong understanding of the coverage and value offered by
the python upgrade dtests
+1
On Tue, Jan 28, 2025 at 8:35 AM Štefan Miklošovič
wrote:
> Proposing the test build of Cassandra 3.11.18 for release.
>
> sha1: 429f3ad83e1c9eff5c288a7c8fb4781939d00090
> Git: https://github.com/apache/cassandra/tree/3.11.18-tentative
> Maven Artifacts:
> https://repository.apache.org/content
+1
On Tue, Jan 28, 2025 at 8:35 AM Štefan Miklošovič
wrote:
> Proposing the test build of Cassandra 3.0.31 for release.
>
> sha1: 09e7a4d6ae23b7ac5c9867235c9d900d0c99649a
> Git: https://github.com/apache/cassandra/tree/3.0.31-tentative
> Maven Artifacts:
> https://repository.apache.org/content/r
.
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
Checked
- signing correct
- checksums are correct
- sou
.
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
+1
Checked
- signing correct
- checksums are correct
- source
Jordan, replies inline.
To take a snippet from your email "A little empathy for our users goes a
> long way." While I agree clarity is important, forcing our users to
> upgrade multiple times is not in their best interest.
>
Yes – we would be moving in that direction by now saying we aim for o
+1
Kind Regards,
Brandon
On Tue, Jan 28, 2025 at 1:35 AM Štefan Miklošovič
wrote:
>
> Proposing the test build of Cassandra 3.11.18 for release.
>
> sha1: 429f3ad83e1c9eff5c288a7c8fb4781939d00090
> Git: https://github.com/apache/cassandra/tree/3.11.18-tentative
> Maven Artifacts:
> https://repo
+1
Kind Regards,
Brandon
On Tue, Jan 28, 2025 at 1:35 AM Štefan Miklošovič
wrote:
>
> Proposing the test build of Cassandra 3.0.31 for release.
>
> sha1: 09e7a4d6ae23b7ac5c9867235c9d900d0c99649a
> Git: https://github.com/apache/cassandra/tree/3.0.31-tentative
> Maven Artifacts:
> https://reposi
Yeah, my position is this isn’t a problem. The full range of upgrade tests only
need to be run at most on release, and we’re not talking about supporting loads
of versions. I think it’s fine to (as before) expect people upgrade from and to
the highest patch version of any minor release, so the m
23 matches
Mail list logo
