Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

On Sat, 10 Dec 2022 at 23:09, Abe Ratnofsky wrote: > Sorry - responded on the take1 thread: > > Could we defer the close of this vote til Monday, December 12th after 6pm > Pacific Time? > > Jon Meredith and I have been working thru an issue blocking streaming on > 4.1 for the last couple months,

[RESULT][VOTE] Release Apache Cassandra 4.1.0 (take2)

Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative > Maven Artifacts: > https://repository.apache.org/content/repositories/orgapachec

[RELEASE] Apache Cassandra 4.1.0 GA released

The Cassandra team is pleased to announce the GA release of Apache Cassandra version 4.1.0. Apache Cassandra is a fully distributed database. It is the right choice when you need scalability and high availability without compromising performance. http://cassandra.apache.org/ Downloads of source

Re: [DISCUSSION] Cassandra's code style and source code analysis

> > Another angle I forgot to mention is that this is quite a big patch and > there are quite big pieces of work coming, being it CEP-15, for example. So > I am trying to figure out if we are ok to just merge this work first and > devs doing CEP-15 will need to rework their imports or we merge this

Re: [DISCUSS] Slack notifications for new Stack Overflow, Stack Exchange questions

> In any case, does anyone have concerns about the notifications in Slack? > Do you foresee any issues with it? Cheers! > Thanks for writing it up Erick. Perfectly fine to have a bias for action here, it being an easy-to-undo action. No objections, my only concern is if it is considered too noisy

Re: [DISCUSSION] Cassandra's code style and source code analysis

> > > 3. Total 5 groups, 2968 files to change > > ``` > org.apache.cassandra.* > [blank line] > java.* > [blank line] > javax.* > [blank line] > all other imports > [blank line] > static all other imports > ``` > 3, then 5. There's lots under com.*, net.*, org.* that is essentially the same as "a

Re: Event Report -- Cassandra Day China 2022 was a big success

> Thank you all again for introducing and approving of this Cassandra Day China > event, we also thank the people at China Golden Bridge for their dedication > throughout the weeks of preparation, without these, we wouldn’t be able to > pull this off in such a short amount of time. > > We look f

Cassandra CI Status 2023-01-07

Happy 2023 everyone! With only four months in front of us before the first 5.0 release I'm hoping we can re-energize our focus on CI and Stable Trunk. This post covers the following * Recap of CI improvements * State of Affair * The Butler (Build Lead) * Proposal for a Repeatable Container

Re: Should we change 4.1 to G1 and offheap_objects ?

> Ok, wrt G1 default, this is won't go ahead for 4.1-rc1 > > We can revisit it for 4.1.x > > We have a lot of voices here adamantly positive for it, and those of us that > have done the performance testing over the years know why. But being called > to prove it is totally valid, if you have data

Re: Should we change 4.1 to G1 and offheap_objects ?

> *+1* to changing to G1 on trunk for 5.0 and 4.1.1. We have over a > thousand clusters and over 10K nodes running on J8 and 11 with G1GC and > memory management is excellent. > Thanks for the support Brad, you're definitely not alone. Alas the project works in a consensus model, i.e. off the ob

Re: Cassandra CI Status 2023-01-07

> > *** The Butler (Build Lead) > > The introduction of Butler and the Build Lead was a wonderful > improvement to our CI efforts. It has brought a lot of hygiene in > listing out flakies as they happened. Noted that this has in-turn > increased the burden in getting our major releases out, but t

Re: Intra-project dependencies

> > I think (4) is the only sensible option. It permits different development > branches to easily reference different versions of a library and also to > easily co-develop them - from within the same IDE project, even. > I've only heard horror stories about submodules. The challenges they bring

Re: Intra-project dependencies

> - permanence from a git SHA no longer exists > > With the caveat that I haven't worked w/submodules before and only know > about them from a cursory search, it looks like git-submodule status would > show us the sha for submodules and … > That isn't one SHA, but a collection of SHAs. I'm thin

Re: Intra-project dependencies

> > … extrapolating this experience to multiple C* versions > > To include forward-merging, bisecting old history, etc etc. that's a leap of faith that I believe deserves the discussion. - patches are off submodule SHAs, not the submodule's HEAD, > > > A SHA would point to the HEAD of a given bran

Re: Merging CEP-15 to trunk

Could you file a bug report with more detail about which classes you think > are lacking adequate documentation in each project, and what you would like > to see? > I suggest instead that we open a task ticket for the merge. I 100% agree with merging work incrementally, under a feature flag, but

Re: Intra-project dependencies

> > Regarding the use of snapshots, this isn’t impossible Henrik - I floated > this as an option. But besides the additional overhead during development, > this does not maintain reproducible builds, as the snapshot can change. > You would reference the snapshot dependency by the timestamped snaps

Re: Intra-project dependencies

You would reference the snapshot dependency by the timestamped snapshot. > This makes it a reproducible build. > > > How confident are we that the repository will not alter or delete them? > They cannot be altered. I see artefacts there that are more than a decade old. But we cannot rely on thei

Re: Intra-project dependencies

Thanks David for the detailed write up. Replies inline… > We tried in-tree for in-jvm dtest and found that this broke every other > commit… maintaining the APIs across all our supported branches was too hard > to do and moving it outside of the tree helped make the upgrade tests more > stable (t

Re: [DISCUSS] Formation of Apache Cassandra Publicity & Marketing Group

> > *To achieve this, we are proposing the formation of a Publicity & > Marketing Working Group, and we are requesting your participation.* > +1 to the proposal and everything you write Patrick! I've submitted the request for the ML (can take 24 hours). Who would like to be a moderator for the l

Re: Merging CEP-15 to trunk

On Tue, 17 Jan 2023 at 10:29, Benedict wrote: > but the pre-commit gateway here is higher than the previous tickets being > worked on > > Which tickets, and why? > All tickets resolved in the feature branch to which you are now bringing from feature branch into trunk. A quick scan I see… 17103

Re: Intra-project dependencies

replies are inline to your inline replies to my inline replies 🥁 > We can ask INFRA to set up a separate snapshots repository just for us, > with a longer expiry policy. I'd rather not create extra work for infra if > there's other ways we can do this, and this approach would always require > so

Re: Intra-project dependencies

> > Both a git post-checkout and a build fail-fast will protect us here. But > the post-checkout will need to fail silently if the .git subdirectory > doesn't exist. > Correction: the build fail-fast will need to fail silently if the .git subdirectory doesn't exist.

Re: Intra-project dependencies

> Both a git post-checkout and a build fail-fast will protect us here. But >>> the post-checkout will need to fail silently if the .git subdirectory >>> doesn't exist. >>> >> >> Correction: the build fail-fast will need to fail silently if the .git >> subdirectory doesn't exist. >> > > How will thi

Re: Merging CEP-15 to trunk

These tickets have all met the standard integration requirements, so I’m > just unclear what “higher pre-commit gateway” you are referring to. > A merge into trunk deserves extra eyeballs than a merge into a feature branch. We can refer to this as a "higher pre-commit gateway" or a "second pass"

Re: Merging CEP-15 to trunk

What Benedict says is that the commits into cassandra/cep-15-accord and > cassandra-accord/trunk branch have all been vetted by at least two > committers already. Each authored by a Cassandra committer and then > reviewed by a Cassandra committer. That *is* our bar for merging into > Cassandra trun

Re: [DISCUSS] Formation of Apache Cassandra Publicity & Marketing Group

s singular >> or plural. :D Just need to know how to do it. >> >> Patrick >> >> On Fri, Jan 20, 2023 at 1:44 AM Mick Semb Wever wrote: >> >>> *To achieve this, we are proposing the formation of a Publicity & >>>> Marketing Working Group, and w

Re: Merging CEP-15 to trunk

> > The sooner it’s in trunk, the more eyes it will draw, IMO, if you are > right about most contributors not having paid attention to a feature branch. > We all agree we want the feature branch incrementally merged sooner rather than later. IMHO any merge to trunk, and any rebase and squash of n

Re: Merging CEP-15 to trunk

> But it's not merge-than-review, because they've already been > reviewed, before being merged to the feature branch, by committers > (actually PMC members)? > > You want code that's been written by one PMC member and reviewed by 2 > other PMC members to be put up for review by some random 4th

Re: [DISCUSS] Formation of Apache Cassandra Publicity & Marketing Group

The market...@cassandra.apache.org list is created. To subscribe send an email to marketing-subscr...@cassandra.apache.org from the email address you want to subscribe from. If you are a committer you can alternately use Whimsy: https://whimsy.apache.org/committers/subscribe regards, Mick On F

Re: Cassandra Summit update for 2023-01-24

> > *To create a more neutral ground that reflects our community better, Linux > Foundation Events has taken on the considerable task of running Cassandra > Summit in 2023. We are very grateful they took a chance on our community, > and we will be better for it. * > *…* > *Why is this important to

Re: Merging CEP-15 to trunk

Hi Everyone, I hope you all had a lovely holiday period. > Thank you David and Caleb for your continuous work dealing with the practicalities involved in getting the merge to happen! And thank you Benedict for starting the thread – it is an important topic for us to continue as CEPs and feature

Re: Apache Cassandra 5.0 documentation

No objections from me! And yes, 7 days have passed and no one has spoken up, you're a committer – you can assume silence is consent. Folks, Lorina's proposal here is very thorough, and it will re-organise the docs significantly. Make sure to check it out quickly if you think you might have any con

Re: [DISCUSS] Merging incremental feature work

Love the write up Henrik :-8 > On Fri, Feb 3, 2023, at 9:20 AM, Henrik Ingo wrote: > > … > 1) I assume JDK17 support is invasive, so that would suggest a feature > branch. However, the next question is, is there any risk involved in this > work (like Falcon for MySQL). Hypothetically it could be

Re: [DISCUSS] Merging incremental feature work

> To my understanding this wasn't the original desire and consensus with > JDK17, folk requested that it be introduced complete, though I cannot > actually find the reference to that. I was about to raise a thread asking > for us to instead take an incremental approach, to help us move faster and

Re: Welcome Patrick McFadin as Cassandra Committer

Long overdue with so much you have done for so many years. Congrats! On Thu, 2 Feb 2023 at 23:26, Molly Monroy wrote: > Congrats, Patrick... much deserved! > > On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker > wrote: > >> Congrats! >> >> On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer wrote: >

Re: [VOTE] Release Apache Cassandra 4.0.8

> > The vote will be open for 72 hours (longer if needed). Everyone who has > tested the build is invited to vote. Votes by PMC members are considered > binding. A vote passes if there are at least three binding +1s and no -1's. > > [1]: CHANGES.txt: > https://gitbox.apache.org/repos/asf?p=cassandr

Re: JIRA account creation request

> I would like to get my JIRA account created as I would like to contribute. > Here are my details > > email address : manishkhandelwa...@gmail.com > Your jira account has been created. You should have received an email. regards, Mick

Re: JIRA account creation request

> HI Mick, > > Could you pls. help with JIRA account for me as well ? > Done Srinivas. You should have received an email. Welcome to the Cassandra community.

Re: Intra-project dependencies

On Thu, 16 Feb 2023 at 21:43, David Capwell wrote: > After a lot of effort I think this branch is in a good state, accord feels > mostly like its in-tree and all the complexity of git is hidden mostly. I > would love more feedback as the patch is in a usable state > This work is very good, tha

Re: [EXTERNAL] Re: Cassandra CI Status 2023-01-07

8 - Test failure in >> upgrade_tests.cql_tests.cls.test_limit_ranges >> - trunk >> - AttributeError: module 'py' has no attribute 'io' >> >> *** CASSANDRA-18189 - Test failure in >> cqlsh_tests.test_cqlsh_copy.TestCqlshCopy.test_bulk_round_tr

Re: A Guest invitation to the Slack Dev Community

Invite sent to you. On Tue, 28 Feb 2023 at 08:51, Maxim Chanturiay wrote: > Hello! > > I would like to join slack dev community, as a guest. > My current email address is the one I'd like to use. > > If it is of any help, here's a link to my ASF Jira Account: > https://issues.apache.org/jira/sec

Re: [DISCUSS] Next release date

> > We forked the 4.0 and 4.1 branches beginning of May. Unfortunately, for > 4.1 we were only able to release GA in December which impacted how much > time we could spend focussing on the next release and the progress that we > could do. By consequence, I am wondering if it makes sense for us to b

Re: [DISCUSS] Next release date

> > My thoughts don't touch on CEPs inflight. > For the sake of broadening the discussion, additional questions I think worthwhile to raise are… 1. What third parties, or other initiatives, are invested and/or working against the May deadline? and what are their views on changing it? 1a. If w

Re: [EXTERNAL] [DISCUSS] Next release date

On Tue, 7 Mar 2023 at 11:20, Sam Tunnicliffe wrote: > Currently, we anticipate CEP-21 being in a mergeable state around late > July/August. > For me this is a more important reason to delay the branch date than CEP-15, it being such a foundational change. Also, this is the first feedback we've

Re: Removal of DateTieredCompactionStrategy in 5.0

> > Are people OK with the removal of DTCS in 5.0? > Yes.

Re: [EXTERNAL] Re: [DISCUSS] Next release date

> > I've also found some useful Cassandra's JIRA dashboards for previous > releases to track progress and scope, but we don't have anything > similar for the next release. Should we create it? > Cassandra 4.0GAScope > Cassandra 4.1 GA scope > https://issues.apache.org/jira/secure/RapidBoard.jspa?

Re: Role of Hadoop code in Cassandra 5.0

On Thu, 9 Mar 2023 at 18:54, Brandon Williams wrote: > I think if we reach consensus here that decides it. I too vote to > deprecate in 4.1.x. This means we would remove it in 5.0. > +1

Re: [EXTERNAL] Re: [DISCUSS] Next release date

> > One place we've been weak historically is in distinguishing between > tickets we consider "nice to have" and things that are "blockers". We don't > have any metadata that currently distinguishes those two, so determining > what our burndown leading up to 5.0 looks like is a lot more data massag

Re: [EXTERNAL] Re: [DISCUSS] Next release date

> > > One place we've been weak historically is in distinguishing between > > > tickets we consider "nice to have" and things that are "blockers". We > > > don't have any metadata that currently distinguishes those two, so > > > determining what our burndown leading up to 5.0 looks like is a lot

[DISCUSS] New dependencies with Chronicle-Queue update

JDK17 requires us to update our chronicle-queue dependency: CASSANDRA-18049 We use chronicle-queue for both audit logging and fql. This update pulls in a number of new transitive dependencies. affinity-3.23ea1.jar asm-analysis-9.2.jar asm-commons-9.2.jar asm-tree-9.2.jar asm-util-9.2.jar jffi-1.

[DISCUSS] Lift MessagingService.minimum_version to 40 in trunk

If we do not recommend and do not test direct upgrades from 3.x to 5.x, we have the opportunity to clean up a fair chunk of code by making `MessagingService.minimum_version=40` As Cassandra versions 4.x and 5.0 are all on `MessagingService.current_version=40` this would mean lifting MessagingServ

Re: [DISCUSS] New dependencies with Chronicle-Queue update

On Mon, 13 Mar 2023 at 16:39, Jeremiah D Jordan wrote: > Given we need to upgrade to support JDK17 it seems fine to me. The only > concern I have is that some of those libraries are already pretty old, for > example the most recent jna-platform is 5.13.0 and 5.5.0 is almost 4 years > old. > Go

[DISCUSS] Drop support for sstable formats m* (in trunk)

If we do not recommend and do not test direct upgrades from 3.x to 5.x, we can clean up a fair bit by removing code related to sstable formats m*, as Cassandra versions 4.x and 5.0 are all on sstable formats n*. We don't allow mixed-version streaming, so it's not possible today to stream any such

Re: [DISCUSS] New dependencies with Chronicle-Queue update

> asm-analysis-9.4.jar > asm-commons-9.4.jar > asm-tree-9.4.jar > asm-util-9.4.jar FYI, on further inspection of the posix dependency, i've excluded these four asm* dependencies.

Re: [VOTE] Release Apache Cassandra 4.1.1

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

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

Ok ok, there's a number of strong arguments to keep sstable formats around for much longer than the previous major Cassandra version, I will unset fixVersion on 18312 :-) Taking a look at the history of sstable formats. They were first introduced in version 0.7, and minor versions introduced in

Re: [DISCUSS] Drop support for sstable formats m* (in trunk)

On Fri, 17 Mar 2023 at 17:24, Brandon Williams wrote: > On Fri, Mar 17, 2023 at 9:25 AM Mick Semb Wever wrote: > > Question/Suggestion: should we improve gossip to include what the oldest > format a node has, and ensure newer versioned node joining fail/warn if it > does >

Welcome our next PMC Chair Josh McKenzie

It is time to pass the baton on, and on behalf of the Apache Cassandra Project Management Committee (PMC) I would like to welcome and congratulate our next PMC Chair Josh McKenzie (jmckenzie). Most of you already know Josh, especially through his regular and valuable project oversight and status e

Re: [EXTERNAL] Re: [DISCUSS] Next release date

> I would like to propose a partial freeze of 5.0 in June. > … > This partial freeze will be valid for every new feature except CEP-21 and > CEP-15. > +1 Thanks for summarising the thread this way Benjamin. This addresses my two main concerns: letting the branch/release date slip too much into t

Re: [EXTERNAL] Re: Cassandra CI Status 2023-01-07

> > Here comes Cassandra CI status for 2023-3-13 - 2023-23-179 : > > *** CASSANDRA-18338 > - > dtest.bootstrap_test.TestBootstrap.test_cleanup > trunk > *** CASSANDRA-18338 > - test:

Re: [EXTERNAL] [DISCUSS] Next release date

> We have a lot of significant features that have or will land soon and our > experience suggests that those merges usually bring their set of > instabilities. The goal of the proposal was to make sure that we get rid of > them before TCM and Accord land to allow us to more easily identify the > ro

Re: [EXTERNAL] [DISCUSS] Next release date

> > I'd be happier with something concrete like the following expected release > flow: > > 1) We freeze a branch > 2) To hit RC, we need green circle + no regression on ASF (or green ASF in > the future when stable) > 3) We need N weeks in this frozen state for people to test it out > 4) Once we ha

Re: [VOTE] Release Apache Cassandra 4.0.9

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

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

> > Something like "TABLESPACE" or 'TABLEGROUP" would *theoretically* better > satisfy point 1 and 2 above but subjectively I kind of recoil at both > equally. So there's that. > TABLEGROUP would work for me. Immediately intuitive. brain-storming… A keyspace today defines replication strategy

Re: [VOTE] Release Apache Cassandra 4.0.9

> Up to you to fail the vote and we realistically release 4.0.9 after Easter > -1 to the vote. I support your initial veto and reasoning, and it appears you are willing to recut once 18429 is resolved.

Re: [DISCUSS] Introduce DATABASE as an alternative to KEYSPACE

> … but that should be a different discussion about how we evolve config. > I disagree. Nomenclature being difficult can benefit from holistic and forward thinking. Sure you can label this off-topic if you like, but I value our discuss threads being collaborative in an open-mode. Sometimes the b

Re: [VOTE] CEP-26: Unified Compaction Strategy

+1 On Thu, 6 Apr 2023 at 19:32, Francisco Guerrero wrote: > +1 (nb) > > On 2023/04/06 17:30:37 Josh McKenzie wrote: > > +1 > > > > On Thu, Apr 6, 2023, at 12:18 PM, Joseph Lynch wrote: > > > +1 > > > > > > This proposal looks really exciting! > > > > > > -Joey > > > > > > On Wed, Apr 5, 2023 at

Re: [VOTE] Release Apache Cassandra 4.0.9 - SECOND ATTEMPT

On Tue, 11 Apr 2023 at 10:12, Berenguer Blasi wrote: > +1 > > On 11/4/23 9:54, Miklosovic, Stefan wrote: > … > > 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

Re: (CVE only) support for 3,11 beyond published EOL

> > There have been several discussions on slack [1], [2] to support 3.11 beyond > the date stated on the web [3] which is May-July 23 and given it's April > that's an unlikely date. > Strictly speaking it is maintained until the 5.0 GA release. We should update the downloads page accordingly.

Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

> > Yes, this would be great. Right now users are confused what EOL means and > what they can expect. > > I think the project would need to land on an agreed position. I tried to find any reference to my earlier statement around CVEs on the latest unmaintained branch but could not find it (I'm su

Re: [DISCUSS] Next release date

> >> We have a lot of significant features that have or will land soon and our >> experience suggests that those merges usually bring their set of >> instabilities. The goal of the proposal was to make sure that we get rid of >> them before TCM and Accord land to allow us to more easily identify

Re: [DISCUSS] Next release date

> > 2. When CEP-15 lands we cut alpha1, > 2a. The deadline is first week of October, anything not yet in > cassandra-5.0 is not in 5.0, > 2b. We expect a minimum two months of testing and beta+rc releases > to get to GA. > > To clarify, is the intent here to say "The deadline for cutoff is

Re: [DISCUSS] Next release date

On Mon, 17 Apr 2023 at 19:31, Caleb Rackliffe wrote: > ...or just cutting a 5.0 branch when CEP-21 is ready. > > There's nothing stopping us from testing JDK17 and TTL bits in trunk > before that. > > On Mon, Apr 17, 2023 at 11:25 AM Caleb Rackliffe > wrote: > >> > Once all CEPs except CEP-21 an

Re: [DISCUSS] Next release date

> b.) Cut a 5.0 branch when the major release-defining element (maybe > CEP-21?) merges to trunk, with the shared understanding (possibly what > we're disagreeing about) that very little of what we need to test/de-risk > is going to be inhibited by not cutting that branch earlier (and that > certai

Re: [DISCUSS] Next release date

> > My personal .02: I think we should consider branching 5.0 September 1st. > That gives us basically 12 weeks for folks to do their testing and for us > to stabilize anything that's flaky in circle or regressed in ASF CI. > I'm not for this, sorry. I see the real risk here of there being no GA

Re: [DISCUSS] Next release date

Thanks Caleb and JD, I'm keen to see us move forward. Josh, I (and others) have expressed concern about trying to use dates, and stating periods of time to achieve X, to work backwards from a desired GA date. Dates always slip, and we don't have the evidence (beyond the extreme of 6 months for 4

Re: Adding vector search to SAI with heirarchical navigable small world graph index

I was soo happy when I saw this, I know many users are going to be thrilled about it. On Wed, 26 Apr 2023 at 05:15, Patrick McFadin wrote: > Not sure if this is what you are saying, Josh, but I believe this needs to > be its own CEP. It's a change in CQL syntax and changes how clusters > op

Re: [EXTERNAL] Re: (CVE only) support for 3,11 beyond published EOL

On Sat, 15 Apr 2023 at 03:17, C. Scott Andreas wrote: > If there’s lack of clarity around EOL policy and dates, we should > absolutely make this clear. > Fix is here: https://github.com/thelastpickle/cassandra-website/tree/mck/update-5-0_dates_download_page w/ html generated here: https://raw

Re: [DISCUSS] New data type for vector search

> > My inclination then would be to say you declare an ARRAY (which > is semantic sugar for FROZEN>). This is very consistent with > our existing style. We then simply permit such columns to define ANN > indexes. > So long as nulls aren't a problem as David questions, an alternative is: FLOAT[N

Re: [DISCUSS] New data type for vector search

> > > > But suggesting that Jonathan should work on implementing general purpose > arrays seems to fall outside the scope of this discussion, since the result > of such work wouldn't even fill the need Jonathan is targeting for here. > > Every comment I have made so far I have argued that the v1 wo

Re: [DISCUSS] New data type for vector search

o have > fuzz testing on trunk so just updating > org.apache.cassandra.utils.AbstractTypeGenerators to know about this new > type means we get type coverage as well… > > I have zero issues helping to review this patch and make sure the testing > is on-par with existing types (this i

Re: [DISCUSS] New data type for vector search

t baking it for several years as a plug-in. > > On 1 May 2023, at 21:03, Mick Semb Wever wrote: > >  > > Yes! What you (David) and Benedict write beautifully supports `VECTOR > FLOAT[n]` imho. > > You are definitely bringing up valid implementation details, and that

Re: [POLL] Vector type for ML

On Tue, 2 May 2023 at 17:14, Jonathan Ellis wrote: > Should we add a vector type to Cassandra designed to meet the needs of > machine learning use cases, specifically feature and embedding vectors for > training, inference, and vector search? > > ML vectors are fixed-dimension (fixed-length) sequ

Re: [VOTE] Release Apache Cassandra 3.11.15

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

Re: [POLL] Vector type for ML

> > Did we agree on a CQL syntax? > > I don’t believe there has been a pool on CQL syntax… my understanding > reading all the threads is that there are ~4-5 options and non are -1ed, so > believe we are waiting for majority rule on this? > Re-reading that thread, IIUC the valid choices remaining

Re: [POLL] Vector type for ML

ou mentioned the first was your preference > > *Syntax* > > *Jonathan Ellis* > > *David Capwell* > > *Josh McKenzie* > > *Caleb Rackliffe* > > *Patrick McFadin* > > *Brandon Williams* > > *Mike Adamson* > > *Benedict* > > *Mick Semb Weve

Re: [VOTE] Release Apache Cassandra 3.0.29

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

Re: [DISCUSS] The future of CREATE INDEX

On Thu, 11 May 2023 at 05:27, Patrick McFadin wrote: > Having pulled a lot of developers out of the 2i fire, > Yes. I'm keen not to leave 2i as the default once SAI lands. Otherwise I agree with the deprecated first principle, but 2i is just too problematic. Just having no default in 5.0, forc

Re: [DISCUSS] The future of CREATE INDEX

> > > Given it seems most DBs have a default index (see Postgres, etc.), I tend > to lean toward having one, but that's me... > I'm for it too. Would be nice to enforce the setting is globally uniform to avoid the per-node problem. Or add a keyspace option. For users replaying <5 DDLs this woul

Re: [DISCUSS] The future of CREATE INDEX

[POLL] Centralize existing syntax or create new syntax? > > 1.) CREATE INDEX ... USING WITH OPTIONS... > 2.) CREATE LOCAL INDEX ... USING ... WITH OPTIONS... (same as 1, but > adds LOCAL keyword for clarity and separation from future GLOBAL indexes) > (1) CREATE INDEX … > [POLL] Should t

Re: [DISCUSS] Feature branch version hygiene

On Tue, 16 May 2023 at 13:02, J. D. Jordan wrote: > Process question/discussion. Should tickets that are merged to CEP feature > branches, like https://issues.apache.org/jira/browse/CASSANDRA-18204, have > a fixver of 5.0 on them After merging to the feature branch? > > > For the SAI CEP which i

Re: [DISCUSS] Feature branch version hygiene

So when a CEP slips, do we have to create a 5.1-cep-N? > No, you'd just rename it, easy to do in just one place. I really don't care, but the version would at least helps indicate what the branch is getting rebased off. > My personal view is that 5.0 should not be used for any resolved ticket

Re: [DISCUSS] Feature branch version hygiene

On Thu, 18 May 2023 at 07:23, Benedict wrote: > So we just rename alpha1 to beta1 if that happens? > Yes, agreed Benedict. > Or, we point resolved tickets straight to 5.0.0, and add 5.0-alpha1 to any > tickets with *only* 5.0.0 > This is probably the easiest for folk to understand when brows

Re: Vector search demo, and query syntax

> > > *I propose that we adopt `ORDER BY` syntax, supporting it for vector > indexes first and eventually for all SAI indexes. So this query would > becomeSELECT id, start, end, text FROM > {self.keyspace}.{self.table} ORDER BY embedding ANN OF %s LIMIT %s* > LGTM. I first stumb

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

WRT git submodules and CASSANDRA-18204, are we happy with how it is working for accord ? The time spent on getting that running has been a fair few hours, where we could have cut many manual module releases in that time. David and folks working on accord ? On Tue, 23 May 2023 at 20:09, Josh Mc

Re: [GitHub] [cassandra-analytics] frankgh opened a new pull request, #1: Provide a SecretsProvider interface to abstract the secret provisioning

Francisco, can you please put the appropriate .asf.yaml file in place so notifications are sent to correct MLs. On Tue, 23 May 2023 at 22:56, frankgh (via GitHub) wrote: > > frankgh opened a new pull request, #1: > URL: https://github.com/apache/cassandra-analytics/pull/1 > >This commit intr

Re: [DISCUSS] Bring cassandra-harry in tree as a submodule

> > So looking at accord trunk, we needed 12 votes for a release, and each > vote is a min of 3 days, so 36 days of overhead vs 5 hours of work? > That's apples and oranges (wait time vs effort time). I was most interested in (and supportive of) your qualified opinion :-) > One thing that ca

[VOTE] Release Apache Cassandra 4.0.10

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

[VOTE] Release Apache Cassandra 4.1.2

Proposing the test build of Cassandra 4.1.2 for release. sha1: c5c075f0080f3f499d2b01ffb155f89723076285 Git: https://github.com/apache/cassandra/tree/4.1.2-tentative Maven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1302/org/apache/cassandra/cassandra-all/4.1.2

Re: [VOTE] Release Apache Cassandra 4.0.10

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

  1   2   3   4   5   6   7   8   9   10   >