Re: [DISCUSS] CEP-55 Generated role names

Wow - I seem to really have struck a nerve. Let me reiterate what I closed my earlier email with: Why. Not. Both. Nobody is suggesting we gatekeep things and put them only in the sidecar to try and coerce people to use it. Let me reiterate: I strongly disagree with characterizing features added

Re: [DISCUSS] CEP-55 Generated role names

Another thing I would *not* suggest we block this CEP on *at all*, but just an interesting data point IMO. On Fri, Sep 19, 2025, at 9:42 AM, Josh McKenzie wrote: > Wow - I seem to really have struck a nerve. > > Let me reiterate what I closed my earlier email with: Why. Not. Bot

Re: [DISCUSS] CEP-55 Generated role names

> Putting this to Sidecar almost guarantees nobody is going to use this > particular functionality. People have their own control planes, their own way > of generating this stuff and they are not going to deploy Sidecar just > because they want to delegate this task to it. I strongly disagree.

Re: [VOTE] CEP-51: Support Include Semantics for cassandra.yaml

+1 On Tue, Sep 16, 2025, at 1:30 PM, Joel Shepherd wrote: > +1 (non-binding) > > On 9/16/2025 1:02 AM, Johnny Miller wrote: > > Hello Everyone 👋, > > > > I’m initiating the vote on CEP-51 > > > > You can find the proposal here: > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-51+Sup

Re: [VOTE] CEP-54: ZSTD with Dictionary SSTable Compression

+1 On Wed, Sep 10, 2025, at 4:42 PM, Bernardo Botella wrote: > +1 > > > On Sep 10, 2025, at 12:33 PM, Francisco Guerrero wrote: > > > > +1 > > > > On 2025/09/10 19:31:27 Yifan Cai wrote: > >> Thanks everyone who has voted so far! > >> > >> Just a quick clarification for Jordan: > >> > >> Aut

Re: [VOTE] CEP-52: Schema Annotations for ApacheCassandra

+1 (I updated the ML discussion link in the wiki article and fixed a typo or two on there while doing a final review pass) On Fri, Aug 29, 2025, at 5:34 AM, shailajako...@icloud.com wrote: > +1 > > >> On Aug 28, 2025, at 11:07 PM, Yifan Cai wrote: >> >> +1 >> >> >> >> *From:* Francisco Gu

Re: [VOTE] Release Apache Cassandra Sidecar 0.2.0

+1 On Wed, Aug 27, 2025, at 9:52 AM, Paulo Motta wrote: > +1 > > On Wed, 27 Aug 2025 at 08:56 Isaac Reath wrote: >> +1 (nb) >> >> On Tue, Aug 26, 2025 at 12:24 PM Bernardo Botella >> wrote: >>> +1 (nb) >>> On Aug 26, 2025, at 1:03 AM, Štefan Miklošovič wrote: +1

Re: Cassandra 5.1 Date

> we're already long overdue I thought the same thing but had forgotten how long it took us to stabilize 5.0 to GA. Looks like we're just over 12 months since we released that so maybe we're not *that* overdue. Or maybe that's just what I'm telling myself so I don't feel so bad about taking so

Re: Welcome Branimir Lambov as Cassandra PMC member

Congratulations Branimir! It's been great to collaborate with you over the years. Looking forward to more. :) On Thu, Aug 21, 2025, at 5:04 PM, guo Maxwell wrote: > Congratulations! > > Ekaterina Dimitrova 于2025年8月22日周五 04:53写道： >> Congratulations! 🎉 Thank you for everything you do all these y

Re: Welcome Lukasz Antoniak as Cassandra committer on the Drivers subproject!

Congratulations Lukasz! On Thu, Aug 21, 2025, at 4:52 PM, Ekaterina Dimitrova wrote: > Congratulations! 🎉 > > On Thu, 21 Aug 2025 at 16:40, Mick wrote: >> Hello folks of the dev list, >> >> The Apache Cassandra PMC is very glad to announce that Lukasz Antoniak has >> accepted our invitation

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

> I'd prefer to prioritize user intuition, since putting the storage port in > the host field does not reflect how end-user traffic works in production. I agree w/Jaydeep's perspective here. On Mon, Aug 18, 2025, at 2:21 PM, Francisco Guerrero wrote: > Yeah, I think this is a good suggestion. We

Re: [VOTE] CEP-48: Cassandra Materialized View Consistency, Reliability & Backfill Enhancement

+1 On Mon, Aug 18, 2025, at 4:53 PM, Dinesh Joshi wrote: > +1 > > On Mon, Aug 18, 2025 at 9:39 AM Runtian Liu wrote: >> Hi dev@, I would like to start the voting for CEP-48: Cassandra Materialized >> View Consistency, Reliability & Backfill Enhancement >> >> Proposal: >> https://cwiki.apache.

Re: Accepting AI generated contributions

odels or services running models with these issues. >>> >>> This isn't even a change of what we settled on right? We seemed to broadly >>> agree that we wouldn't accept output from models that aren't license >>> compatible. What has changed is we h

Re: Accepting AI generated contributions

rpretation. On Fri, Aug 1, 2025, at 11:48 AM, David Capwell wrote: > > > > On Aug 1, 2025, at 6:38 AM, Josh McKenzie wrote: > > > >> Kimi K2 has similar wording as OpenAI so I assume they are banned as well? > > > > What about the terms is incompatible wi

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

Definitely want to avoid scope creep, *however*... ;) What if the CEP includes an interface for MV repair that calls out to some user pluggable solution and the spark-based solution you've developed is the first / only reference solution available at the outset? That way we could integrate it i

Re: Accepting AI generated contributions

don’t need to disclose? > > Sent from my iPhone > >> On Jul 31, 2025, at 9:13 PM, Yifan Cai wrote: >>  >> Does "*optionally* disclose the LLM used in whatever way you prefer and >> *definitely* no OpenAI" meet everyone's expectations? >> &g

Re: Accepting AI generated contributions

ing and then heavily modified >>>>>>>> > everything I think we'll be in a pretty good spot. >>>>>>>> >>>>>>>> David is disclosing it in the maillist and the GH page. Should the >>>>>>>> dis

Re: [DISCUSS] introduction of nodetool get/set guardrailsconfig in 4.1, 5.0 and trunk

+1 to adding. It's a user-facing API so we're going to be wedded to it for the lifespan of the project; having existing MBean's we're wiring it to and a relatively simple use-case makes this non-controversial to me. On Sat, Jul 26, 2025, at 11:06 AM, Jordan West wrote: > Similar to Ekaterina and

Re: Running unit tests by package

y speaking, I think we could probably really improve the discoverability of how to run a subset of tests and/or get involved with developing in this space. On Wed, Jul 23, 2025, at 6:33 PM, Joel Shepherd wrote: > On 7/23/2025 7:21 AM, Josh McKenzie wrote: >> >> There anything in

Re: Cassandra Meetup – Hosted by Uber and the Apache Cassandra Community (Aug 12, Sunnyvale, CA)

, Jul 23, 2025 at 7:24 AM Josh McKenzie wrote: >> __ >>> I'll be there, and I hope if you are in the area, you don't miss this >>> opportunity for us to connect. >> Do not arm wrestle Patrick. Unless you like doing PT afterward. >> >> I'

Re: [VOTE] Release Apache Cassandra Analytics 0.1.0

+1 On Tue, Jul 22, 2025, at 5:26 AM, Štefan Miklošovič wrote: > +1 > > On Tue, Jul 22, 2025 at 5:03 AM Bernardo Botella > wrote: >> Proposing the test build of Cassandra Analytics 0.1.0 for release. >> >> sha1: 6e1d5257a8d6c910a42751475612145533ae3b1d >> Git: https://github.com/apache/cassandr

Re: Cassandra Meetup – Hosted by Uber and the Apache Cassandra Community (Aug 12, Sunnyvale, CA)

> I'll be there, and I hope if you are in the area, you don't miss this > opportunity for us to connect. Do not arm wrestle Patrick. Unless you like doing PT afterward. I'll be there; have some things to present and chat about. :D Looking forward to it! On Tue, Jul 22, 2025, at 6:48 PM, Jaydee

Re: Running unit tests by package

There anything in that README that we could/should promote to https://cassandra.apache.org/_/development/testing.html? On Tue, Jul 22, 2025, at 8:04 PM, Joel Shepherd wrote: > Ah, thanks: all kinds of good stuff in there. > > -- Joel. > > On 7/22/2025 1:45 PM, Mick Semb Wever wrote: >> >> try

Re: Question on CEP-32 and OpenTelemetry Integration

> I would like to propose extending the scope of the CEP to include C* Sidecar, > Analytics, and Java Driver (at a minimum). To clarify (my position, not put words in your mouth Dinesh) - the *CEP* I think should cover them all, but *implementation* we could definitely do piece-meal. On Mon, Ju

Re: [VOTE] CEP-50: Authentication Negotiation

+1 On Mon, Jul 21, 2025, at 12:40 PM, Nate McCall wrote: > +1 > > On Mon, Jul 21, 2025 at 8:52 AM 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

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

il things. On Mon, Jul 21, 2025, at 11:37 AM, Johnny Miller wrote: > I think that's worth getting done - it would be very handy! Maybe we can > discuss it when implementing to figure out the way to do it? > > On Mon, 21 Jul 2025 at 16:02, Josh McKenzie wrote: >> _

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

t; I have added the section "Reference Example Configuration" - will see what > the feedback on this is. I suppose the only concern would be maintaining this > version in alignment with what's going into the main cassandra.yaml as part > of the regular development. > >

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

That sounds useful to me. I'd like to see us move to "modularized by default"; our current config being 2839 lines of .yaml is a bad experience for both new and old users. Starting with examples of the new paradigm and then r

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

have a chance 👍 > > On Sat, 19 Jul 2025 at 20:18, Josh McKenzie wrote: >> __ >> +1 >> >> One small bit of feedback - in testing: >>> Unit Tests >>> >>> • Include file loading with all three directive types >>> • Rejection of

Re: [DISCUSS] CEP-51: Support Include Semantics for cassandra.yaml

+1 One small bit of feedback - in testing: > Unit Tests > > • Include file loading with all three directive types > • Rejection of include directives in included files > • Detection of duplicate configuration keys across files > • Error messages for duplicate keys include file and line number

Re: Is it time for 5.0.5?

e group of people > able to do that more wider but no problem staging it myself if you want ... > > On Thu, Jul 17, 2025 at 9:07 PM Josh McKenzie wrote: >> __ >> It's been a minute: >> >> Latest GA Version >> Apache Cassandra 5.0 >> Late

Is it time for 5.0.5?

It's been a minute: Latest GA Version Apache Cassandra 5.0 Latest release on 2025-02-03 Maintained until 5.3.0 release 5.0.4

Re: Order of operations for CEP's; wiki, JIRA, discussion

everyone feels that there is no need to start this CEP, >> then Jira either does not need to be created or there is no need to set it >> to open. >> >> I think the order to set the jira‘s status is more important than create. >> >> Josh McKenzie 于2025年7月17日 周四下午1

Order of operations for CEP's; wiki, JIRA, discussion

I *may* have led Joel astray re: ordering on CEP-50 and https://issues.apache.org/jira/browse/CASSANDRA-20768. I always thought we created JIRAs proactively to go along w/a CEP and just closed out the JIRA if we couldn't get to an agreement on things. Mostly just because of my anal retentive re

Re: [DISCUSS] CEP-50: Authentication Negotiation

> I'm concerned about config updates made through JMX not being persistent > across restarts Reasonably so yeah. I was thinking along the lines of "change to config that is persisted in config file", but now that you mention this I don't think we actually have a precedent for that yet. And the s

Re: [DISCUSS] CEP-50: Authentication Negotiation

Responses to specific > points interwoven below ... > > On 7/9/2025 3:25 AM, Josh McKenzie wrote: >> >> Sorry for the delay in getting to this Joel. This is great work - really >> well thought out and put together. I'm a +1 on it; had the following >> observat

Re: [DISCUSS] CEP-50: Authentication Negotiation

Sorry for the delay in getting to this Joel. This is great work - really well thought out and put together. I'm a +1 on it; had the following observations or questions reviewing the CEP: Rather than going with a new discretely allowed option to a closed list of allowable options in STARTUP, wha

Re: Sharing a Monthly Cassandra Community Update – Would This Be Useful Here?

Definitely Himanshu! I've had a todo list item for, oh, two? three? months now to get to another one of these; I've sent them off and on over the past few years. Historically I tried to cover: 1. How to get started w/the community 2. Releases that have come out 3. Any discussions people might

Re: [DISCUSS] Seeking Guidance on Next Task and Areas to Contribute

Pranav, Here's a link to a list of tickets that are unassigned and have been designated good "Starter Tickets": https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2160 On Sun, Jul 6, 2025, at 7:44 PM, Jaydeep Chovatia wrote: > > Hey Pranav, > > Re

Re: [ANNOUNCE] Apache Cassandra Analytics 0.1.0 test artifact available

A brief moment of validation and cheerleading: this build process is complex and analytics has a *lot* of artifacts coming out of it. I really appreciate you spearheading this Bernardo; once we have these kinks worked out this is going to be a huge benefit to the project. So: thanks! On Wed, J

Re: [VOTE] Release Apache Cassandra Analytics 0.1.0

This is... a lot of artifacts. Any recommendations on automated / scripted ways to pull down and validate this release for voters? On Thu, Jun 26, 2025, at 6:19 PM, Bernardo Botella wrote: > Proposing the test build of Cassandra Analytics 0.1.0 for release. > > sha1: 9c948eab9356f5d166c26bb7a155

Re: Accepting AI generated contributions

Did some more digging. Apparently the way a lot of headline-grabbers have been making models reproduce code verbatim is to prompt them with dozens of verbatim tokens of copyrighted code as input where completion is then very heavily weighted to regurgitate the initial implementation. Which makes

Re: Accepting AI generated contributions

lly. >>>> >>>> I think the key distinction to find some early consensus on if we do a >>>> binding allow list or guidance, and then we can iron out the guidance, but >>>> I think that will be less controversial to work out. >>>> >>>

Re: [RESULT][VOTE] Clarifying our JDK Support Policy

erarchy for this JDK version support policy <https://cwiki.apache.org/confluence/display/CASSANDRA/JDK+Version+Support+Policy> and moved some of the loose top level pages that belonged into that group. On Thu, Jun 19, 2025, at 7:55 AM, Josh McKenzie wrote: > Binding: 14 +1, no -1 > N

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

>>>> escape hatch where I can pass my raw commands >>> >>> For more “advanced” users, normal profile.sh would still be able to >>> profile, just requires more steps. >>> >>>> I think supporting both an abstraction-layer bound "simple

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

I think supporting both an abstraction-layer bound "simple mode" and a "--raw for experts" is the way to go. On Thu, Jun 19, 2025, at 1:23 PM, Jon Haddad wrote: > I understand the motivation to decouple the command line configuration from > what we expose to end users, and to an extent, agree wi

Re: [VOTE] Clarifying our JDK Support Policy

gt; >>> On Wed, Jun 18, 2025 at 8:28 AM C. Scott Andreas >>> wrote: >>>> +1 >>>> >>>>> On Jun 18, 2025, at 11:08 AM, Aleksey Yeshchenko >>>>> wrote: >>>>> +1 >>>>> >&

[RESULT][VOTE] Clarifying our JDK Support Policy

r the discussion and vote participation! - Original message - From: Josh McKenzie To: dev Subject: [VOTE] Clarifying our JDK Support Policy Date: Friday, June 13, 2025 7:56 AM [DISCUSS] thread: https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft Text to vo

Re: [VOTE] Clarifying our JDK Support Policy

; wrote: >>> >>> +1 >>> >>> On Fri, Jun 13, 2025 at 1:58 PM Josh McKenzie wrote: >>>> __ >>>> [DISCUSS] thread: >>>> https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft >>>> >>>> Text to vot

Re: Accepting AI generated contributions

Couldn't our official stance be a combination of 1 and 2? i.e. "Here's an allow list. If you're using something not on that allow list, here's some basic guidance and maybe let us know how you tried to mitigate some of this risk so we can update our allow list w/some nuance". On Mon, Jun 16, 20

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

x27;*Unsafe.park*' "${@:2}" > >>> $PID > >>> > >>> There's also some subtle issues when it's run in a container, since by > >>> default you don't have access to the perf_event_open syscall. Just > >>

Re: Question: are committers binding on CEP votes or just PMC members?

icy, as only the PMC may approve a release, but others may reject it. > > The only votes that were intended to be PMC-only were policy/governance votes. > > > On 2025/06/13 20:51:24 Josh McKenzie wrote: > > Doug had a great question that had me digging through gdoc comm

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

ps://github.com/async-profiler/async-profiler/blob/2b556680dc8f5d02c3f26ac119d835dc2381e604/src/jattach/jattach_hotspot.c#L38 > [5] https://issues.apache.org/jira/browse/CASSANDRA-20428 > [6] > https://github.com/async-profiler/async-profiler/blob/master/docs/IntegratingAsyncProfiler.m

Question: are committers binding on CEP votes or just PMC members?

Doug had a great question that had me digging through gdoc comments from 5 years ago to try and figure out the answer. Our governance page here: https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Project+Governance Felt kind of unclear on what committer votes were binding for or no

Re: [VOTE] Clarifying our JDK Support Policy

ps with it." On Fri, Jun 13, 2025, at 7:58 AM, Josh McKenzie wrote: > +1 > > On Fri, Jun 13, 2025, at 7:56 AM, Josh McKenzie wrote: >> [DISCUSS] thread: >> https://lists.apache.org/thread/vr7j2ob92k6fb

Re: [VOTE] Clarifying our JDK Support Policy

+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: > -- > *[New LTS JDK Adop

[VOTE] Clarifying our JDK Support Policy

[DISCUSS] thread: https://lists.apache.org/thread/vr7j2ob92k6fbcwvlfo60l3scylzdbft Text to vote on: -- *[New LTS JDK Adoption]* • When a new JDK goes LTS, we prioritize: • Moving trunk to build, run, pass CI,

Re: [DISCUSS] CASSSIDECAR-254 - Enabling sidecar to collect async profiles

I was curious if o3 (model from OpenAI) would be able to do a deep dive health check on a repo to assist in considering taking it as a dependency. The results can be found here: https://chatgpt.com/share/684be703-1d4c-8002-b831-f997f829f4b4 Apparently it can, and can do it quite well. This was

Re: [DISCUSS] How we handle JDK support

for a simple performance-based smoke test On Wed, Jun 11, 2025, at 4:53 PM, Josh McKenzie wrote: >> it might not always be smooth sailing – we might be losing some agility. >> But let's give it a go and find out. > Yeah, good point. When I bring it to VOTE I'll see if I can&#

Re: [DISCUSS] How we handle JDK support

> it might not always be smooth sailing – we might be losing some agility. But > let's give it a go and find out. Yeah, good point. When I bring it to VOTE I'll see if I can't massage the wording a tiny bit around our intent to get to latest LTS support on trunk but retain flexibility to wait i

Re: [DISCUSS] How we handle JDK support

> How did jdk12 suddenly appear ? How did that happen in trunk ? > While 2.0 was trunk, it must have started off as jdk11 only. During trunk dev > jdk12 was worked on, and the runtime aspect of jdk12 backported to 1.0. I'm having a hard time tracking what you're saying here. =/ Another way of p

Re: [DISCUSS] Improving the operational safety and simplicity of in-place major version upgrades

+1 that this is something that would be very valuable to our users. As to where it lives, my gut reaction is to have the coordination, stop/start, etc live inside the sidecar and lean on the DB for the durable distributed lock to make the process atomic. Ultimately I'd like to see us move to the

Re: [DISCUSS] How we handle JDK support

53 AM, Josh McKenzie wrote: > Any other thoughts on this? We think we're ready for a [VOTE] thread? > > On Tue, Jun 3, 2025, at 2:07 PM, Josh McKenzie wrote: >>> 1) As you said, in trunk, we would go with the latest language level >>> features and if we backporte

Re: [DISCUSS] How we handle JDK support

Any other thoughts on this? We think we're ready for a [VOTE] thread? On Tue, Jun 3, 2025, at 2:07 PM, Josh McKenzie wrote: >> 1) As you said, in trunk, we would go with the latest language level >> features and if we backported and these language features are not present &g

Re: [DISCUSS] CEP-49: Hardware-accelerated compression

>From skimming the CEP (limited on time): > We propose a framework which can perform the offload when hardware is > available and will default to software otherwise. The framework also allows > for additional accelerators in the future. I'm provisionally receptive to this. Not sure whether we'd

Re: [DISCUSS] How we handle JDK support

ow complex the patch is and if using the newest > language level would yield some considerable performance gains etc. > > Regards > > On Tue, Jun 3, 2025 at 4:38 PM Josh McKenzie wrote: >> __ >> I was attempting to convey the language level support for a given bran

Re: [DISCUSS] How we handle JDK support

Might be more helpful to explain > states and events at different points of branch lifecycles… > > On Tue, 3 Jun 2025 at 00:16, Josh McKenzie wrote: >> __ >> I originally had "everyone supports highest language level whee" which of >> course wou

Re: [DISCUSS] How we handle JDK support

- otherwise, you have folks starting > to use new language features and then have to rip them all out when you find > that some previous supported Cassandra release can’t use that JDK. > > Doug > >> On May 27, 2025, at 10:37 AM, Josh McKenzie wrote: >> >> rev

Re: [DISCUSS] How we handle JDK support

revised snapshot of the state of conversation here: *[New LTS JDK Adoption]* • Trunk supports 1 JDK at a time • After a branch is cut for a release, we push to get trunk to support latest LTS JDK version available at that time • Trunk targets the language level of that JDK • CI on trunk is th

Re: [DISCUSS] How we handle JDK support

ipted UDFs. If we have similar needs at any time - we can’t do such >>> breaking changes in a patch release. >>> - Benedict made a great point on performance changes with JDK upgrades - we >>> do not have regular performance testing so probably introducing a new JDK &

Re: [DISCUSS] How we handle JDK support

for trunk after we release a new > major, fixing the next release’s Java version at that point. > >> • On 21 May 2025, at 13:57, Josh McKenzie wrote: >>  >>> You don’t have to run every suite on every commit since as folks have >>> pointed out for the most part the

Re: [DISCUSS] How we handle JDK support

> You don’t have to run every suite on every commit since as folks have pointed > out for the most part the JVM isn’t culprit. Need to run it enough times to > catch when it is for some assumption of “enough”. So riffing on this. We could move to something like: • For each given supported C* br

Re: [DISCUSS] How we handle JDK support

> The problem with (2) being only "overlapping JDK version support on > consecutive releases" instead of an overlapping JDK over all `N-2` releases > is that we say we support upgrade paths that we never test (w/ > jvm-dtest-upgrade). Here, I would rather add a third LTS JDK to a release to >

Re: [DISCUSS] How we handle JDK support

> This gets stated on perhaps an annual basis, so perhaps we should start > having these conversations on wiki to avoid the repetition. I didn't state this in my original email: my goal is to come to a consensus and codify it in the wiki going forward. > * or do the two version thing and not bot

[DISCUSS] How we handle JDK support

This came up in the release versioning thread and we punted to its own thread. *Topic: How do we want to handle JDK version support in C* releases?* Oracle LTS policy here: https://www.oracle.com/java/technologies/java-se-support-roadmap.html My first rough thoughts: 1. Any given C* release wi

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

versions. 1845 in Core Cassandra, dozens in various ecosystem projects On Sat, May 17, 2025, at 10:35 AM, Mick Semb Wever wrote: > . > > On Fri, 16 May 2025 at 20:53, Josh McKenzie wrote: >> __ >> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484 >&

Re: FixVersion house cleaning

with the same final outcome. I think the straight bump to 6.x is probably better since having missing information is less misleading than having *bad* version targeting information. On Sat, May 17, 2025, at 10:30 AM, Mick Semb Wever wrote: > . > > On Sat, 17 May 2025 at 14

FixVersion house cleaning

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 specific release line, then resolve the "X" to the number of the release

Re: Welcome Bret McGuire as Cassandra PMC Member!

Congrats Bret! On Fri, May 16, 2025, at 5:13 PM, Ekaterina Dimitrova wrote: > Congrats, Bret!!! Welcome and thank you for all you do! > > On Fri, 16 May 2025 at 17:09, Marouan REJEB wrote: >> Congrats! >> >> On Fri, May 16, 2025 at 11:02 PM Mick Semb Wever wrote: >>> >>> The Project Managemen

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

https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484 I've done the following: 1. added all the cassandra subprojects into the base query that feeds the board 2. added swimlanes for the various ecosystem projects (including a 1.0 release lane for analytics and sidecar) 3. added q

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

e repaired independently. When there is data loss or >>> bit-rot in either the base table or the view, then it is the same as 2i >>> today: rebuild is required. >>> >>> > It'd be correct (if operationally disappointing) to be able to just say >>&g

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

There's bi-directional entropy issues with MV's - either orphaned view data or missing view data; that's why you kind of need a "bi-directional ETL" to make sure the 2 agree with each other. While normal repair would resolve the "missing data in MV" case, it wouldn't resolve the "data in MV that

Re: Test Strategy for Cassandra

Given the title on 20291: "Batch queries timeout when private IP of a node fails in multi-dc Cassandra setup", this seems like a prime candidate for an in-jvm dtest. The way I think about it: if I need to exercise intra-node communication or functionality to confirm that something operates the w

Re: Welcome Abe Ratnofsky as Cassandra committer!

Congratulations Abe! On Mon, May 12, 2025, at 4:16 PM, Arjun Ashok wrote: > Congratulations Abe! > >> On May 12, 2025, at 9:45 AM, 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

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

+1 On Mon, May 12, 2025, at 10:41 AM, Jon Haddad wrote: > +1 > > > On Mon, May 12, 2025 at 7:28 AM Ariel Weisberg wrote: >> Hi dev@, >> >> I would like to start the voting for CEP-46: Finish Transient >> Replication/Witnesses >> >> Proposal: >> https://cwiki.apache.org/confluence/pages/view

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

y casting objects has historically >>> >> been a source of pain for us, so it seems like the benefit would be >>> >> small if any. >>> >> >>> >> On Fri, May 9, 2025, at 10:38 AM, Jon Haddad wrote: >>> >> >>> >> W

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

> This makes me really, really concerned with how it scales, and how likely it > is to be able to schedule automatically without blowing up. It seems to me that resource-aware throttling would be the solution here, or from a more primitive case, just hard bounding threadpool size, throughput ra

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

s more than sufficient to me. No need for lots of >> ceremony, but good to keep everyone in the decision loop. >> >>> On 9 May 2025, at 13:10, Josh McKenzie wrote: >>> >>>> I think it doesn’t cost us much to briefly discuss new language features >>&

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

ably be fine? On Fri, May 9, 2025, at 7:58 AM, Benedict wrote: > > I think it doesn’t cost us much to briefly discuss new language features > before using them. Lambdas, Streams and var all have problems - and even with > the guidance we publish some are still misused. > >

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

For new feature work on trunk, targeting the highest supported language level featureset (jdk17 right now, jdk21 within the next couple of weeks) makes sense to me. For bugfixing, targeting the oldest supported GA branch and the highest language level that works there would allow maximum flexibi

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

> IMHO, focus should be on accord-based MVs. Even if that means it's blocked > on first adding support for multiple conditions. > Strongly disagree here. We should develop features to be as loosely coupled w/one another as possible w/an eye towards future compatibility and leverage but not blo

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

+1 On Tue, May 6, 2025, at 4:06 PM, Yifan Cai wrote: > +1 (nb) > > > > *From:* Ariel Weisberg > *Sent:* Tuesday, May 6, 2025 12:59:09 PM > *To:* Claude Warren, Jr > *Subject:* Re: [DISCUSS] CEP-46 Finish Transient Replication/Witnesses > > Hi, > > On Sun, May 4, 2025, at 4:57 PM, Jordan We

Re: [VOTE] Simplifying our release versioning process

>> trying to understand if we were voting on the original text or the original >> text *plus* the "we don't break things and discuss breakage before breaking >> apis" (which I still can't find on the wiki, but I am likely just bad at >> search). >>

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

+1, and open to different names. No strong opinion there. On Wed, Apr 30, 2025, at 12:55 PM, Paulo Motta wrote: > +1 to cassandra-easy-stress - looks reasonable and differentiates from > legacy cassandra-stress and slightly different from > easy-cass-stress/easy-cass-lab. > > On Wed, Apr 30,

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

This makes intuitive sense to me. In our case we could tie documentation to the process of promoting a feature from “experimental” to production ready, though I fear that might leave wiggle room for primary authors of some features to leave them as experimental forever, not desiring to take on

Welcome Jaydeepkumar Chovatia as Cassandra committer

<https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-37+Apache+Cassandra+Unified+Repair+Solution> and CASSANDRA-19918 <https://issues.apache.org/jira/browse/CASSANDRA-19918>. Please join us in congratulating and welcoming Jaydeep. Josh McKenzie on behalf of the Apache Cassandra PMC

Re: Welcome David Capwell as Cassandra PMC Member!

\o/ Congrats David! On Tue, Apr 29, 2025, at 5:51 PM, David Capwell wrote: > Thanks all =) > >> On Apr 29, 2025, at 8:22 AM, Jeremiah Jordan wrote: >> >> Congrats David! Thank you for everything you have been doing around the >> project! >> >> On Apr 29, 2025 at 9:35:02 AM, Aaron wrote: >>

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

> So while it would be nice to keep things such that someone just runs ant and > gets everything built, given this does not seem to be a standard method of > dealing with a go install in build scripts, I would suggest we stop doing it. > It looks to be very simple to install Go, so maybe switc

[RESULT][VOTE] Simplifying our release versioning process

just bad at search). > > I do agree version and feature support is perhaps a separate topic from > killing the minor (which seems unambiguously good). > > -Joey > > > On Wed, Apr 23, 2025 at 7:47 PM Josh McKenzie wrote: >> __ >> Pragmatically, I believe

Re: [VOTE] Simplifying our release versioning process

Pragmatically, I believe our in-jvm upgrade dtests require the 2 versions of C* you're testing to both support running on (and probably right now building on) a shared JDK version. So for instance, if we had: - Release 21.0.0: JDK30, JDK31 - Release 22.0.0: JDK35, JDK40 We wouldn't be able to t

  1   2   3   4   5   6   7   8   >