Re: CCM and CASSANDRA_USE_JDK11

> The scripts that are in cassandra-builds seem like a starting point for > converging different CI systems so that they run the same set of tests in as > similar environments as possible Yeah, I took a superset of circle and ASF tests to try and run :allthethings:. Part of how the checkstyle

Re: CCM and CASSANDRA_USE_JDK11

Agree with Mick on the revert, and agree w/you Jacek on this area needing to be cleaned up. I'm just as irritated as anyone about how archaic and hard to trace our CI system is (trust me. The last 9 months has been... challenging), but with things like this that are effectively API's, the

Re: [DISCUSS] ccm as a subproject

it regularly. > > Jordan > > On Thu, May 16, 2024 at 7:55 AM Josh McKenzie wrote: >> __ >>> We do still have the issues of DSE-supporting code in it, as we do with the >>> drivers. I doubt any of us strongly object to it: there's no trickery >>> happenin

Re: [DISCUSS] Gossip Protocol Change

I'm +1 to continuing work on CASSANDRA-18917 for all the reasons Jordan listed. Sounds like the request was to hit the pause button until TCM merged rather than skipping the work entirely so that's promising. On Thu, May 16, 2024, at 1:43 PM, Jon Haddad wrote: > I have also recently worked with

Re: [DISCUSS] Adding support for BETWEEN operator

> More of a "how could we technically reach mars?" discussion than a "how we > get congress to authorize a budget to reach mars?" Wow - that is genuinely a great simile. Really good point. To Jeff's point - want to kick off a [DISCUSS] thread referencing this thread Jon so we can take the

Re: [DISCUSS] ccm as a subproject

s a separate discussion IMO > > - - -- --- - - > Jacek Lewandowski > > > czw., 16 maj 2024 o 10:21 Berenguer Blasi > napisał(a): >> __ >> +1 ccm is super useful >> >> On 16/5/24 10:09, Mick Semb Wever wrote: >>> >>> >>>

[DISCUSS] ccm as a subproject

Right now ccm isn't formally a subproject of Cassandra or under governance of the ASF. Given it's an integral components of our CI as well as for local testing for many devs, and we now have more experience w/our muscle on IP clearance and ingesting / absorbing subprojects where we can't track

Re: [DISCUSS] Adding support for BETWEEN operator

> Is there a technical limitation that would prevent a range write that > functions the same way as a range tombstone, other than probably needing a > version bump of the storage format? The technical limitation would be cost/benefit due to how this intersects w/our architecture I think. Range

Re: Is there appetite to maintain the gocql driver (in the drivers subproject) ?

Does anyone call out the need for a new CEP for bringing the gocql into the Driver's subproject ? > My suggestion is that this falls under CEP-8, even if it is not DataStax > donating this particular codebase, the process is largely the same and it is > the Drivers subproject receiving it. +1

Re: [DISCUSS] guardail for global schema modifcations - CASSANDRA-19556 in the context of CASSANDRA-17495

> Given that CASSANDRA-17495 was not released in any GA (just in 5.0-alpha1), I > think that the option 1) is still viable - we would drop CASSANDRA-17495 and > we would have CASSANDRA-19556 instead of that which would act as a global > on/off on all schema modifications however given that we

Re: CI's working, and repeatable !!

A huge amount of work and time went into this and it's going to have a big impact on the project. I want to offer a heartfelt thanks to all involved for the focus and energy that went into this! As the author of the system David lovingly dubbed "JoshCI" (/sigh), I definitely want to see us all

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

> might get roasted for scope creep This community *would never*. What you've outlined seems like a very reasonable stretch goal or v2 to keep in mind so we architect something in v1 that's also supportive of a v2 keyspace only migration. On Thu, Apr 25, 2024, at 1:57 PM, Venkata Hari Krishna

Re: Welcome Alexandre Dutra, Andrew Tolbert, Bret McGuire, Olivier Michallat as Cassandra Committers

Congrats everyone and thanks for all the hard work to get things to this point! On Wed, Apr 17, 2024, at 1:18 PM, Ekaterina Dimitrova wrote: > Congrats and thank you for all your work on the drivers! > > On Wed, 17 Apr 2024 at 13:17, Francisco Guerrero wrote: >> Congratulations everyone! >> >>

Re: [DISCUSS] Modeling JIRA fix version for subprojects

+1 to separate JIRA projects per subproject. Having workflows distinct to each project is reason enough for me, nevermind the global namespace pollution that occurs if you pack a bunch of disparate projects together into one instance. On Mon, Apr 8, 2024, at 9:11 PM, Dinesh Joshi wrote: > hi

Re: [DISCUSS] Fixing coverage reports for jvm-dtest-upgrade

+1 from me > If classloaders are appropriately named in the current versions of Cassandra, > we should be able to test upgrade paths to that version without updating the > older branches or building new jvm-dtest JARs for them. Pretty sure Caleb was wrestling w/something recently that might

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

Looks like we bumped from 3.6 requirement to 3.7 in CASSANDRA-18960 as well - similar thing. Vector support in python, though that patch took it from "return a simple blob" to "return something the python driver knows about, but apparently

Re: [Discuss] Repair inside C*

be a good opportunity to consider the sidecar to host >> repair scheduling, since this looks to be a control plane responsibility? >> One downside is that this would not make repair scheduling available to >> users who do not use the sidecar. >> >> What do you think? It

Re: [Discuss] Repair inside C*

Very late response from me here (basically necro'ing this thread). I think it'd be useful to get this condensed into a CEP that we can then discuss in that format. It's clearly something we all agree we need and having an implementation that works, even if it's not in your preferred execution

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

ople on this thread, but I figured >> I'd post it just in case :) >> >> On Tue, Jan 30, 2024 at 11:58 AM Josh McKenzie wrote: >>> __ >>>> 2.) We should make sure the links between the "known" root causes of >>>> cascading failures and the mechanisms

Welcome Brad Schoening as Cassandra Committer

The Apache Cassandra PMC is pleased to announce that Brad Schoening has accepted the invitation to become a committer. Your work on the integrated python driver, launch script environment, and tests has been a big help to many. Congratulations and welcome! The Apache Cassandra PMC members

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

> Would it make sense to only block commits on the test strategy you've listed, > and shift the entire massive test suite to post-commit? > Lots and lots of other emails ;) There's an interesting broad question of: What config do we consider "recommended" going forward, the "conservative"

Re: [Discuss] "Latest" configuration for testing and evaluation (CASSANDRA-18753)

> When we have failing tests people do not spend the time to figure out if > their logic caused a regression and merge, making things more unstable… so > when we merge failing tests that leads to people merging even more failing > tests... What's the counter position to this Jacek / Berenguer?

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

> 2.) We should make sure the links between the "known" root causes of > cascading failures and the mechanisms we introduce to avoid them remain very > strong. Seems to me that our historical strategy was to address individual known cases one-by-one rather than looking for a more holistic

Welcome Maxim Muzafarov as Cassandra Committer

The Apache Cassandra PMC is pleased to announce that Maxim Muzafarov has accepted the invitation to become a committer. Thanks for all the hard work and collaboration on the project thus far, and we're all looking forward to working more with you in the future. Congratulations and welcome!

Re: [DISCUSSION] CEP-38: CQL Management API

> Fundamentally, I think it's better for the project if administration is fully > done over CQL and we have a consistent, single way of doing things. Strongly agree here. With 2 caveats: 1. Supporting backwards compat, especially for automated ops (i.e. nodetool, JMX, etc), is crucial.

Re: [DISCUSS] CEP-39: Cost Based Optimizer

ally when you > have the new ANN OF operator in use combined with index queries. Depending > on what order you query the indexes in, it can dramatically change the > performance of the query. We are seeing and working through such issues in > Astra today. > > -Jeremiah > &g

Re: [DISCUSS] CEP-39: Cost Based Optimizer

t; >>>>>> In my mental model a no-op optimizer just becomes what we have today >>>>>> (since all new features really should be disabled by default, I would >>>>>> hope we support this), so we benefit from having a logical AST + ability >

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

touch the configs we use in > CI, causing us to waste resources… Can we solve this in junit4 param logic… > no clue… > >> On Dec 15, 2023, at 6:52 PM, Josh McKenzie wrote: >> >>> First of all - when you want to have a parameterized test case you do not >>>

Re: Future direction for the row cache and OHC implementation

t; > I offered to do the work and asked for permission to contribute it and no > response. Followed up later with a ping and also no response. > > Ariel > > On Fri, Dec 15, 2023, at 9:58 PM, Josh McKenzie wrote: >>> I have reached out to the original maintainer about it

Re: Moving Semver4j from test to main dependencies

+1 On Fri, Dec 15, 2023, at 1:29 PM, Derek Chen-Becker wrote: > +1 > > Semver4j seems reasonable to me. I looked through the code and it's > relatively easy to understand. I'm not sure how easy it would be to replace > CassandraVersion, but that's not an immediate concern I guess. > > Cheers,

Re: Future direction for the row cache and OHC implementation

> I have reached out to the original maintainer about it and it seems like if > we want to keep using it we will need to start releasing it under a new > package from a different repo. > the current maintainer is not interested in donating it to the ASF Is that the case Ariel or could you just

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

> First of all - when you want to have a parameterized test case you do not > have to make the whole test class parameterized - it is per test case. Also, > each method can have different parameters. This is a pretty compelling improvement to me having just had to use the somewhat painful and

Re: Custom FSError and CommitLog Error Handling

Adding a poison-pill error option on finding of corrupt data makes sense to me. Not sure if there's enough demand / other customization being done in this space to justify the user customizable aspect; any immediate other approaches come to mind? If not, this isn't an area of the code that's

Re: [DISCUSS] CEP-39: Cost Based Optimizer

> Goals > • Introduce a Cascades(2) query optimizer with rules easily extendable > • Improve query performance for most common queries > • Add support for EXPLAIN and EXPLAIN ANALYZE to help with query > optimization and troubleshooting > • Lay the groundwork for the addition of features

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

> Unit tests that fail consistently but only on one configuration, should not > be removed/replaced until the replacement also catches the failure. > along the way, people have decided a certain configuration deserves > additional testing and it has been done this way in lieu of any other more

Re: Welcome Mike Adamson as Cassandra committer

Congrats Mike! Good to see this recognition of your contributions to the project! On Fri, Dec 8, 2023, at 10:02 AM, Patrick McFadin wrote: > Yay! Congratulations Mike. Well deserved! > > On Fri, Dec 8, 2023 at 7:00 AM Andrés de la Peña wrote: >> Congrats Mike! >> >> On Fri, 8 Dec 2023 at

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

e could look to deprecate them. > >> On 30 Nov 2023, at 17:20, Josh McKenzie wrote: >>  >> Strongly agree. I started working on a declarative refactor out of our CI >> configuration so circle, ASFCI, and other systems could inherit from it (for >> instance, see pre-

Re: Removal of deprecations added in Cassandra 3.x

> Personally, I think the removal of the deprecated code which was marked like > that in 3.x is quite safe to do in 5.x but I have to ask broader audience to > have a consensus. Safe for us, sure. Safe for our users, not so much. No amount of including it in release notes guarantees they'll see

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

Strongly agree. I started working on a declarative refactor out of our CI configuration so circle, ASFCI, and other systems could inherit from it (for instance, see pre-commit pipeline declaration here

Re: [VOTE] Release Harry 0.0.2

+1 On Wed, Nov 29, 2023, at 7:03 AM, Brandon Williams wrote: > +1 > > Kind Regards, > Brandon > > On Wed, Nov 29, 2023 at 5:15 AM Alex Petrov wrote: > > > > Even though we would like to bring harry in-tree, this is not an immediate > > priority. Meanwhile, we need to unblock RPM builds for

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

Congrats Francisco! On Tue, Nov 28, 2023, at 2:37 PM, Melissa Logan wrote: > Congrats Francisco! > > On Tue, Nov 28, 2023 at 11:34 AM Vinay Chella wrote: >> Congratulations Francisco !! >> >> Thanks, >> Vinay Chella >> >> >> On Tue, Nov 28, 2023 at 11:24 AM Mick Semb Wever wrote: >>> >>>

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

Building these jars every time we run every CI job is just silly. +1. On Tue, Nov 28, 2023, at 2:08 PM, Francisco Guerrero wrote: > Hi Abe, > > I'm +1 on this. Several Cassandra-ecosystem projects build the dtest jar in > CI. We'd very > much prefer to just consumed shaded dtest jars from

Re: CEP-21 - Transactional cluster metadata merged to trunk

> on our internal CI system Some more context: This environment adheres to the requirements we laid out in pre-commit CI on Cassandra with a couple required differences. We don't yet include the resource

Re: [DISCUSS] Harry in-tree

Strong +1 to including harry in-tree and further, integrating a harry stress soak into our pre-commit and post-commit CI. On Fri, Nov 24, 2023, at 5:10 PM, Alex Petrov wrote: > Unfortunately my Harry talk got declined. Of course I’ll be happy to talk > about Harry and how it can be useful for

Re: Road to 5.0-GA (was: [VOTE] Release Apache Cassandra 5.0-alpha2)

> I think before we cut a beta we need to have diagnosed and fixed 18993 > (assuming it is a bug). Before a beta? I could see that for rc or GA definitely, but having a known (especially non-regressive) data loss bug in a beta seems like it's compatible with the guarantees we're providing for

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

. It can be > chucked out or rewoven at zero cost, but if the norms have taken hold and are > broadly understood in the same way, it won’t change much or at all, because > the actual glue is the norm, not the words, which only serve to broadcast > some formulation of the norm. > &

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

code is a formal agreed upon voting mechanism. On Wed, Nov 1, 2023, at 7:26 PM, Josh McKenzie wrote: >> Community voting is also entirely by consensus, there is no such thing as a >> simple majority community vote, technical or otherwise. > Ah hah! You're absolutely correct in that

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

. > > The norm existed before the vote, and it exists whether the vote was valid or > not. That is how things evolve on the project, we just formalise them a > little more slowly. > > >> On 1 Nov 2023, at 20:07, Josh McKenzie wrote: >>  >> First off, I app

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

gt; If they aren’t able to, the consequences of that are for them >>>>>>>>>>>>>>> to bear. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We should be working to avoid surprises as CEP start to land. >>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

>>>>>>>>>>>>>> disappointing to see it again. Clearly we need to make this >>>>>>>>>>>>>> explicit in the guidance docs. >>>>>>>>>>>>>> >>>>>>>>>&g

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

not aware that it could slip. > That's where I think more communication could help -- > > > Thanks, > German > > > > > > *From:* Josh McKenzie > *Sent:* Friday, October 27, 2023 10:13 AM > *To:* dev > *Subject:* [EXTERNAL] Re: Push TCM (CEP-21) and Ac

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

releases that folk can use through the trunk dev cycle. >>>> >>> >>>> >>> Personally, with my understanding of timelines in front of us to fully >>>> >>> review and stabilise tcm, it makes sense to branch it as soon as it's >>>&g

Project Status Update: 90-day catch-up edition [2023-10-27]

In case you're keeping score on how frequently these are coming out: *please stop*. ;) Silver lining - looks like we have a lot to discuss this round! Last update was late July and we've been churning through the 5.0 freeze and stabilization phase. *[New Contributors Getting Started] * Check

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

lly involves me saying the words "Yes, ant >> >> realclean exists. I'm not trolling you" >> >> >> >> docker pull works on every OS and curates a single node >> >> experience. >> >> >> >> >> >> >> &

Re: [DISCUSS] Allow UPDATE on settings virtual table to change running configuration

lthough the solution is self-sufficient for > > the already tagged properties, we still need to bring the rest of them > > under the framework afterwards. I'll create an issue and do it right, > > we'll be done with the inital patch. > > > > > > On Fri, 7 Jul 202

Re: CASSANDRA-18775 (Cassandra supported OSs)

+1 to drop if we're not using. On Fri, Oct 20, 2023, at 6:58 PM, Ekaterina Dimitrova wrote: > +1 on removal the whole lib if we are sure we don’t need it. Nothing better > than some healthy house cleaning > > -1 on partial removals > > On Fri, 20 Oct 2023 at 17:34, David Capwell wrote: >>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

y, if we can get a >>>>> build and docker image available ASAP with Accord, it will allow >>>>> developers >>>>> to start playing with the syntax. Up to this point, that hasn't been >>>>> widely >>>>> available unless you compi

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

> Maybe it won't be a glamorous release but shipping > 5.0 mitigates our worst case scenario. I disagree with this characterization of 5.0 personally. UCS, SAI, Trie memtables and sstables, maybe vector ANN if the sub-tasks on C-18715 are accurate, all combine to make 5.0 a pretty glamorous

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

> to 4.0 and up to trunk Think the proposal is all supported branches from 4.0 up. +1 here. On Mon, Oct 23, 2023, at 10:19 PM, guo Maxwell wrote: > +1, but I want to know why only trunk and 4.0 ? not all the versions > involved, like 4.1 ,5.0 。 > > Francisco Guerrero 于2023年10月24日周二 07:47写道：

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

>>>> in one hop. >>>>> >>>>> Nobody likes going through these upgrades. So I personally expect 5.0 to >>>>> be a largely ghost release if we go this route, adopted by few, just a >>>>> permanent burden on the merge path to

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

We discussed that at length in various other mailing threads Jeff - kind of settled on "we're committing to cutting a major (semver MAJOR or MINOR) every 12 months but want to remain flexible for exceptions when appropriate". And then we discussed our timeline for 5.0 this year and settled on

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

> This has to be in 5.0, even if it’s alpha and ships after December, or this > is going to be disaster that will take us much longer to unravel. I'm curious to hear more about this. > What is it going to take to get it into 5.0? What is off track and how did we > get here? I'm going to

Re: [DISCUSS] CommitLog default disk access mode

+1 to adding the feature, clear and easy configurability, and if after a major cycle we can say with confidence it's beating the status quo in the vast majority of general cases, flip default. I mean, logically it *should* be, but infra software at the scale we do requires great care. :) This

Re: [DISCUSS] putting versions into Deprecated annotations

> If some piece of code is not used anymore then simplifying the code is the > best thing to do In the case of unused / unreferenced, sure. In the case of "other things use this but we shouldn't add any more dependencies on this because we need to remove it", a @Deprecated annotation w/version,

Re: Avoiding pushes to broken branches

What about having a nag-bot that notifies #cassandra-dev on ASF slack hourly if the builds are broken? On Tue, Oct 10, 2023, at 8:02 AM, Mick Semb Wever wrote: > I'd like to suggest some improvements for identifying and announcing > broken branches and to avoid pushing commits to broken

Re: [DISCUSS] putting versions into Deprecated annotations

Sounds like we're relitigating the basics of how @Deprecated, forRemoval, since, and javadoc @link all intersect to make deprecation less painful ;) So: 1. Built-in java.lang.Deprecated: required 2. Can use since and forRemoval if you have that info handy and think it'd be useful (would make

Re: [DISCUSS] putting versions into Deprecated annotations

Might be nice to support a 3rd param that's a String for the reason it's deprecated. i.e. "Replaced by X", "Unmaintained", "Obsolete", "See CASSANDRA-N", link to a dev ML thread on pony mail, etc. That way if someone comes across it in the codebase they have some context to follow up on

Re: [VOTE] Accept java-driver

> I see now this will likely be instead apache/cassandra-java-driver I was wondering about that. apache/java-driver seemed pretty broad. :) >From the linked page: Check that all active committers have a signed CLA on record. TODO – attach list I've been part of these discussions and work so am

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

> it may be better to support most cloud storage > It simply only supports S3, which feels a bit customized for a certain user > and is not universal enough.Am I right ? I agree w/the eventual goal (and constraint on design now) of supporting most popular cloud storage vendors, but if we have

Re: [DISCUSS] Add JVector as a dependency for CEP-30

;> list DISCUSS thread? It applies to all source code we take in, and accept >>> copyright assignment of, not to jars we depend on and not only to vector >>> related code contributions. >>> >>>> On Sep 22, 2023, at 7:29 AM, Josh McKenzie wro

Re: [DISCUSS] Add JVector as a dependency for CEP-30

So if we're going to chat about GenAI on this thread here, 2 things: 1. A dependency we pull in != a code contribution (I am not a lawyer but my understanding is that with the former the liability rests on the provider of the lib to ensure it's in compliance with their claims to copyright and

Re: [DISCUSS] Add JVector as a dependency for CEP-30

Oops; thought I'd already +1'ed earlier in the thread. In case it wasn't clear: +1 on inclusion as-is. On Thu, Sep 21, 2023, at 4:00 PM, Josh McKenzie wrote: > My .02 re: the copyright: the library is licensed ASL v2.0. Who it's > originally copyrighted by / to (Jonathan personally, Da

Re: [DISCUSS] Add JVector as a dependency for CEP-30

My .02 re: the copyright: the library is licensed ASL v2.0. Who it's originally copyrighted by / to (Jonathan personally, DataStax as a corporate entity, Santa Claus, my dog :)) doesn't really have any impact on the legalities of our ability to make use of it or the durability or safety of the

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

I support including this in 5.0. This looks to me like a significant correctness and stabilization effort, very similar to other large bodies of work we merged in post freeze for testing and stabilizing 4.0. On Tue, Sep 19, 2023, at 5:42 PM, Chris Lohfink wrote: > I absolutely love the idea of

Re: [DISCUSS] Vector type and empty value

> I am strongly in favour of permitting the table definition forbidding nulls - > and perhaps even defaulting to this behaviour. But I don’t think we should > have types that are inherently incapable of being null. I'm with Benedict. Seems like this could help prevent whatever "nulls in primary

Re: [Discuss] cleaning up build temp files

> There's also tests that hardcode I started mentally twitching when I hit that point in the sentence. **Kill them with fire.** On Sun, Aug 13, 2023, at 4:51 PM, Mick Semb Wever wrote: >> >>

Re: [Discuss] cleaning up build temp files

> I think we want/need relative paths, e.g. "build/tmp", and if the path is in > a mounted volume there can be another container still running. Sure. The specifics of *what* path isn't interesting to me. The pattern of: 1. Let env declare where TEMP lives 2. Write things to TEMP 3. Delete things

Re: [Discuss] cleaning up build temp files

Why not use "/${CASS_BUILD_TMP}/cassandra." on a given run and then on subsequent runs "rm -rf f/${CASS_BUILD_TMP}/cassandra.*"? If CASS_BUILD_TMP is not defined, default to /tmp. "ant clean" can also wipe it. If it's a safe assumption that we only ever need 1 instance of data in that space

Re: Tokenization and SAI query syntax

, >>>>>> > > even >>>>>> > > if it means there's two ways of writing the same query. To use >>>>>> > > Caleb's >>>>>> > > example, this would mean supporting both LIKE and the `expr` column. >>>>>> > > >

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

Merge path for bugs on 3.0 is pretty brutal at this point. Good thing 2 will drop off when we GA 5.0. Updated wiki w/new branches plus some examples: link On Mon, Aug 7, 2023, at 11:18 AM, Mick

Re: [DISCUSSION] Shall we remove ant javadoc task?

k. If someone feels the task is >> >> > useful they can always implement one that does not crash and add it >> >> > back. >> >> > >> >> > -Jeremiah >> >> > >> >> > On Aug 3, 2023 at 9:59:55 AM, "Claude Warr

Re: [DISCUSS] Creating a 5.0 landing page

We actually already have an events page: https://cassandra.apache.org/_/events.html; not sure if you were saying we should add one Ekaterina or saying we should add this content there. +1 to the content there and having a landing page that points there + integrating meetups, town halls, etc.

Re: [DISCUSSION] Shall we remove ant javadoc task?

e not opening their browsers and > looking at Javadoc..." :) > > Cheers, > > Derek > > > > On Wed, Aug 2, 2023, 1:30 PM Josh McKenzie > mailto:jmcken...@apache.org>> wrote: > most people are not looking at Javadoc when working on the codebase. &g

Re: [DISCUSSION] Shall we remove ant javadoc task?

> most people are not looking at Javadoc when working on the codebase. I definitely use it extensively **inside the IDE**. But never as a compiled set of external docs. Which is to say, I'm +1 on removing the target and I'd ask everyone to keep javadoccing your classes and methods where things

Re: August 5.0 Freeze (with waivers…) and a 5.0-alpha1

+1 to what you've stated here Mick with a question: where did we land on flagging new features as experimental? Seems like it's an "at author's discretion" - search of the list turned up not too much structure there. Had a statement to that effect from Benjamin here

Re: [DISCUSS] Maintain backwards compatibility after dependency upgrade in the 5.0

+1 to the change pre 5.0. Any committers have bandwidth to review https://issues.apache.org/jira/projects/CASSANDRA/issues/CASSANDRA-14667? PR can be found here: https://github.com/apache/cassandra/pull/2238/files On Thu, Jul 27, 2023, at 7:59 AM, Maxim Muzafarov wrote: > Bump this topic up

Re: [Discuss] Repair inside C*

> The idea that your data integrity needs to be opt-in has never made sense to > me from the perspective of either the product or the end user. I could not agree with this more. 100%. > The current (and past) state of things where running the DB correctly > **requires* *running a separate

Re: [DISCUSS] Using ACCP or tc-native by default

+1 to the "on by default" camp. > What comes to mind is how we brought down people clusters and made sstables > unreadable with the introduction of the chunk_length configuration in 1.0 I think a key difference here is that changing chunk length is something that materially changes behavior and

Re: Tokenization and SAI query syntax

> `column CONTAINS term`. Contains is used by both Java and Python for > substring searches, so at least some users will be surprised by term-based > behavior. I wonder whether users are in their "programming language" headspace or in their "querying a database" headspace when interacting with

Cassandra project status, 2023-07-19

In case you were wondering, if you switch your ToDo list structure enough times you're bound to have something slip through the cracks. Like, say, a periodic project status update email. If you're curious where I landed: "All tools are comparably insufficient in different ways". /sigh Don't be

Re: Changing the output of tooling between majors

> I just find it ridiculous we can not change "someProperty: 10" to "Some > Property: 10" and there is so much red tape about that. Well, we're talking about programmatic parsing here. This feels like complaining about a compiler that won't let you build if you're missing a ; We *can* change

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

>>> we've been allowing circle to validate pre-commit and haven't been >>> multiplexing.” >>> I am interested to compare how many tickets for flaky tests we will have >>> pre-5.0 now compared to pre-4.1. >>> >>> >>> On Wed,

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

en allowing circle to validate pre-commit and haven't been >> multiplexing.” >> I am interested to compare how many tickets for flaky tests we will have >> pre-5.0 now compared to pre-4.1. >> >> >> On Wed, 12 Jul 2023 at 8:41, Josh McKenzie wrote: >>

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

t not recently. >> What is more common though is packaging errors, >> cdc/compression/system_ks_directory targeted fixes, CI w/wo upgrade tests, >> being less responsive post-commit as you already moved on,... Either the >> smoke pre-commit has approval steps for every

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

I > systems for twice the price. +1 on the proposed subsets. > > Derek > > On Mon, Jul 10, 2023 at 9:37 AM Josh McKenzie wrote: >> __ >> I'm personally not thinking about CircleCI at all; I'm envisioning a world >> where all of us have 1 CI *software* sys

Re: Removal of CloudstackSnitch

> 2) keep it there in 5.0 but mark it @Deprecated I'd say Deprecate, log warnings that it's not supported nor maintained and people to use it at their own risk, and that it's going to be removed. That is, assuming the maintenance burden of it isn't high. I assume not since, as Brandon said,

Re: [DISCUSS] When to run CheckStyle and other verificiations

> • Remove the checkstyle dependency from "jar" and "test" > • Create a single "check" target that includes all the checks we expect to > pass in the CI (currently Checkstyle, RAT, and Eclipse-Warnings), making this > task the default. +1 here. (of note: haven't forgotten the request from

Re: Fwd: [DISCUSS] Formalizing requirements for pre-commit patches on new CI

e reasonable, since it's >> unlikely to have config-specific flaky tests. As in five configs with 100 >> repetitions each. >> >> On Fri, 7 Jul 2023 at 16:14, Josh McKenzie wrote: >>> Maybe. Kind of depends on how long we write our tests to run doesn't it?

Re: Changing the output of tooling between majors

t break it for folks in nodetool" is still relevant. CQL > output is there from times of 4.0 at least (at least!) and YAML / JSON is > also not something completely new. It is not like we are suddenly forcing > people to change their habits, there was enough time to update the stuff

Re: Changing the output of tooling between majors

> Once there is, we are free to change the default output however we want. One thing I always try to keep in mind on discussions like this. A thought experiment (with very hand-wavy numbers; try not to get hung up on them): * Let's say there are 5,000 discrete "users" of C* out there (different

  1   2   3   4   5   >