Re: [VOTE] Release Apache Cassandra 4.1.10

. > Proposing the test build of Cassandra 4.1.10 for release. > > sha1: d48bfcce442489de45797ecdf3bde7574ade42d5 > Git: https://github.com/apache/cassandra/tree/4.1.10-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachecassandra-1418/org/apache/cassan

[ANNOUNCE] Pre-commit CI @ pre-ci.cassandra.apache.org , an AWS donation

tl;dr I am super excited to share with you all the availability of https://pre-ci.cassandra.apache.org , made possible from a very generous donation by Amazon. Using AWS donated credits we now have a fast open-source CI system for pre-commit testing. This is intended primarily for committer

Welcome James Berragan as Cassandra committer on the Analytics subproject!

The Project Management Committee (PMC) for Apache Cassandra has invited James Berragan to become an Analytics subproject committer and we are pleased to announce that he has accepted. Please join us in welcoming James to his new role and responsibility in our project community. Mick, on

Welcome Lukasz Antoniak as Cassandra committer on the Drivers subproject!

and welcoming Lukasz! Mick, on behalf of the Apache Cassandra PMC

Re: Cassandra 5.1 Date

It'll be 6.0. At some point we will cut the release branch cassandra-6.0, and likely at the same time cut a 6.0-alpha1 release. How long it takes to stablise that branch to GA is unknown, but there are typically a few alpha releases, a few beta releases and a few rc releases first. We are w

Re: [DISCUSS] Audit log host field - client port vs storage port (CASSANDRA-20826)

> I'd like to bring up for discussion the host field in audit logs, which > currently shows > the storage port (e.g., 192.168.1.100:7000) instead of the native port users > expect to see. > > Background: > - Original implementation[1] used storage port for consistency with other > s

Re: CONTRIBUTING.md

> The important thing to know (but maybe not mention), which is on the “how to > commit” page, is that the GitHub PRs aren’t merged directly on GitHub, > they’re committed manually on the upstream git repo branch by branch with an > annotation to auto close them downstream on GitHub And

Re: [DISCUSS] CEP 52: Schema Annotations for ApacheCassandra

a point of order and a reminder: aside from suggestions that the CEP author is free to adopt or not, anything that's assuming to steer what the CEP should be should be accompanied with the willingness to commit in helping making it happen. we want to work as a meritocracy: those that lead the w

Re: [DISCUSS] Java SPI way of loading custom implementations

> > I have 0 issues with ServiceLoader, but I think the bigger question is “what > is a public api”. Let's also please be clear in separating what are our public SPIs and our public APIs, as compatibility concerns are different for each. We typically refer to both when mentioning API

Re: Running unit tests by package

; or at least mentioning their existence. >> Let me get a little more familiar with what's in that directory and pull up >> the juiciest-looking examples into the testing doc. >> Thanks -- Joel. >> >>> >>> On Tue, Jul 22, 2025, at 8:04 PM, Joel Shepherd

Re: [VOTE] CEP-50: Authentication Negotiation

+1 On Mon, 21 Jul 2025 at 17:52, Joel Shepherd wrote: > Hi dev@ - I'd like to request voting for adoption of CEP-50: > Authentication Negotiation. > > Proposal: > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-50%3A+Authentication+Negotiation > Discussion: > https://lists.apache.or

Re: Running unit tests by package

try .build/run-tests.sh -a test -t org.apache.cassandra.hints https://github.com/apache/cassandra/blob/cassandra-5.0/.build/README.md On Tue, 22 Jul 2025 at 21:06, Joel Shepherd wrote: > Hi - I know it's possible to run just the unit tests in a single test > class, or a specific test in a sp

Re: Missing 4.1.9 documentation

. > It has been pointed out to me that the documentation for 4.1.9 is missing > from the website ( https://cassandra.apache.org/doc/ ), does anyone know > why this is? > > Looking at the list of changes for 4.1.9, I guess there were not many, if > any, changes to the documentation, but it is confu

Re: [VOTE] Release Apache Cassandra Analytics 0.1.0

There's no signature and checksums on files. (and in the vote email you should state which key has been used for signing) apache-cassandra-analytics-0.1.0.tar.gz is basically empty. On Fri, 27 Jun 2025 at 00:19, Bernardo Botella wrote: > Proposing the test build of Cassandra Analytics 0.1.0

Re: [VOTE] Clarifying our JDK Support Policy

+1 On Fri, 13 Jun 2025 at 13:58, Josh McKenzie wrote: > +1 > > On Fri, Jun 13, 2025, at 7:56 AM, Josh McKenzie wrote: > > [DISCUSS] thread: > https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft > > Text to vote on: > >

Re: [DISCUSS] How we handle JDK support

You replied accurately to what i said, we're aligned. One point to continue is below… > And then, will the confidence of jdk12 in trunk be complete before its > merge, and at what point can jdk11 safely be dropped ? > > The action of dropping jdk11 in trunk is just a one-liner in build.xml > (a

Re: [DISCUSS] How we handle JDK support

Pushing a little for added clarity, see inline, while totally fine with this approach. Then we release the next C* version; for sake of illustration let's assume > a new JDK LTS 12: > >- C* 2.0 / 12 / 12 / 12 >- C* 1.0 / 11 / 11+12 / 11 > > How did jdk12 suddenly appear ? How did that h

Re: [DISCUSS] How we handle JDK support

che/cassandra-easy-stress/tree/main/src/main/kotlin/com/rustyrazorblade/easycassstress/workloads> > ) >- Upgrades > - N-2 -> N-1: tested on JDK and JDK-1 > - N-2 -> N: tested on JDK > - N-1 -> N: tested on JDK > > > --- &g

Re: [DISCUSS][CASSANDRA-20681] Mark JDK 17 as production ready for Cassandra 5.0

Do it. Four patch releases and eight months in, we're safe. On Mon, 26 May 2025 at 21:00, Dmitry Konstantinov wrote: > Hi all, > > I've created a task to mark JDK 17 as production-ready for Cassandra 5.0 > in our documentation - CASSANDRA-20681 >

Re: [DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

> > On Fri, May 2, 2025 at 05:54 Joseph Lynch wrote: > >> On Fri, May 2, 2025 at 6:46 AM Mick Semb Wever wrote: >> >>> But layering in the ability to do it with docker is opposed to requiring >>> the use of docker. i.e. I don't think we should make docker

Re: [DISCUSS] How we handle JDK support

. > For the rare edge case where we have to stop supporting something entirely >> because it's incompatible with a JDK release (has this happened more than >> the 1 time?) - I think a reasonable fallback is to just not backport new >> JDK support and consider carrying forward the older JDK su

Re: [DISCUSS] How we handle JDK support

. > > For the rare edge case where we have to stop supporting something entirely > because it's incompatible with a JDK release (has this happened more than > the 1 time?) - I think a reasonable fallback is to just not backport new > JDK support and consider carrying forward the older JDK suppo

Re: [DISCUSS] How we handle JDK support

. > So yeah. I think we'll need to figure out how much coverage is reasonable >> to call something "tested". I don't think it's sustainable for us to have, >> at any given time, 3 branches we test across 3 JDK's each with all our >> in-jvm test suites is it? >> > Correct. For non-upgrade test

Re: [DISCUSS] How we handle JDK support

. > If it came down to either: > >1. Support latest 2 LTS JDK on any given C* release, no overlap. >Operators deal with it. >2. Require 1 overlapping JDK version support on consecutive releases. >Users may have to wait a year for new JDK features > > My opinions… - we sho

Re: One Board to Rule Them All (or: ecosystem JIRA's are now integrated in our kanban board)

. On Fri, 16 May 2025 at 20:53, Josh McKenzie wrote: > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484 > Nice, thank you Josh. It looks like the swimline for "Patch 5.0.x" is missing.

Re: FixVersion house cleaning

. On Sat, 17 May 2025 at 14:57, Josh McKenzie wrote: > With the dropping of .MINOR in semver simplifying some things in our > release we have some FixVersion updating to consider. > > For those that might not know - we use the ".X" FixVersion to indicate > something is intended for a specif

Welcome Bret McGuire as Cassandra PMC Member!

join us in welcoming Bret McGuire to his new role in our project! Mick, on behalf of the Apache Cassandra PMC

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

. > e.g., assume gc_grace_seconds=10 days, a repair takes 5 days to run > * Day 0: Repair 1 starts and processes token A > * Day 1: Token A is deleted resulting in Tombstone A that will expire on > Day 11 > * Day 5: Repair 1 completes > * Day 7: Repair 2 starts > * Day 11: Tombstone A expires

Re: Welcome Abe Ratnofsky as Cassandra committer!

Congrats ! On Tue, 13 May 2025 at 08:59, Štefan Miklošovič wrote: > Congratulations! > > On Mon, May 12, 2025 at 6:48 PM Alex Petrov wrote: > >> Hello folks of the dev list, >> >> The Apache Cassandra PMC is very glad to announce that Abe Ratnofsky has >> accepted our invitation to become a com

Re: [VOTE] CEP-46: Finish Transient Replication/Witnesses

. The vote will be open for 72 hours. A vote passes if there are at least 3 > binding +1s and no binding vetoes. > +1

Re: [VOTE][IP CLEARANCE] easy-cass-stress

Great, thanks! +1 on the vote. On Mon, 12 May 2025 at 17:27, Jordan West wrote: > Mick I've addressed your two comments on the PR and merged it to the main > branch. I believe everything should be completed to remove your minus one > but let me know if you have further concer

Re: [VOTE][IP CLEARANCE] easy-cass-stress

. > That said, it has been committed. I don't see it yet reflected on the live > page but I assume (hope) there is some amount of auto-deployment. > I think it's hourly, and I see it now at https://incubator.apache.org/ip-clearance/cassandra-easy-cass-stress.html Please merge the PR before

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> Curious what others think though. I'm +1 on the spirit of getting MVs to > a stable point, but not convinced this is the best approach. > IMHO, focus should be on accord-based MVs. Even if that means it's blocked on first adding support for multiple conditions.

Re: [VOTE][IP CLEARANCE] easy-cass-stress

. > I’m working on updating the date in the form. Some feedback I plan to > eventually give: it took me literally 12 hours (that’s not an > exaggeration) to clone the ASF Infra repo (on a good internet connection) > to make this one line change and that took the free time I had over the > wee

Re: [VOTE][IP CLEARANCE] easy-cass-stress

dy has the three binding votes from the Cassandra PMC it needs, but my veto needs to be addressed (which is just small details of process, and strictly speaking only blocking the gh transfer). On Mon, 5 May 2025 at 18:14, Jon Haddad wrote: > So Mick - just to be clear, it sounds like you&#x

Re: [VOTE][IP CLEARANCE] easy-cass-stress

. > This IP Clearance form is not yet completed. Please fill out the data > column in the form to indicate all steps have been done. > Please fill out the *date* column in the form to indicate all steps have been done. 😮‍💨

Re: [VOTE][IP CLEARANCE] easy-cass-stress

Apologies for coming in late on this one. +1 in general, but… -1 on the gh transfer (see below), and a few questions seeking clarification. Dave, is your comment about lazy-consensus applicable to both the project's PMC or the IPMC (Incubator PMC's role on this thread) ? My understanding is tha

Re: [DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

> On Tue, 29 Apr 2025 at 10:10, Benedict wrote: >>> > >>> > We should never download and install software via adhoc scripts >>> without user consent. Was this ever discussed on this mailing list? If not, >>> it’s a clear breach of policy (introducing

Re: [DISCUSS] Requirement to document features before releasing them

Our nodetool pages can definitely be improved. Each has a bare sentence description. I mean what can a newcomer do with "gossipinfo - Shows the gossip information for the cluster" An example of where any extra denseness, in this case examples of when and why, would go a long way. On Wed, 30

Re: Welcome Jaydeepkumar Chovatia as Cassandra committer

Congrats! On Wed, 30 Apr 2025 at 13:44, Josh McKenzie wrote: > Hey there Cassandra Devs! > > The Apache Cassandra PMC is very happy to announce that Jaydeep Chovatia > has > accepted the invitation to become a committer! > > Jaydeep has been busy on Cassandra for a good while now, most recently

Re: [DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

. > But that doesn’t seem to be the case here, the script checks for arm vs > amd64, Linux vs Mac, and then fetches and untars the go distro into tmp. > There is no verification of the download. The only check is if curl > returned non 0. > Thanks for catching this, the sha256 check should

Re: Welcome David Capwell as Cassandra PMC Member!

Welcome David! On Mon, 28 Apr 2025 at 21:10, Jon Haddad wrote: > Hey everyone! > > The Project Management Committee (PMC) for Apache Cassandra is delighted > to announce that David Capwell has joined the PMC! > > Thank you David for all your contributions to the project over the years. > > The P

Re: [DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

gt;> installing go. >>> >>> Ideally we would not pull in one more language for a small task but it’s >>> hard for me to judge how difficult it would’ve been to implement this >>> feature differently. >>> >>> On Sun, Apr 27, 2025, at 6:20 PM,

[DISCUSS] auto-installing golang in `ant gen-doc` (CASSANDRA-19915)

rate accord > to ant if that’s the project preference, but there’s continual discussion > to begin modularising Cassandra (at least a little), and a proposal to use > grade for the modules - which might be a happy medium for everyone’s > competing priorities. > > > On 24

Re: Python and Go callouts during ant compile/build task

tion website? > > On Thu, Apr 24, 2025, at 8:25 AM, Mick Semb Wever wrote: > > Does this also apply to gradle, which now gets downloaded and installed, > and is the most recent addition ? > > The python requirement from gen-doc has been around for over three years > now.

Re: Python and Go callouts during ant compile/build task

d times when developing would be helpful. > > Jordan > > On Wed, Apr 23, 2025 at 13:37 Mick Semb Wever wrote: > > Python and Go are used by the gen-doc target. > > Code changes can break these, hence it is part of `ant check`. > It is not called by `ant jar` > > If

Re: Python and Go callouts during ant compile/build task

Python and Go are used by the gen-doc target. Code changes can break these, hence it is part of `ant check`. It is not called by `ant jar` If you want to run check but skip it, it's to add `-Dant.gen-doc.skip=true` On Wed, 23 Apr 2025 at 22:06, Alex Petrov wrote: > Hi folks, > > Building Cas

Re: [VOTE] Simplifying our release versioning process

. > > This reads to me that Java 17 would need to be deprecated now, continue to > be deprecated in 6.0 (at least one major in deprecated), then removed in > 7.0. > This is technically true. But I don't think we need to be explicitly deprecating jdk versions. Users are generally aware of J

Re: [VOTE] Simplifying our release versioning process

. > I'll plan to leave the vote open until we hit enough participation to pass > or fail it up to probably a couple weeks. > +1

Re: Project hygiene on old PRs

On Mon, 14 Apr 2025 at 10:23, Štefan Miklošovič wrote: > BTW If you still do not want to take care of closing it, that is also > fine, because we have a script at least. > >> >>> Relying on the PR name seems a bit brittle. Maybe it wouldn't take much to improve it. e.g. would it be possible to

Re: [DISCUSS] How we version our releases

On Thu, 10 Apr 2025 at 22:54, Josh McKenzie wrote: > … > So here's what I'm thinking: a new release strategy that doesn't use > .MINOR of semver. Goals: > - Simplify versioning for end users > - Provide clearer contracts for users as to what they can expect in > releases > - Simplify support for

Re: [DISCUSS] 5.1 should be 6.0

e need for the discussion and these long conversations altogether :-) On Thu, 10 Apr 2025 at 21:15, Jordan West wrote: > I don’t think there is any world where we can justify such major changes > being called 5.1. 5.0 had significantly less major changes. Mick, the > topics you b

Re: [DISCUSS] 5.1 should be 6.0

are supported, but >> let's at least address this one issue of version number so we can have >> consistent messaging. When i talk to people about the next release, I'd >> like to be consistent with what I call it, and have a unified voice as a >> project. >>

Re: [DISCUSS] slack notifications for subprojects

On Tue, 8 Apr 2025 at 23:59, Joel Shepherd wrote: > FWIW, my personal experience is that mixing automated notifications > (beyond a very low volume) with human communications adds a bunch of noise > to the human conversations and increases the risk of an interesting > automated notification being

Huge NetApp donation of hardware for ci-cassandra

Under a ASF targeted sponsorship, NetApp (Instaclustr) has been very generous with the community and donated ten beefy (AMD EPYC 9454P Genoa 48-Core, 256G ram) servers to be used with our ci-cassandra.apache.org infrastructure. On each server we fit 6 jenkins executors, increasing our ci-cassandra

Re: [VOTE][IP CLEARANCE] Spark-Cassandra-Connector

. On Tue, 18 Mar 2025 at 09:13, Mick Semb Wever wrote: > (general@incubator cc'd) > > Please vote on the acceptance of the Spark-Cassandra-Connector and its > IP Clearance: > > https://incubator.apache.org/ip-clearance/cassandra-spark-cassandra-connector.html >

[VOTE][IP CLEARANCE] Spark-Cassandra-Connector

he IP Clearance requirements before voting. The vote will be open for 72 hours (or longer). Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and no -1's. regards, Mick

Re: [VOTE][IP CLEARANCE] Spark-Cassandra-Connector

. PMC members, please check carefully the IP Clearance requirements before > voting. > > The vote will be open for 72 hours (or longer). Votes by PMC members > are considered binding. A vote passes if there are at least three > binding +1s and no -1's. > +1

[RESULT][VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

Vote passes with twelve +1s (ten binding). > On Sun, Mar 9, 2025 at 5:18 AM Mick Semb Wever wrote: >>> >>>> Please vote on the acceptance of the Cassandra Cluster Manager (CCM) >>>> and its IP Clearance: >>>> https://incubator.apache.org/ip-cl

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

. > The vote will be open for 72 hours (or longer). Votes by PMC members > are considered binding. A vote passes if there are at least three > binding +1s and no -1's. +1

[VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

authors. PMC members, please check carefully the IP Clearance requirements before voting. The vote will be open for 72 hours (or longer). Votes by PMC members are considered binding. A vote passes if there are at least three binding +1s and no -1's. regards, Mick

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

The IPMC vote only requires lazy consensus on IP Clearance matters. > Detailed in: > https://incubator.apache.org/ip-clearance/ That's correct, the vote is directed to the Cassandra PMC. The IPMC is only cc'd for notification, as is required.

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

On Thu, 6 Mar 2025 at 09:40, Štefan Miklošovič wrote: > That is cool but this still does not show / explain how it would look like > when it comes to dependencies needed for actually talking to storages like > s3. > As Benedict writes, dealing with optional dependencies is not hard (and as Jon

Re: Welcome Bernardo Botella as Cassandra Committer

Congrats Bernardo! On Wed, 5 Mar 2025 at 16:03, Abe Ratnofsky wrote: > Congratulations Bernardo! Great news. >

Re: Welcome Aaron Ploetz as Cassandra Committer

Well deserved Aaron ! 🎉 On Tue, 4 Mar 2025 at 19:27, Jon Haddad wrote: > > Congrats Aaron! > > On Tue, Mar 4, 2025 at 10:26 AM Jordan West wrote: >> >> Congratulations!! >> On Tue, Mar 4, 2025 at 09:57 Tolbert, Andy wrote: >>> >>> Congrats Aaron! >>> >>> On Tue, Mar 4, 2025 at 11:24 AM Francis

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

. It’s not an area where I can currently dedicate engineering effort. But if > others are interested in contributing a feature like this, I’d see it as > valuable for the project and would be happy to collaborate on > design/architecture/goals. > Jake mentioned 17 months ago a custom FileSys

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

. > The Project Management Committee (PMC) for Apache Cassandra is delighted to > announce that Ekaterina Dimitrova has joined the PMC! > > Thanks a lot, Ekaterina, for everything you have done for the project all > these years. Congrats Ekaterina !

Re: Welcome Caleb Rackliffe to the PMC

. > > Please join us in welcoming Caleb to his new role! > Congratulations Caleb !!

Re: [DISCUSS] JVM HEAP and G1 flag improvements for 5.0 (CASSANDRA-20296)

There have been no objections after 9 days. I'll commit these changes also to 5.0 On Tue, 11 Feb 2025 at 11:16, Jon Haddad wrote: > +1 to putting it in 5.0 > > > On Tue, Feb 11, 2025 at 2:10 AM Mick Semb Wever wrote: > >> Any objections to making the fol

Re: Merging compaction improvements to 5.0

Solid write up Jon! Hoping the committers and PMC members are keeping in mind this (very) recent thread: https://lists.apache.org/thread/h38g6q9d8h1q92h6qzs5tqdxpn2vmnyy This thread needs to also be about evaluating the risk these commits are to a patch version. I'm +1 and here's my thinking over

Re: Welcome Jeremiah Jordan to the PMC

. > I hope you will join me in welcoming him to the committee. Welcome JD!

Re: Meaningless emptiness and filtering

On Tue, 11 Feb 2025 at 19:56, Caleb Rackliffe wrote: > When we add IS [NOT] NULL support, that would preferably NOT match EMPTY > values for the types where empty means something, like strings. For > everything else, EMPTY could be equivalent to null and match IS NULL. > Makes sense to me to sa

[DISCUSS] JVM HEAP and G1 flag improvements for 5.0 (CASSANDRA-20296)

Any objections to making the following changes also to 5.0 ? CASSANDRA-20296 proposes the following changes: 1. G1 to by default use `-XX:G1NewSizePercent=50` to floor the young generation's size to 50% of the heap. (We know in production this can often be raised to 66% for optimal performance.)

Re: [VOTE] Release Apache Cassandra 4.0.17

. > The vote will be open for 24 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. The vote has passed with three binding +1s and no vetoes.

Re: [VOTE] Release Apache Cassandra 4.0.17

. > The vote will be open for 24 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

[VOTE] Release Apache Cassandra 4.0.17

Proposing the test build of Cassandra 4.0.17 for release. sha1: 0354c915a9f8be6ab671af5ff93b8178e6f2e76f Git: https://github.com/apache/cassandra/tree/4.0.17-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1363/org/apache/cassandra/cassandra-all/4.0

Re: [VOTE] Release Apache Cassandra 3.11.19

. > The vote will be open for 24 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

Re: [VOTE] Release Apache Cassandra 3.0.32

. > The vote will be open for 24 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 -

Re: [VOTE] CEP-45: Mutation Tracking

+1 :-) On Wed, 5 Feb 2025 at 23:05, Blake Eggleston wrote: > Ok ok, I've jumped gun here, sorry, small off by 24 error. Please continue > voting, and I'll be back tomorrow :D > > On Wed, Feb 5, 2025, at 1:49 PM, Blake Eggleston wrote: > > The vote passes with 10 +1s (4 nb) and no -1. > > Thanks

Re: [DISCUSS] 5.1 should be 6.0

. > If you mean only 4.1 and 5.0 would be online upgrade targets, I would > suggest we change that to T-3 so you encompass all “currently supported” > releases at the time the new branch is GAed. > > I think that's better actually, yeah. I was originally thinking T-2 from > the "what calendar

Re: [VOTE] Release Apache Cassandra 5.0.3

. 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

Re: [VOTE] Release Apache Cassandra 4.1.8

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

Re: [VOTE] Release Apache Cassandra 4.0.16

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

Re: [DISCUSS] 5.1 should be 6.0

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

Re: [VOTE] Release Apache Cassandra 3.11.18

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

Re: [VOTE] Release Apache Cassandra 3.0.31

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

Re: [DISCUSS] 5.1 should be 6.0

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

Re: [DISCUSS] 5.1 should be 6.0

There's still a few open loops in this thread that I'd like to keep pushing on. I admit I've been pretty adamant that there's real value for a) users, operators, and ourselves, having an intuitive understanding of our recommended upgrade paths by versions, and b) a method to reduce the CI testing

Re: What branches should perf fixes be targeting

I think the status quo here extends to: operational issues and performance regressions can be considered like bugs in this context, and patches that are very isolated and deemed safe by any pmc member with experience in that area of the code can approve it on the ticket without it going to the mail

Re: Status of CEP-1

On Mon, 20 Jan 2025 at 02:16, Jeff Jirsa wrote: > IIRC Cassandra is configured such that only PMC members can roll a release > FTR, it's only the very final step of pushing the release artefacts public that only the PMC can do. Any committer can initiate and lead the release process at large.

Re: Checkstyle as style contract for Cassandra

On Thu, 16 Jan 2025 at 22:06, Caleb Rackliffe wrote: > … > There are forks out there, of course, and they would be affected, too. > This. Let's make sure to check thoroughly, this could really hurt people (for what is a trivial annoyance). Personally, braces on newlines doesn't bother me. I

Re: [DISCUSS] Usage of "var" instead of types in the code

Jumping in, I'm ok to allow it in tests for a trial period too. I would imagine in test methods especially it's of much less concern, where the code is much simpler to read, and also safer to change to types later on. On Wed, 8 Jan 2025 at 16:46, Josh McKenzie wrote: > I would like to remove th

Re: Supporting 2.2 -> 5.0 upgrades

On Fri, 13 Dec 2024 at 06:06, Jeremiah Jordan wrote: > TL;DR - in progress migration off 2.2 to 5.0 is annoying as there were >>> different bugs in the past we have to support again. Out of process >>> migration to me feels far more plausible, but feels annoying without >>> splitting off our rea

Re: [DISCUSS] 5.1 should be 6.0

s still do happen, hopefully less over time, and _drawing a line in the sand_ is a legit tactic to deal with them.) @Mick, you made me laugh, with your unique ability to agree disagreeably. > You might not care about marketing, but people pay more attention to major > version upgrades and &quo

Re: [DISCUSS] 5.1 should be 6.0

I would very much rather keep our upgrade paths simple and intuitive: You can only upgrade between adjacent major versions. This does catch users, and keeping it simple has helped a lot. I find it helps internally working on the code too, with a focus on stability for online upgrades, which does q

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> A possibility with SAI is to mark it beta while also marking 2i as > deprecated (and leaving SASI as marked). This sends a clear signal > (imho) that SAI is the recommended solution forward but also being > honest about its maturity and QA. (and leaving SASI as marked *experimental*)

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

I see value in using a beta flag in addition to an experimental flag, and that such a beta flag should see a lot more use than experimental. Java 17 definitely falls in the beta category. I/We definitely recommend its usage in production, but as has been said data is needed over trust and the co

Re: Re-evaluate compaction defaults in 5.1/trunk

Chiming in with my two cents… When people have the luxury of working in environments where clusters are > massively over provisioned, LCS as a default makes a lot of sense, because > there's not much downside. The use cases where you'd actually fall behind > in compaction are pretty slim, so the

Re: Markdown JavaDoc

+1 for more code (github/ide) readable in-code documentation. Do we use javadoc anywhere anymore, or read its generated apidocs anywhere ? We removed that target from the build cycle, and don't publish those artefacts or deploy the apidocs anywhere anymore… I would say folk are either got the c

Re: [DISCUSS] Removing v30 and v3X from trunk in-JVM upgrade tests

On Sat, 16 Nov 2024 at 00:18, Caleb Rackliffe wrote: > The subject line probably says it all, but just to confirm, we won't be > supporting 3.11 -> 5.1/trunk upgrades, correct? > Correct. To be specific, online upgrades. > If that's correct, I'm going to go ahead and remove v30 and v3X from

  1   2   3   4   5   6   7   8   9   10   >