Re: Welcome Jon Meredith as Cassandra committer

Congratulations Jon! On Fri, Jul 30, 2021 at 2:51 PM Jon Meredith wrote: > Thanks so much everybody, you make a person feel very welcome. > > Patrick: I was hoping nobody noticed :) > > > On Fri, Jul 30, 2021 at 1:58 PM Patrick McFadin > wrote: > > > Congratulations Jon and what great timing fo

Re: Welcome Adam Holmberg as Cassandra committer

Congrats Adam! On Tue, Aug 17, 2021 at 5:51 AM Paulo Motta wrote: > Congratulations and well deserved Adam! > > Em ter., 17 de ago. de 2021 às 03:58, Sumanth Pasupuleti < > sumanth.pasupuleti...@gmail.com> escreveu: > > > Congratulations Adam!! > > > > On Mon, Aug 16, 2021 at 10:32 PM Berenguer

Re: [VOTE] CEP-13: Denylisting partitions

+1 On Wed, Sep 8, 2021 at 11:38 AM Chris Lohfink wrote: > +1 > > On Wed, Sep 8, 2021 at 11:58 AM bened...@apache.org > wrote: > > > +1 > > > > From: Brandon Williams > > Date: Wednesday, 8 September 2021 at 17:57 > > To: dev@cassandra.apache.org > > Subject: Re: [VOTE] CEP-13: Denylisting par

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 nb 2. +1 nb 3. +1 nb I am personally excited for the foundation this new work lays. Multi-partition transactions will enable many new features and I don’t think we should hold up it’s development for missing conceptual SQL support when the community hasn’t decided on going in the SQL directi

Re: Tradeoffs for Cassandra transaction management

Hi All, First off, thank you for the very interesting technical discussions on this topic. It's been great to see some back and forth on it. I haven't been involved mainly because my research on this topic is relatively stale. I did however want to chime in to encourage us to step back and take a

Re: Welcome Sumanth Pasupuleti as Apache Cassandra Committer

Congratulations Sumanth! On Fri, Nov 5, 2021 at 12:17 PM Stefan Miklosovic < stefan.mikloso...@instaclustr.com> wrote: > Welcome! > > On Fri, 5 Nov 2021 at 20:11, Joseph Lynch wrote: > > > > Congratulations Sumanth! > > > > Well deserved!! > > > > -Joey > > > > On Fri, Nov 5, 2021 at 11:17 AM Ol

Re: [DISCUSS] Donating easy-cass-stress to the project

 > Hi folks, > > I'm familiar with the codebase and can help with the maintenance and > evolution. > I already have some additional profiles that I can push there which were > never merged in the main branch of tlp-cluster. > > I love this tool (I know I'm

Re: [DISCUSS] Donating easy-cass-stress to the project

should also start releasing >> Cassandra this way to make it easier for OSX users to install locally, but >> that's a separate discussion. >> >> Jon >> >> >> On Wed, Oct 9, 2024 at 11:48 AM Jordan West wrote: >> >>> Count me in as a cont

Re: [Discuss] Repair inside C*

Agreed with the sentiment that decomposition is a good target but out of scope here. I’m personally excited to see an in-tree repair scheduler and am supportive of the approach shared here. Jordan On Tue, Oct 22, 2024 at 08:12 Dinesh Joshi wrote: > Decomposing Cassandra may be architecturally d

Re: [DISCUSS] Donating easy-cass-stress to the project

Josh/Mick, where does that leave us? I’d like to start with the smaller scope Josh described in his last email. We can tackle in-tree/stress separately. I was going to start working on getting signed ICLAs. Does that still sound like the right next step? Or is that also not necessary unless we tak

Re: [VOTE] CEP-37: Repair scheduling inside C*

+1 On Wed, Nov 6, 2024 at 11:15 Chris Lohfink wrote: > +1 > > On Wed, Nov 6, 2024 at 11:10 AM Francisco Guerrero > wrote: > >> +1 (nb) >> >> On 2024/11/06 14:07:47 "Tolbert, Andy" wrote: >> > +1 (nb) >> > >> > On Tue, Nov 5, 2024 at 9:51 PM Josh McKenzie >> wrote: >> > >> > > +1 >> > > >> > >

Re: [VOTE] Release Apache Cassandra 4.1.7

+1. Validated by starting and creating a 3 node cluster using easy-cass-lab. Jordan On Fri, Sep 20, 2024 at 7:36 AM Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.1.7 for release. > > sha1: ca494526025a480bc8530ed3ae472ce8c9cbaf7a > Git: https://github.com/apache/cassandra/t

Re: [EXTERNAL] [Discuss] Generic Purpose Rate Limiter in Cassandra

ss (avoid workload and utilization imbalances) > > All three points are achievable with very straightforward approaches that > will not require much operator involvement. > > I guess my main point is we need to solve load balancing (summarized by > the above three points) before we start

Re: [EXTERNAL] [Discuss] Generic Purpose Rate Limiter in Cassandra

+1 to Benedict’s (and others) comments on plugability and low overhead when disabled. The latter I think needs little justification. The reason I am big on the former is, in my opinion: decisions on approach need to be settled with numbers not anecdotes or past experience (including my own). So I w

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

Agreed this would absolutely be a win. Dont see need for a flag either. On Tue, Oct 1, 2024 at 1:31 PM Caleb Rackliffe wrote: > Alrighty, with what looks like a fair amount of support, I'll declare > CASSANDRA-19968 ready > for some prelimi

Re: Re-evaluate compaction defaults in 5.1/trunk

While we continue the discussion here on short term defaults do we all feel it would be beneficial to start a new thread on what is required to get UCS over the line as a default? So we can have both discussions going at once? On Sun, Dec 8, 2024 at 8:44 AM Paulo Motta wrote: > > Hi Dave, > > I

Path to UCS being default our compaction strategy

Splitting this out from the other thread. It seems like there is broad support for eventually moving towards UCS as our default compaction strategy. What do we think needs to be completed ahead of that change. What I've heard so far: * Time / more reports of use in production - In particular for m

Re: Re-evaluate compaction defaults in 5.1/trunk

Generally agree with the following sentiments: - LCS as the stable default, it’s not perfect and can blow up but it’s the best in the majority of cases. All of the compaction strategies come with foot guns of varying sizes. If STCS is replaced by UCS it definitely should not be the default. - mov

Re: Re-evaluate compaction defaults in 5.1/trunk

tless. > > The main grievances over UCS all seem to be doc related, and a lack of > experience. These are both fixable problems. > > Jon > > > > > On Sat, Dec 7, 2024 at 9:48 AM Jordan West wrote: > >> Generally agree with the following sentiments: >> >>

Capabilities

In a recent discussion on the pains of upgrading one topic that came up is a feature that Riak had called Capabilities [1]. A major pain with upgrades is that each node independently decides when to start using new or modified functionality. Even when we put this behind a config (like storage compa

Re: Default sorting in nodetool status CASSANDRA-20104

I don’t have a strong preference. I agree with Chris that for those clusters not using vnodes, by token is nice. Not sure if it’s worth having the branching for that or just pick some other default and let people use the sort flags to sort by token when applicable. Jordan On Fri, Dec 13, 2024 at

Re: Default sorting in nodetool status CASSANDRA-20104

I think it’s good we have a yaml/json option but don’t think that rules out having sorting when not using that output type. Jordan On Fri, Dec 13, 2024 at 15:26 Abe Ratnofsky wrote: > Looks like we’re moving towards supporting JSON output for nodetool > commands: > > CASSANDRA-12698

Re: Capabilities

Capabilities are built on TCM and I wanted to do Guardrails on TCM too >> but was explained it is probably too soon, I guess you would experience >> something similar. >> >> Sam's comment is from May and maybe a lot has changed since in then and >> his comment i

Re: Capabilities

One minor clarification: ETS is entirely in memory (unless you explicitly dump it to disk or use DETS) so the equivalence to a local system table is only partially accurate but I think the parallel is fine in the case of what I was describing. Jordan On Fri, Dec 20, 2024 at 09:07 Jordan West

Re: Capabilities

ttle bit of a pushback (1) >>>>> (even though super reasonable one) that TCM is just too young at the >>>>> moment >>>>> and it would be desirable to go through some stabilisation period. >>>>> >>>>> Another idea was that we should

Re: Capabilities

ndividual node configures itself > in some way or not to comply? > > Is there any intersection in these approaches? At first sight it seems > somehow related. How is one different from another from your point of view? > > Regards > > (1) https://issues.apache.org/jira/browse/CAS

Re: Capabilities

places we > risk this the better IMO. > > Of course, there are steps we could take to expose a limited API targeting > these use cases, as well as using a separate log for ancillary > functionality, that might better balance risk:reward. But equally I’m not > sure it makes se

Patrick McFadin joins the PMC

The PMC's members are pleased to announce that Patrick McFadin has accepted an invitation to become a PMC member. Thanks a lot, Patrick, for everything you have done for the project all these years. Congratulations and welcome!! The Apache Cassandra PMC

What branches should perf fixes be targeting

Hi folks, A topic that’s come up recently is what branches are valid targets for performance improvements. Should they only go into trunk? This has come up in the context of BTI improvements, Dmitry’s work on reducing object overhead, and my work on CASSANDRA-15452. We currently have guidelines p

Re: [DISCUSS] Review Guide for the project

I generally support a guide we can point new contributors to as well. Jordan On Sat, Jan 18, 2025 at 10:20 Dinesh Joshi wrote: > As a growing community with new committers and contributors, I would > support establishing a review guide to ensure consistency and uniformity of > feedback. > > On

Re: Checkstyle as style contract for Cassandra

I too had the same experience as Jon (not with Go but with a project that had a pre-commit linter and another that did it in IntelliJ — much nicer than the pre-commit formatter). If we have a guide it should be as automatable as possible. I feel strongly about that. From the responses I also think

Re: [DISCUSS] Bracing style on trunk

While on the surface I would like to change the rules going forward, the special or hybrid rules sound like a nightmare for lingers. I’m -1 unless the change comes with functional changes to e.g. the idea files etc. if someone wants to take that on I’m all for modernizing the style guide. Jordan

Re: [DISCUSS] 5.1 should be 6.0

Mick, There is a lot to respond to here and I think we might need a few other threads to avoid a spidering conversation but I wanted to respond to what I saw is at least part of the crux of your concern: our recommended upgrade paths. To take a snippet from your email "A little empathy for our use

Re: What branches should perf fixes be targeting

ing deep in the storage engine to be 1% faster is not worth the risk, > because most users will skip the type of qualification that finds those one > in a billion regressions. > > Patch releases are for bug fixes not perf improvements. > > > On Jan 21, 2025, at 9:10 PM, Jord

Re: What branches should perf fixes be targeting

come up between community members and I wanted to bring it to the broader mailing list is all. On Tue, Jan 21, 2025 at 6:35 PM Jordan West wrote: > Thanks for the initial feedback. I hear a couple different themes / POVs. > > David/Paulo, it sounds like maybe a guide for perf ba

Re: EmbeddedCassandraService - still supported?

Setting up IntelliJ, running Cassandra and cqlsh/nodetool locally, and using the debugger is also a great way to familiarize Jordan On Tue, Jan 14, 2025 at 17:11 Brandon Williams wrote: > I've sent a slack invite to your email. The embedded service is no longer > around, perhaps try the docker

Re: Checkstyle as style contract for Cassandra

IMO the more we can enforce the style guide programmatically the better. It was a big improvement when we got parts of it in IntelliJ. It saves time and reduces friction. The burden shouldn’t be on humans to place or check that every curly brace is on its own line. And if we say don’t check during

Re: Checkstyle as style contract for Cassandra

during reviews. > > On Thu, Jan 16, 2025 at 8:44 PM Jordan West wrote: > >> IMO the more we can enforce the style guide programmatically the better. >> It was a big improvement when we got parts of it in IntelliJ. It saves time >> and reduces friction. The burden shouldn

Re: Merging compaction improvements to 5.0

Regarding the buffer size, it is configurable. My personal take is that we’ve tested this on a variety of hardware (from laptops to large instance sizes) already, as well as a few different disk configs (it’s also been run internally, in test, at a few places) and that it has been reviewed by four

Re: Merging compaction improvements to 5.0

disk access patterns during compaction and range > reads (PR available) https://github.com/apache/cassandra/pull/3606 > > Thanks, > > – Scott > > On Feb 12, 2025, at 9:45 PM, guo Maxwell wrote: > > > Of course, I definitely hope to see it merged into 5.0.x as

Re: Merging compaction improvements to 5.0

Thanks for the write up Mick. I think its is a great evaluation of 15452. A few notes below: * CI links for 15452 might be burried and I may need to link the most recent run (I’ve been using CircleCI since it’s what I’m familiar with — happy to have runs on ASf hardware as well). * 15452 is confi

Re: [DISCUSS] 5.1 should be 6.0

I am +1 on 6.0 as well. The other topics brought up on this thread are important, and we should address them, but I think we can move forward with the version decision in parallel. Jordan On Thu, Apr 10, 2025 at 11:50 AM Brad wrote: > > . I assume JDK 21 may lead to removal of JDK 11 which is b

Re: [DISCUSS] 5.1 should be 6.0

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 bring up are important. But I don’t think they are required for the community to decide we are calling this 6.0. We’ve tried that approach and we

Re: [VOTE] Simplifying our release versioning process

+1 On Thu, Apr 17, 2025 at 12:14 Jeremiah Jordan wrote: > +1 > > On Apr 17, 2025 at 10:58:24 AM, Josh McKenzie > wrote: > >> [DISCUSS] thread: >> https://lists.apache.org/thread/jy6vodbkh64plhdfwqz3l3364gsmh2lq >> >> The proposed new versioning mechanism: >> >>1. We no longer use semver .MI

Re: CEP-15 Update

the community to removing this work would be >>> very high. But, I do not intend to argue Accord’s case here. I will let you >>> all decide. >>> >>> Please decide soon though, as it shapes our work planning. The positive >>> reception so far had lead me t

Re: Project hygiene on old PRs

If we want something to happen repeatably we should automate it not add more manual tasks to the list. Paulo’s suggestion seems to be in line with that so +1 to something in that direction. We continually are swimming upstream making up our own process. The ask to put the ticket number in the PR

Re: Merging compaction improvements to 5.0

/apache/cassandra/commit/17cb89208c804680ffd4445d6a826171a67edb79 Jordan On Mon, Apr 14, 2025 at 5:00 AM Chris Lohfink wrote: > +1 > > On Sun, Apr 13, 2025 at 12:32 PM Jordan West wrote: > >> Hi Folks, >> >> A bit delayed but I have the backport for 20092 ready. T

Re: Welcome David Capwell as Cassandra PMC Member!

Congratulations!!! On Mon, Apr 28, 2025 at 2:43 PM David Capwell wrote: > Thanks everyone =) > > On Apr 28, 2025, at 2:13 PM, Bernardo Botella < > conta...@bernardobotella.com> wrote: > > Oh wow that’s awesome David!! > > Congratulations!! > > On Apr 28, 2025, at 1:09 PM, Pavel Yaskevich wrote:

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

Should we consider making that the default and then passing false explicitly in CI/builds? I agree with Alex it’s a bit surprising and shorter build 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

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

(general@incubator cc'd) Please vote on the acceptance of the easy-cass-stress (to be renamed cassandra-stress) and its IP Clearance: https://incubator.apache.org/ip-clearance/cassandra-easy-cass-stress.html All consent from original authors of the donation, and tracking of collected CLAs, is fo

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

+1 On Wed, Apr 30, 2025 at 8:15 AM Jordan West wrote: > (general@incubator cc'd) > > Please vote on the acceptance of the easy-cass-stress (to be renamed > cassandra-stress) and its IP Clearance: > > https://incubator.apache.org/ip-clearance/cassandra-easy-cass-stress.ht

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

Jordan West wrote: > I will defer to Mick on the proposed naming, and any requirements, as that > came from the document he created that is linked at the start of the > thread. I don’t have a personal preference besides to note that it conforms > with all the other project names li

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

ming this project to cassandra-stress could >> potentially confuse users with legacy (in-tree) cassandra-stress, since >> this is the name referred to in old documentation. Not sure what would be a >> more appropriate name though, just keep easy-cass-stress perhaps? >>

Re: Welcome Jaydeepkumar Chovatia as Cassandra committer

Congratulations!! Well deserved On Wed, Apr 30, 2025 at 18:44 jay.zhuang.yahoo.com via dev < dev@cassandra.apache.org> wrote: > Congratulations Jaydeep [image: Emoji] > > On Wednesday, April 30, 2025 at 10:04:42 AM PDT, Runtian Liu < > curly...@gmail.com> wrote: > > > congratulations! > > On Wed,

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

t;> +1 (nb) >> >> >> >> -- >> >> *From:* Jon Haddad >> >> *Sent:* Wednesday, April 30, 2025 8:24:44 AM >> >> *To:* dev@cassandra.apache.org >> >> *Cc:* gene...@incubator.apache.org >> >&g

Re: Merging compaction improvements to 5.0

's less of a nice to have and more > of a "some cluster falls over periodically now". > > Ariel > > On Fri, Feb 14, 2025, at 5:23 PM, Jordan West wrote: > > Thanks for the write up Mick. I think its is a great evaluation of 15452. > A few notes below: > >

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 weekend for this. To

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

+1 to docker. It’s a relatively universal dependency at this point, allows for more repeatable builds, and doesn’t require installing software in the build. It’s not any more heavyweight that go or python and has less environment nuances. It lets us pick what python (or go) we use among many other

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

I’m generally supportive. The concept is one that I can see the benefits of and I also think the current implementation adds a lot of complexity to the codebase for being stuck in experimental mode. It will be great to have a more robust version built on a better approach. On Sun, May 4, 2025 at 0

Re: [UPDATE] CEP-37

Great work all! Another awesome milestone and huge step forward for the project! On Wed, Apr 23, 2025 at 12:47 Jaydeep Chovatia wrote: > The CEP-37 work has been successfully merged into the trunk today! Please > let me know if you have any issues. > > This merge is a massive win for Apache Cass

Re: [VOTE] Simplifying our release versioning process

I agree with Jon that I’m now a bit confused on part of what I voted for. It feels like there is more discussion to be had here. Or we need to split it into two votes if we want to make progress on the part where there is consensus and revisit where there is not. Regarding JVM version what I’ve mo

Re: [VOTE] Simplifying our release versioning process

precate, technically. >> I agree with this. I think the JVM version the server runs under and how >> we cycle those is a separate discussion from feature deprecation. >> >> There can and has been some overlap there that would need to be handled >> on a case by case b

Re: CEP-15 Update

ll let you >> all decide. >> >> Please decide soon though, as it shapes our work planning. The positive >> reception so far had lead me to consider prioritising a move to trunk-first >> development within the next week or two, and the associated work that >> en

Re: [UPDATE] CEP-37

Thank you for the update Jaydeep. Very excited to see the progress here. I’m removed the internal status of our deployment of it now but from the JIRAs, meetings, and other conversations my impression is this feature has been heavily tested and is production grade. Jordan On Fri, Mar 7, 2025 at 1

Re: CEP-15 Update

ge imbalance of over-investment to recoup, and anything >> unnecessary will be deferred. >> >> Since the feature is disabled, and the code is almost entirely isolated, >> I cannot imagine the cost to the community to removing this work would be >> very high. But, I do

Re: CEP-15 Update

ugh, as it shapes our work planning. The positive > reception so far had lead me to consider prioritising a move to trunk-first > development within the next week or two, and the associated work that > entails. However, if that was optimistic we will have to shift our plans. > > >

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

I too initially felt we should just use mounts and was excited by e.g. Single Zone Express mounting. As Cheng mentioned we tried it…and the results were disappointing (except for use cases who could sometimes tolerate seconds of p99 latency. That brought me around to needing an implementation we ow

Re: Welcome Bernardo Botella as Cassandra Committer

Congratulations!! On Tue, Mar 4, 2025 at 10:16 Arjun Ashok wrote: > Congratulations Bernardo !! > > On Mon, Mar 3, 2025 at 11:31 PM Štefan Miklošovič > wrote: > >> The Project Management Committee (PMC) for Apache Cassandra has invited >> Bernardo Botella to become a committer and we are please

Re: Welcome Aaron Ploetz as Cassandra Committer

Congratulations!! On Tue, Mar 4, 2025 at 09:57 Tolbert, Andy wrote: > Congrats Aaron! > > On Tue, Mar 4, 2025 at 11:24 AM Francisco Guerrero > wrote: > >> Congratulations Aaron! >> >> On 2025/03/04 00:23:49 Patrick McFadin wrote: >> > The Apache Cassandra PMC is very happy to announce that Aaron

Re: Welcome Ekaterina Dimitrova as Cassandra PMC member

Congratulations!!! On Wed, Mar 5, 2025 at 07:01 Abe Ratnofsky wrote: > Congratulations Ekaterina! 🎉 >

Re: CEP-15 Update

The work and effort in accord has been amazing. And I’m sure it sets a new standard for code quality and correctness testing which I’m also entirely behind. I also trust the folks working on it want to take it to the a fully production ready solution. But I’m worried about circumstances out of our

Re: CEP-15 Update

ma w nodes down issue > and anything written on it? > Yes, there is a clear known path for fixing schema changes, and gladly > they do not require a protocol change, just a slightly deeper integration > with TCM. > > > On Fri, Mar 7, 2025, at 4:44 PM, Jordan West wrote: >

Re: Welcome Jeremiah Jordan to the PMC

Congrats, JD! Welcome aboard! Jordan On Fri, Feb 14, 2025 at 11:01 Mick Semb Wever wrote: >. > > > I hope you will join me in welcoming him to the committee. > > > Welcome JD! >

Re: Welcome Caleb Rackliffe to the PMC

Congrats Caleb!! Jordan On Thu, Feb 20, 2025 at 18:13 Bernardo Botella wrote: > So many good news today! Congratulations Caleb! > > > > On Feb 20, 2025, at 4:07 PM, Ekaterina Dimitrova > wrote: > > That’s awesome addition! Well done! Thanks for everything, Caleb!! > Congrats!!! > > On Thu, 20

Re: New committers: Maxwell Guo and Dmitry Konstantinov

Congrats both! Looking forward to working with you more in the future. Jordan On Thu, Feb 20, 2025 at 14:20 Aaron wrote: > Congratulations Maxwell and Dmitry! That's awesome! > > On Thu, Feb 20, 2025 at 1:12 PM Maxim Muzafarov wrote: > >> Congratulations! >> >> On Thu, 20 Feb 2025 at 19:17, Ab

Re: Welcome Caleb Rackliffe to the PMC

Congrats Caleb!! Jordan On Wed, Feb 26, 2025 at 13:01 Mick Semb Wever wrote: > . > >> >> Please join us in welcoming Caleb to his new role! >> > > > > Congratulations Caleb !! > >

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

gt; 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 concerns. >> >>

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

It is absolutely a pain and its a bit unfortunate its still in use. this was the longest it took me to update 4 lines in a repo that I can remember. 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. Otherwis

Re: Welcome Abe Ratnofsky as Cassandra committer!

Congratulations!! On Mon, May 12, 2025 at 14:41 Josh McKenzie wrote: > 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

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

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 concerns. Jordan On Sun, May 11, 2025 at 3:31 PM Jordan West wrote: > The infra ticket is here and

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

Also Dinesh, I misunderstood your ask here. I opened this incubator ticket: https://issues.apache.org/jira/browse/INCUBATOR-288 On Mon, May 12, 2025 at 8:25 AM Jordan West wrote: > Mick I've addressed your two comments on the PR and merged it to the main > branch. I believe everythin

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

The infra ticket is here and has been open for a bit https://issues.apache.org/jira/browse/INFRA-26785 Will merge the PR when Im back at my machine Jordan On Sun, May 11, 2025 at 14:44 Mick Semb Wever wrote: > > . > > >> That said, it has been committed. I don't see it yet reflected on th

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

+1 On Mon, May 12, 2025 at 19:48 Nate McCall wrote: > +1 > > On Tue, May 13, 2025 at 2:27 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/viewpage.act

Re: [DISCUSS] How we handle JDK support

On Tue, May 20, 2025 at 08:12 Josh McKenzie wrote: > 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-ro

Re: [DISCUSS] How we handle JDK support

When I worked on Riak we had a much more complex matrix due to supporting even more backwards compatibility. It’s not unfeasible. 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 i

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

+1 On Mon, May 26, 2025 at 13:26 Jon Haddad wrote: > I have had great results with it. Shenandoah plus off heap trie memtables > can improve throughput by more than 2x when you have lower latency > requirements. > > Lets do it. > > > On Mon, May 26, 2025 at 12:00 PM Dmitry Konstantinov > wrote:

<    1   2