Re: [DISCUSS] Stream Pipelines on hot paths

> > I think this is a good general principle for *raising standards* in the > codebase like this: if somebody says something is important, and cannot be > convinced otherwise, then it should generally be treated as important. This > is different from cases where there are simply competing

Re: CCM and CASSANDRA_USE_JDK11

I'd like us to invest in unit tests and make them the contract guards. > Thank you Jacek. In the end, I feel we strayed off the topic a bit - my question was quite > concrete - I'd like to remove the CASSANDRA_USE_JDK11 knob for CCM - it > should set it appropriately for Cassandra 4 so that

Re: [DISCUSS] The way we log

> Based on these findings, I went through the code and I have incorporated > these rules and I rewrote it like this: > > 1) no wrapping in "if" if we are not logging more than 2 parameters. > 2) rewritten log messages to not contain any string concatenation but > moving it all to placeholders

Re: Updating Instaclustr donated Jenkins Agents

> This is exactly the feedback I was looking for, the last thing we want to > do is reduce the throughput of the already strained CI pipelines. > > Sounds like it's a bigger task than just cutting over to ARM, just want to > reassure you Brandon we certainly won't change anything without

Re: Updating Instaclustr donated Jenkins Agents

Jackson, we are very thankful for all the donations from Instaclustr. Getting people (and resources) involved in ARM maintenance and testing is desperately needed. More detailed feedback below. On Fri, 24 May 2024 at 16:08, Brandon Williams wrote: > On Thu, May 23, 2024 at 5:51 PM Fleming,

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.1 (2nd attempt)

With all of that said let's get to it. I’m proposing the test build of > Cassandra Java Driver 4.18.1 for release. > > sha1: cbdde2878786fa6c4077a21352cbe738875f2106 > > Git: >

Re: CCM and CASSANDRA_USE_JDK11

> > When starting Cassandra nodes, CCM uses the current env Java distribution > (defined by the JAVA_HOME env variable). This behavior is overridden in > three cases: > > - Java version is not supported by the selected Cassandra distribution - > in which case, CCM looks for supported Java

Re: [VOTE] Release Apache Cassandra 4.1.5

> > > The vote will be open for 72 hours (longer if needed). Everyone who >> > has tested the build is invited to vote. Votes by PMC members are >> > considered binding. A vote passes if there are at least three binding >> > +1s and no -1's. > > +1 Checked - signing correct - checksums are

Re: [VOTE] Release Apache Cassandra 4.0.13

> > > The vote will be open for 72 hours (longer if needed). Everyone who > > has tested the build is invited to vote. Votes by PMC members are > > considered binding. A vote passes if there are at least three binding > > +1s and no -1's. > +1 Checked - signing correct - checksums are correct -

Re: [DISCUSS] ccm as a subproject

On Wed, 15 May 2024 at 16:24, Josh McKenzie wrote: > 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

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

> > Ok, so we're got confidence now on how to approach this, confirmation from >> the project's maintainers supporting it, and interest from a handful of >> people interested in maintaining and contributing to the project. >> > > Did you talk to the current maintainers off list or did I miss some

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

donating this particular codebase, the process is largely the same and it is the Drivers subproject receiving it. On Mon, 15 Apr 2024 at 12:31, Mick Semb Wever wrote: > > > > We can open an issue with LEGAL to see what they say at least? >>> >> >> >>

Re: Missing link to KEYS files on download page

done. asc changed again, but it can also be verified against the staged artifact we voted on. On Thu, 9 May 2024 at 07:45, Justin Mclean wrote: > Hi, > > I would update the asc file (and KEYS file if needed) so that if any user > tries to verify the release, it can be verified. > > Kind

Re: Missing link to KEYS files on download page

On Wed, 8 May 2024 at 02:33, Justin Mclean wrote: > Hi, > > The Cassandra download page [1] includes signature files, but you also > need to include a link to the KEYS files to verify these. Relevant ASF > policy is here [2]. > > Trying the verify the latest source release, it fails with this

Re: CI's working, and repeatable !!

On Mon, 29 Apr 2024 at 04:08, Josh McKenzie wrote: > I want to offer a heartfelt thanks to all involved for the focus and > energy that went into this! > … I also think there'd be significant value in more of us moving towards > using the JenkinsFile where at all possible. > Appreciated Josh.

CI's working, and repeatable !!

Good news. CI on 5.0 and trunk is working again, after an unexpected 6 weeks hiatus (and a string of general problems since last year). This includes pre-commit for 5.0 and trunk working again. More info… >From 5.0 we now have in-tree a Jenkinsfile that only relies on the in-tree scripts – it

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

> > A separate subproject like dtest and the Java driver would maybe help > address concerns with introducing a gradle build system and Kotlin. > Nit, dtest is a separate repository, not a subproject. The Java driver is one repository to be in the Drivers subproject. Esoteric maybe, but ASF

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

On Fri, 26 Apr 2024 at 00:11, Jon Haddad wrote: > I should probably have noted - since TLP is no more, I renamed tlp-stress > to easy-cass-stress around half a year ago when I took it over again. > Do we have the IP cleared for donation ? At what SHA did you take and rename tlp-stress, and who

Re: [VOTE] Release Apache Cassandra 3.11.17

> Proposing the test build of Cassandra 3.11.17 for release. +1 Checked - signing correct - checksums are correct - source artefact builds - binary artefact runs - debian package runs - debian repo installs and runs

Re: [VOTE] Release Apache Cassandra 3.0.30

> Proposing the test build of Cassandra 3.0.30 for release. > +1 Checked - signing correct - checksums are correct - source artefact builds - binary artefact runs - debian package runs - debian repo installs and runs

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

We can open an issue with LEGAL to see what they say at least? >> > > > I will raise a LEGAL ticket. > > My question here is whether we have to go through the process of > best-efforts to get approval to donate (transfer copyright), or whether we > can honour the copyright on the prior work and

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

> tl,dr: > - The AUTHORS lists everyone who ever made a commit ( > https://github.com/gocql/gocql/blob/master/AUTHORS) > - The license is BSD-3 and explicitly says the copyright is owned by the > authors (https://github.com/gocql/gocql/blob/master/LICENSE#L1) > - We had a previous discussion about

Re: Welcome Brad Schoening as Cassandra Committer

Big Congrats Brad! On Wed, 21 Feb 2024 at 21:47, Josh McKenzie wrote: > 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

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

> Mick and Ekaterina (and everyone really) - any thoughts on what test > coverage, if any, we should commit to for this new configuration? > Acknowledging that we already have *a lot* of CI that we run. > Branimir in this patch has already done some basic cleanup of test variations, so this is

Re: [VOTE] Release Apache Cassandra 4.1.4

> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > +1 Checked - signing correct - checksums are correct - source

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

The current sole maintainer of the gocql driver has stated the project is essentially in attic mode and is asking for new maintainers. https://groups.google.com/g/gocql/c/v0FruczBb2w No one has suggested the repo be donated to the ASF yet, but before anyone should raise any such suggestion we

Re: [ANNOUNCE] Apache Cassandra 4.1.4 test artifact available

> cassandra-4.1 branch in Jenkins is disabled so we can't have any builds > from there for now. > Running: https://ci-cassandra.apache.org/job/Cassandra-4.1/461/ (without arm agents – we are waiting on them getting reconfigured)

Re: [VOTE] Release Apache Cassandra 4.0.12

> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > +1 Checked - signing correct - checksums are correct - source

Re: Call for Presentations closing TOMORROW: Community over Code EU 2024

The CFP for the Cassandra track at the Community Over Code EU conference, June in Bratislava, closes tomorrow (Friday) !! We'd love to hear your Cassandra experience, operating or coding. Submit before it's too late 拾 see you there, Mick On Mon, 8 Jan 2024 at 20:24, Paulo Motta wrote: > I

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

> I strongly believe that bringing Harry in-tree will help to lower the > barrier for fuzz test and simplify co-development of Cassandra and Harry. > Previously, it has been rather difficult to debug edge cases because I had > to either re-compile an in-jvm dtest jar and bring it to Harry, or >

Re: [DISCUSS] Replace Sigar with OSHI (CASSANDRA-16565)

On Mon, 18 Dec 2023 at 11:04, Claude Warren, Jr wrote: > The pull request is : https://github.com/apache/cassandra/pull/2842 > That doesn't help me much. https://github.com/Claudenw/cassandra/pull/6 is still open, and the ticket has discussions still open in its trailing comments. It would be

Re: [DISCUSS] Replace Sigar with OSHI (CASSANDRA-16565)

Can I get an another review/approval for the pull request? > https://github.com/apache/cassandra/pull/2842/files > It is not clear on the ticket what is being finally proposed, or what is to be reviewed, ref: https://github.com/Claudenw/cassandra/pull/6 Keeping the ticket up to date makes this

[ATTENTION] Forced push on cassandra-5.0 branch !!!

The cassandra-5.0 branch accidentally got 229 trunk merge commits brought into it. This has been fixed now, but required a forced push. I've gone ahead and done this quickly for the sake of avoiding most folk from seeing it. The fix was git switch cassandra-5.0 git reset --hard 2fc2be5 git

Re: Moving Semver4j from test to main dependencies

I'd like to add Semver4j to the production dependencies. It is currently on > the test classpath. The library is pretty lightweight, licensed with MIT > and has no transitive dependencies. > > We need to represent the kernel version somehow in CASSANDRA-19196 and > Semver4j looks as the right tool

Re: [DISCUSS] Replace Sigar with OSHI (CASSANDRA-16565)

> > Are there objections to making this switch and adding a new dependency? > > [1] https://github.com/apache/cassandra/pull/2842/files > [2] https://issues.apache.org/jira/browse/CASSANDRA-16565 > +1 to removing sigar and to add oshi-core

Re: Future direction for the row cache and OHC implementation

I would avoid taking away a feature even if it works in narrow set of > use-cases. I would instead suggest - > > 1. Leave it disabled by default. > 2. Detect when Row Cache has a low hit rate and warn the operator to turn > it off. Cassandra should ideally detect this and do it automatically. > 3.

Re: Future direction for the row cache and OHC implementation

> > 3. Deprecate the row cache entirely in either 5.0 or 5.1 and remove it in > a later release > I'm for deprecating and removing it. It constantly trips users up and just causes pain. Yes it works in some very narrow situations, but those situations often change over time and again just

[RELEASE] Apache Cassandra Java Driver 4.18.0 released

The Cassandra team is pleased to announce the release of Cassandra Java Driver version 4.18.0 The Source release and Binary convenience artifacts are available here: https://dist.apache.org/repos/dist/release/cassandra/cassandra-java-driver/4.18.0/ The Maven artifacts can be found at:

[RESULT][VOTE] Release Apache Cassandra Java Driver 4.18.0

> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > Vote passes with four votes (three binding).

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.0

> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > +1

Re: [VOTE] Release Apache Cassandra Java Driver 4.18.0

Thanks Alex. > The only caveat for integrators, apart from the GAV coordinates change, is > that 2 dependencies were moved to provided scope: spotbugs-annotations > and jcip-annotations, so these must be provided explicitly. > We will need to document this. They needed to be made provided

[VOTE] Release Apache Cassandra Java Driver 4.18.0

Proposing the test build of Cassandra Java Driver 4.18.0 for release. sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9 Git: https://github.com/apache/cassandra-java-driver/tree/4.18.0 Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1322

Re: Welcome Mike Adamson as Cassandra committer

Congrats Mike !! >

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

> > I think everyone agrees here, but…. these variations are still catching >> failures, and until we have an improvement or replacement we do rely on >> them. I'm not in favour of removing them until we have proof /confidence >> that any replacement is catching the same failures. Especially

Re: Voice of Apache (Feathercast) at summit?

On Tue, 5 Dec 2023 at 15:35, Rich Bowen wrote: > Hey, folks. I'll be at Cassandra Summit next week, and was wondering if > any of you who might be there would be interested in doing a podcast > interview with me for Voice Of Apache (the podcast formerly known as > Feathercast - see

[ANNOUNCE] Apache Cassandra Java Driver 4.18.0 test artifact available

The test build of Cassandra Java Driver 4.18.0 is available. sha1: 105d378fce16804a8af4c26cf732340a0c63b3c9 Git: https://github.com/apache/cassandra-java-driver/tree/4.18.0 Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1322

[RELEASE] Apache Cassandra 5.0-beta1 released

The Cassandra team is pleased to announce the release of Apache Cassandra version 5.0-beta1. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. Downloads of source and binary distributions are

[RESULT][VOTE] Release Apache Cassandra 5.0-beta1 (take2)

> The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > The vote passes with five +1s (three binding).

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

> > 1. Since long tests are just unit tests that take a long time to run, > Yes, they are just "resource intensive" tests, on par to the "large" python dtests. they require more machine specs to run. They are great candidates to improve so they don't require additional resources, but many often

Re: [VOTE] Release Apache Cassandra 5.0-beta1 (take2)

> The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > +1 Checked - signing correct - checksums are correct - source

[VOTE] Release Apache Cassandra 5.0-beta1 (take2)

Proposing the test build of Cassandra 5.0-beta1 for release. sha1: 87fd1fa88a0c859cc32d9f569ad09ad0b345e465 Git: https://github.com/apache/cassandra/tree/5.0-beta1-tentative Maven Artifacts:

[RESULT][VOTE] Release Apache Cassandra 5.0-beta1

> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > With vetoes this vote does not pass. 19011 has been committed, I

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. Strawman: Evaluate the cost and risk to us by having to keep the code. Weigh that against the effort it takes for

CASSANDRA-19054 – Community Catalyst Program

Raising for broader awareness, the project plans to announce a Catalyst program in the next few days. For further details please see CASSANDRA-19054. If you have any questions or concerns please raise them.

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

> > If you checked SHAs I suspect we would skip 90% of the dtests-jar builds > in CI? > Yes. The repeated building in each stage and split/container is nuts. This can be solved in various ways, e.g. stashes, published snapshots, … I think the stashing approach is simplest here, at the build

Pre-commit (devbranch) ci-cassandra.a.o on 5.0 and trunk unavailable

For broader awareness. The debranch job on ci-cassandra.a.o: that used for pre-commit testing; is currently not available for patches against 5.0 and trunk. Restoring it is part of CASSANDRA-18594. This was a priority up until recently, eta now is early January. Those that do not have circleci

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

On Tue, 28 Nov 2023 at 20:06, Abe Ratnofsky wrote: > Hey folks - wanted to raise a separate thread to discuss publishing of > dtest-shaded JARs on release. > > Currently, adjacent projects that want to use the jvm-dtest framework need > to build the shaded JARs themselves. This is a decent

Re: [VOTE] Release Apache Cassandra 5.0-beta1

So then cutting an alpha2 is possible. > Possible, but still leaves alpha1 as our mitigation plan and alpha2 as our best plan. Doesn't seem worth it IMHO.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

be fixing that, not having it drive our release decisions. > > Kind Regards, > Brandon > > On Tue, Nov 28, 2023 at 12:54 PM Mick Semb Wever wrote: > > > > > > > > On Tue, 28 Nov 2023 at 19:27, J. D. Jordan > wrote: > >> > >> That said. Th

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

On Tue, 28 Nov 2023 at 19:54, Dinesh Joshi wrote: > The PMC members are pleased to announce that Francisco Guerrero Hernandez > has accepted > the invitation to become committer today. > > Congratulations and welcome! Congrats !!

Re: [VOTE] Release Apache Cassandra 5.0-beta1

On Tue, 28 Nov 2023 at 19:27, J. D. Jordan wrote: > That said. This is clearly better than and with many fixes from the alpha. > Would people be more comfortable if this cut was released as another alpha > and we do beta1 once the known fixes land? > There is no way with our release process to

Re: [VOTE] Release Apache Cassandra 5.0-beta1

> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > +1 Checked - signing correct - checksums are correct - source

Re: [VOTE] Release Apache Cassandra 5.0-beta1

> > Compared to the rigor of our previous major release, this feels rushed and > timeline-driven rather than anchored in values of quality and data > integrity. > Yes, it is (unfortunately) time-driven. But rather than say rushed I would say incremental. At the Summit, whatever release we end

Re: [VOTE] Release Apache Cassandra 5.0-beta1

On Tue, 28 Nov 2023 at 18:06, Caleb Rackliffe wrote: > Just to update this thread, Mike has identified the root cause of 19011 > and in the process uncovered 2 additional very closely related issues. > (Fantastic job fuzzing there!) Fixes for all three issues are in hand, and > he continues to

Re: Include CASSANDRA-18464 in 5.0-beta1 (direct I/O support for commitlog write)

So, assuming beta2, can it be merged to cassandra-5.0 now? > Yes from me. And I would interpret Brandon and Maxwell's statements as supporting too.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

On Mon, 27 Nov 2023 at 16:28, Brandon Williams wrote: > On Mon, Nov 27, 2023 at 9:25 AM Mick Semb Wever wrote: > > > > It was agreed to move them to 5.0-rc > > Where? > Typo, "it" not "them". I'm only talking about 19011. The others were already

Re: [VOTE] Release Apache Cassandra 5.0-beta1

d for the beta release. > CASSANDRA-19039 <https://issues.apache.org/jira/browse/CASSANDRA-19039> > could also be a real problem. > > > Le dim. 26 nov. 2023 à 13:35, Mick Semb Wever a écrit : > >> >> Proposing the test build of Cassandra 5.0-beta1 for release. >> >

Re: Include CASSANDRA-18464 in 5.0-beta1 (direct I/O support for commitlog write)

I don't want to veto the 5.0-beta1 release for this. I would rather cut and include it in the next: 5.0-beta2; release. Given it's an add-on and does not change default behaviour, I believe this would be ok – if we agree. I feel this would be a better use of our time. And would mean, yes commit

[VOTE] Release Apache Cassandra 5.0-beta1

Proposing the test build of Cassandra 5.0-beta1 for release. sha1: e0c0c31c7f6db1e3ddb80cef842b820fc27fd0eb Git: https://github.com/apache/cassandra/tree/5.0-beta1-tentative Maven Artifacts:

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

Great work Sam, Alex & Marcus ! > There are about 15-20 flaky or failing tests in total, spread over several > test jobs[2] (i.e. single digit failures in a few of these). We have filed > JIRAs for the failures and are working on getting those fixed as a top > priority. CASSANDRA-19055[3] is

Re: [DISCUSS] Harry in-tree

> I had conversations with several folks, and wanted to propose to move > harry-core to Cassandra test tree. This will substantially > simplify/streamline co-development of Cassandra and Harry. With a new > HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it > will also be

Re: [DISCUSSION] CASSANDRA-19001 - JRE vs JDK runtime

> Given we have functionality that depends on a JDK, and all our testing is > done with a JDK, I'm in favour of printing a warning that JDK is > recommended, from 5.0 onwards. And before 5.0 just leaving things in the > state they are in. > Correction: ignore these two sentences. They should

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

On Sun, 5 Nov 2023 at 00:49, Paulo Motta wrote: > > With the publication of this release I would like to switch the default > 'latest' docs on the website from 4.1 to 5.0. Are there any objections to > this ? > > It looks like the switch of latest to 5.0 broken some top search links > (returns

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

we should fix it with the highest priority and get a > new 4.1.x released. Blocking 5.0 beta voting is a secondary issue to me if > we have a “data not being returned” issue in an existing release? > > > >> On Nov 4, 2023, at 11:09 AM, Benedict wrote: > >> > >

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

> With the publication of this release I would like to switch the > default 'latest' docs on the website from 4.1 to 5.0. Are there any > objections to this ? I would also like to propose the next 5.0 release to be 5.0-beta1 With the aim of reaching GA for the Summit, I would like to suggest

[RELEASE] Apache Cassandra 5.0-alpha2 released

The Cassandra team is pleased to announce the release of Apache Cassandra version 5.0-alpha2. This release contains Vector Similarity Search (CEP-30). http://cassandra.apache.org/ Downloads of source and binary distributions are listed in our download section:

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

> > > As this is alpha release - can we open a ticket to be resolved in the > next alpha/beta? It is up to PMC to decide, of course. > > No objections from me since these issues are mostly cosmetic, but it would > be nice to clear these before the next alpha/beta. I will create a ticket > for the

[RESULT][VOTE] Release Apache Cassandra 5.0-alpha2

> The vote will be open for 72 hours (longer if needed). Everyone who > has tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s and no -1's. The vote passes with 6 +1s (three binding). With the publication

Re: Immediately Deprecated Code

> My thought was that we have code that is intended to be used for a > specific time frame. > With your example of bloom filters, if that's on-disk then it is not to be removed. Specifically, code that is used in relation to a sstable format still listed in BigFormat.BigVersion (or

Re: [VOTE] Release Apache Cassandra 5.0-alpha2

> The vote will be open for 72 hours (longer if needed). Everyone who > has tested the build is invited to vote. Votes by PMC members are > considered binding. A vote passes if there are at least three binding > +1s and no -1's. +1 Checked - signing correct - checksums are correct - source

Re: Immediately Deprecated Code

For online upgrades we support skipping majors so long as the majors are adjacent. That is, any 4.x.z to any 5.x.z ( Is it recommended that you always first patch upgrade the .z to the latest before the major upgrade. ) For offline upgrades, we are aiming to maintain all compatibility. Take

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

gt;>> see it again. Clearly we need to make this explicit in the guidance docs. >>> >>> >>> Regarding the release of 5.1, I understood the proposal to be that we >>> cut an actual alpha, thereby sealing the 5.1 release from new features. >&

Re: Removal of deprecations added in Cassandra 3.x

> similarly as for Cassandra 1.x and 2.x deprecations removal done in > CASSANDRA-18959, you are welcome to comment on the removal of all stuff > deprecated in 3.x (1). > > If nobody objects after couple days I would like to proceed to the actual > removal. Please tell me if you want something

[VOTE] Release Apache Cassandra 5.0-alpha2

Proposing the test build of Cassandra 5.0-alpha2 for release. DISCLAIMER, this alpha release does not contain the features: Transactional Cluster Metadata (CEP-21) and Accord Transactions (CEP-15). These features are under discussion to be pushed to a 5.1-alpha1 release, with an eta still this

[ANNOUNCE] Apache Cassandra 5.0-alpha2 test artifact available

The test build of Cassandra 5.0-alpha2 is available. DISCLAIMER, this alpha release does not contain the features: Transactional Cluster Metadata (CEP-21) and Accord Transactions (CEP-15). These features are under discussion to be pushed to a 5.1-alpha1 release, with an eta still this year.

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

icrosoft-to-pay-legal-fees-for-customers-sued-while-using-its-ai-products/?cf-view__;!!PbtH5S7Ebw!ayp8v3C0XGwLhCQCu_FuLfvUz7V4Jgg5JGVkJGJl6DenfyeGqFvD_RAERDUr7koCoiLAnkz8q3QoF3fBz7fZ$>. > Pretty interesting, and not a step a provider would take in an environment > where things were leg

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

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 >&g

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

On Tue, 24 Oct 2023 at 12:25, Benjamin Lerer wrote: > My biggest concern with the 5.1 suggestion is that it makes the review of > TCM far more complicated than it should be. Even if all TCM patches were > fully reviewed by committers that I fully trust, due to the patch size and > the impact of

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

> > Regarding the versioning scheme, if we follow the versioning scheme we > have defined "by the book" then TCM/Accord would belong to a 6.0 version, > which I have to admit feels a bit weird but it would signal to the user > community that a major change is being introduced. I don't feel

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

The TCM work (CEP-21) is in its review stage but being well past our cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to propose the following. We merge TCM and Accord only to trunk. Then branch cassandra-5.1 and cut an immediate 5.1-alpha1 release. I see this as a

Re: CASSANDRA-18775 (Cassandra supported OSs)

> > Does anyone see any reason _not_ to do this? > Thanks for bring this to dev@ I see reason not to do it, folk do submit patches for other archs despite us not formally maintaining and testing the code for those archs. Some examples are PPC64 Big Endian (CASSANDRA-7476), s390x

Re: ci-cassandra 5.0 and trunk now uses in-tree scripts

, Mick Semb Wever wrote: > FYI > > CASSANDRA-18665 has been committed. > This makes our ci-cassandra.a.o stage jobs on 5.0 and trunk branches build > and test with the in-tree script instead of cassandra-builds. > > This is a significant change, lots of testing happened, but

ci-cassandra 5.0 and trunk now uses in-tree scripts

FYI CASSANDRA-18665 has been committed. This makes our ci-cassandra.a.o stage jobs on 5.0 and trunk branches build and test with the in-tree script instead of cassandra-builds. This is a significant change, lots of testing happened, but I'm still expecting some trouble (like everytime we touch

Re: [DISCUSS] putting versions into Deprecated annotations

On Fri, 13 Oct 2023 at 13:07, Benjamin Lerer wrote: > I was asking because outside of configuration parameters and JMX calls, > the approach as far as I remember was to just change things without using > an annotation. > Yes, it is my understanding that such deprecation is only needed on

Avoiding pushes to broken branches

I'd like to suggest some improvements for identifying and announcing broken branches and to avoid pushing commits to broken branches. For CI we should have two gates. The first is pre-commit testing, which we have already discussed, e.g. either ci-cassandra or circleci can be used (and repeated

[RESULT][VOTE] Accept java-driver

> > The vote will be open for 72 hours (or longer). Votes by PMC members are > considered binding. A vote passes if there are at least three binding +1s and > no -1's. Vote passes with 30 +1s (ten binding). This page is updated:

Re: [DISCUSS] putting versions into Deprecated annotations

> > Tangential question to this is if everything we deprecated is eligible for > removal? In other words, are there any cases when forRemoval would be > false? Could you elaborate on that and give such examples or do you all > think that everything which is deprecated will be eventually removed? >

Re: [VOTE] Accept java-driver

but I’d have expected the ASF to also want a record of the historic CLAs. > > On 6 Oct 2023, at 09:28, Mick Semb Wever wrote: > >  > > > On Thu, 5 Oct 2023 at 17:50, Jeremiah Jordan > wrote: > >> I think this is covered by the grant agreement? >> &

Re: [VOTE] Accept java-driver

On Thu, 5 Oct 2023 at 17:50, Jeremiah Jordan wrote: > I think this is covered by the grant agreement? > > https://www.apache.org/licenses/software-grant-template.pdf > > 2. Licensor represents that, to Licensor's knowledge, Licensor is > legally entitled to grant the above license. Licensor

Re: [VOTE] Accept java-driver

. On Tue, 3 Oct 2023 at 13:25, Josh McKenzie wrote: > 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 –

  1   2   3   4   5   6   7   8   9   >