Re: Compact Storage and SuperColumn Tables in 4.0/trunk

4.0 should also fail startup (very early) if it still sees any non-migrated tables, probably. — AY On 19 September 2017 at 18:35:11, J. D. Jordan (jeremiah.jor...@gmail.com) wrote: Thanks for the clarification. +1 for adding a "DROP COMPACT STORAGE" option in 3.x and then not allowing it to

RE: [VOTE] Release Apache Cassandra 3.11.1

Thomas, I would maybe agree with waiting for a while because of it, if we had a proper fix at least under review - or in progress by someone. But this is not a regression, and there’s been a lot of fixes accumulated and not released yet. Arguable worse to hold them back :\ — AY On 2 October

Re: Proposal to retroactively mark materialized views experimental

ture I > think > > >> that is pretty visible during development? > > >> > > >> I guess I can see just blocking new ones without a flag set, but we > need > > >> to be careful here. We need to make sure we don’t cause a problem for > > >> someone tha

Re: Proposal to retroactively mark materialized views experimental

Yep. And that would be nice to have in addition to the opt-in flag in the yaml for the operators that’s stricter than a warning. — AY On 2 October 2017 at 22:21:33, Jeremiah D Jordan (jerem...@datastax.com) wrote: We are not saying to just put something in logs, we are talking about the warn

Re: Proposal to retroactively mark materialized views experimental

Indeed. Paulo and Zhao did a lot of good work to make the situation less bad. You did some as well. Even I retouched small parts of it - metadata related. I’m sorry if I came off as disrespectful - I didn’t mean to. I’ve seen and I appreciate every commit that went into it. It is however my

Re: Hints replay incompatible between 2.x and 3.x

It doesn’t work between any two majors (1.2 and 2.0, 2.0 and 2.1, 2.1 and 3.0). The reason is that hint delivery doesn’t proceed between two nodes unless they have the same schema version, and in every recent major release we made changes that made schema calculation differ even without any DDL

Re: [VOTE] Release Apache Cassandra 2.1.19

+1 — AY On 28 September 2017 at 19:12:19, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 2.1.19. sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c Git:

Re: Expected release date for 3.11.1?

> I appreciate the update! > > -- > Michael > > On 09/28/2017 10:50 AM, Aleksey Yeshchenko wrote: > > FWIW, none of the remaining issues are strictly speaking regressions > from previous versions. > > > > So if we felt strongly about st

Re: Proposal to retroactively mark materialized views experimental

The idea is to check the flag in CreateViewStatement, so creation of new MVs doesn’t succeed without that flag flipped. Obviously, just disabling existing MVs working in a minor would be silly. As for the warning - yes, that should also be emitted. Unconditionally. — AY On 2 October 2017 at

Re: [VOTE] Release Apache Cassandra 3.0.15

+1 — AY On 2 October 2017 at 18:18:26, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.0.15. sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773 Git:

Re: [VOTE] Release Apache Cassandra 3.11.1

+1 — AY On 2 October 2017 at 18:58:57, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.11.1. sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af Git:

Re: Proposal to retroactively mark materialized views experimental

There are a couple compromise options here: a) Introduce the flag (enalbe_experimental_features, or maybe one per experimental feature), set it to ‘false’ in the yaml, but have the default be ‘true’. So that if you are upgrading from a previous minor to the next without updating the yaml, you

Re: [VOTE] Release Apache Cassandra 3.11.1

gt;> > >> Thanks, > >> Thomas > >> > >> -Original Message- > >> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon > >> Haddad > >> Sent: Montag, 02. Oktober 2017 22:09 > >> To: d

Re: Proposal to retroactively mark materialized views experimental

Strongly disagree with MV’s being isolated part. You can feel the touch of the MVs in the read path, write path, metadata handling, whether you use them or not. And comparing any of those before/after MVs were introduced makes me sad every time I face any of it. It made our codebase

Re: Proposal to retroactively mark materialized views experimental

Yep. Almost! Changing the default in a minor version might break some scripts/tooling that manipulate schema and potentially create new MVs (as dangerous as it currently is - manipulating schema in that way), and that would still not be very nice. Introducing a flag and leaving it at false in

Re: Which approach should we use for exposing metrics through Virtual tables?

I don’t think it’s really necessary. Or at least I’m not seeing why having individual, specialised virtual tables is not sufficient. Nor do I think that we should expose everything that nodetool does, so IMO we shouldn’t aim for that. Even if the goal were to eventually deprecate and remove

Re: Testing 4.0 Post-Freeze

If we want to have a stable, usable 4.0.0 release out in the next 6-12 months, there needs to be a focused effort on getting it out - or else it’ll just never happen. This is more of a call to action and announcement of intent than an attempt to enforce policy; we can and probably will branch

Re: CASSANDRA-8527

redRowIterator interface to include the tombstones/rows/cells stats > as this is what is returned from the lower levels of the read path. > Is there any easier way to achieve this that you can think of, as that > interface is used in many parts of the code ? > > On Wed, Dec 2

Re: CASSANDRA-8527

ows" or something similar would make more sense then? Le ven. 5 janv. 2018 à 20:24, Aleksey Yeshchenko <alek...@apple.com> a écrit : > Counting the number of range tombstones - sure, that is reasonable. > > Counting cells/rows shadowed by range tombstones toward the

Re: [VOTE] Release Apache Cassandra 2.2.12

+1 — AY On 12 February 2018 at 20:31:06, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 2.2.12. sha1: 1602e606348959aead18531cb8027afb15f276e7 Git:

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

+1 — AY On 13 February 2018 at 03:41:09, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.11.2. sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d Git:

Re: [VOTE] Release Apache Cassandra 2.1.20

+1 — AY On 12 February 2018 at 20:30:58, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 2.1.20. sha1: b2949439ec62077128103540e42570238520f4ee Git:

Re: [VOTE] Release Apache Cassandra 3.0.16

+1 — AY On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.0.16. sha1: 91e83c72de109521074b14a8eeae1309c3b1f215 Git:

Re: CASSANDRA-8527

As Jeff says, the number of actual tombstones is no less relevant than the number of cells and rows shadowed by them. And the way row and cell tombstones affect a read query can be very different from the way a big range tombstone might: you potentially have to retain every (regular) tombstone

Re: GitHub PR ticket spam

Nice indeed. I assume it also doesn’t spam commits@ when done this way, in which case double +1 from me. — AY On 6 August 2018 at 17:18:36, Jeremiah D Jordan (jeremiah.jor...@gmail.com) wrote: Oh nice. I like the idea of keeping it but moving it to the worklog tab. +1 on that from me. >

Re: Side Car New Repo vs not

FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate repo, dtest-style. — AY On 21 August 2018 at 16:36:02, Jeremiah D Jordan (jeremiah.jor...@gmail.com) wrote: I think the following is a very big plus of it being in tree: >> * Faster iteration speed in general. For

Re: Side Car New Repo vs not

Aleksey, Can you please elaborate on the reasons for your -1? This way we can make progress towards any one approach. Thanks, Sankalp On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko wrote: > FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate > repo,

Re: Testing 4.0 Post-Freeze

nch off 4.0, and keep trunk > > technically active. > > These are two very different statements. :) Which is it? > > On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko > wrote: > > > If we want to have a stable, usable 4.0.0 release out in the next 6-12

Re: Testing 4.0 Post-Freeze

+1 from me too. — AY On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote: > We have done all this for previous releases and we know it has not worked > well. So how giving it one more try is going to help here. Can someone > outline what will change for 4.0 which will make

Re: Approximate 4.0 timeframe

There isn’t, or at least not that I know of. Some time this year most likely. I don’t think anybody is in a rush for 4.0, either. — AY On 23 January 2018 at 15:40:36, Jakub Janco (jja...@redhat.com) wrote: Hello, is here any update? I can't find any new information. Thanks. -- Best

Re: Roadmap for 4.0

So long as non-user-visible improvements, including big ones, can still go in 4.0 at that stage, I’m all for it. — AY On 5 April 2018 at 21:14:03, Nate McCall (zznat...@gmail.com) wrote: >>> My understanding, from Nate's summary, was June 1 is the freeze date for >>> features. I expect we

Re: Roadmap for 4.0

3.0 will be the most popular release for probably at least another couple years - I see no good reason to cap its support window. We aren’t Oracle. — AY On 3 April 2018 at 22:29:29, Michael Shuler (mich...@pbandjelly.org) wrote: Apache Cassandra 3.0 is supported until 6 months after 4.0

Re: Roadmap for 4.0

June feels a bit too early to me as well. I personally would go prefer end of August / beginning of September. +1 to the idea of having a fixed date, though, just not this one. — AY On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote: June is too early. On 05.04.18

Re: Paying off tech debt and correctly naming things

Poor and out-of-date naming of things is probably the least serious part of our technical debt. Bad factoring, and straight-up poorly written components is where it’s really at. Doing a big rename for rename sake alone does more harm than it is good, sometimes. Some of us have big patches in

Re: Using Cassandra as local db without cluster

I agree with Jeff here. Furthermore, Cassandra should generally be your solution of last resort - if nothing else works out. In your case I’d try sqlite or leveldb (or rocksdb). > On 18 Oct 2018, at 11:46, Jeff Jirsa wrote: > > I can’t think of a situation where I’d choose Cassandra as a

Re: Moving tickets out of 4.0 post freeze

We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with minor forever fixed to 0. But I’m also struggling with how to justify the existence of that unused digit. We have never really done semantic versioning, we’ve arbitrarily flipped the major whenever we felt like “it was the

Re: [VOTE] Change Jira Workflow

Sure, +1 > On 18 Dec 2018, at 09:42, Joseph Lynch wrote: > > +1 non-binding > > On Tue, Dec 18, 2018 at 1:15 AM Sylvain Lebresne wrote: > >> +1 >> -- >> Sylvain >> >> >> On Tue, Dec 18, 2018 at 9:34 AM Oleksandr Petrov < >> oleksandr.pet...@gmail.com> >> wrote: >> >>> +1 >>> >>> On Mon,

Re: JIRA Workflow Proposals

1. C, D, A, B, E 2. B, C, A 3. A 4. Meh > On 11 Dec 2018, at 16:28, Benedict Elliott Smith wrote: > > Just to re-summarise the questions for people: > > 1. (A) Only contributors may edit or transition issues; (B) Only contributors > may transition issues; (C) Only Jira-users may transition

Re: Jira: Author Field

Some of it is just for clear attribution. Occasionally, you do get an extensive review that borders on authoring/coauthoring. Sometimes you get a large body of work co-created by several people in author capacity. Having a multi-user Authors field, in addition to the multi-user Reviewers

Re: [VOTE] Release Apache Cassandra 3.11.4

+1 > On 3 Feb 2019, at 00:31, Michael Shuler wrote: > > I propose the following artifacts for release as 3.11.4. > > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 2.1.21

Not sure we need another 2.1 release, this one included, but sure, +1 So long as the branch itself stays kinda open and most critical issues can have at least fixes for them committed, the interested parties can then keep building the artefacts manually. Once 4.0 is out we can freeze the

Re: [VOTE] Release Apache Cassandra 2.2.14

+1 > On 3 Feb 2019, at 00:32, Michael Shuler wrote: > > I propose the following artifacts for release as 2.2.14. > > sha1: af91658353ba601fc8cd08627e8d36bac62e936a > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 3.0.18

+1 > On 4 Feb 2019, at 00:39, Joseph Lynch wrote: > > 3.0.18-tentative unit and dtest run: > https://circleci.com/gh/jolynch/cassandra/tree/3.0.18-tentative > > unit tests: 0 failures > dtests: 1 failure > * test_closing_connections - thrift_hsha_test.TestThriftHSHA ( >

Re: TLP tools for stress testing and building test clusters in AWS

some standardised workloads and test bed. >>> At the moment we’re benefiting from some large contributors doing their own >>> proprietary performance testing, which is super valuable and something >>> we’ve lacked before. But I’m also keen to see some more repr

Re: TLP tools for stress testing and building test clusters in AWS

Hey Jon, This sounds exciting and pretty useful, thanks. Looking forward to using tlp-stress for validating 15066 performance. We should touch base some time next week to pick a comprehensive set of workloads and versions, perhaps? > On 12 Apr 2019, at 16:34, Jon Haddad wrote: > > I don't

Re: Acceptable for trunk? Committing the patch for "Customize cassandra log directory" (CASSANDRA-15090)

Yeah. I wouldn’t even go and ask for a waiver for anything as trivial as this change. Common sense of a committer should be sufficient. > On 26 May 2019, at 09:31, Mick Semb Wever wrote: > > > The ticket CASSANDRA-15090 has a patch to introduce the variable > $CASSANDRA_LOG_DIR > >

Re: Java8 compatibility broken in 4.0

No, this is not intentional. At the very least for 4.0 we are going to keep compatibility with Java 8. > On 11 Jun 2019, at 10:04, Tommy Stendahl wrote: > > Hi, > > I can't find a way to build 4.0 artifacts so I can run Cassandra using Java8. > Building the artifacts ("ant artifacts" or "ant

Re: 4.0 alpha before apachecon?

Not really important IMO if we do or do not cut a new branch yet. So let’s hold off? But as mentioned on Slack, I really like the idea of cutting an alpha now, with clear understanding that the API will still slightly change before the 4.0-GA. There is enough complete work in trunk that will

Re: Improvements on C* v3.11

Normally we prefer new features to go to trunk. In some rare cases, when the risk is low and the value of a new feature is high, we make exceptions - but usually early in a major version life cycle, and mostly in the past, when we were a lot more lax about such things. In this particular case

Re: [VOTE] Release Apache Cassandra 3.0.19

+1 > On 24 Oct 2019, at 18:25, Michael Shuler wrote: > > I propose the following artifacts for release as 3.0.19. > > sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 2.2.15

+1 > On 24 Oct 2019, at 18:25, Michael Shuler wrote: > > I propose the following artifacts for release as 2.2.15. > > sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

+1 > On 24 Oct 2019, at 18:26, Michael Shuler wrote: > > I propose the following artifacts for release as 4.0-alpha2. > > sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 3.11.5

+1 > On 24 Oct 2019, at 18:26, Michael Shuler wrote: > > I propose the following artifacts for release as 3.11.5. > > sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative > Artifacts: >

Re: [VOTE-2] Apache Cassandra Release Lifecycle

+1 as a rather reasonable starting point; we can make changes to the process in the future if need be. > On 8 Oct 2019, at 19:00, sankalp kohli wrote: > > Hi, >We have discussed in the email thread[1] about Apache Cassandra Release > Lifecycle. We came up with a doc[2] for it. We have

Re: Protocol-impacting (internode and client) changes for 4.0

+1; in particular since the protocol itself is still in beta > On 9 Oct 2019, at 17:26, Oleksandr Petrov wrote: > > Hi, > > During NGCC/ACNA19 we've had quite a few conversations around the 4.0 > release. Many (minor) features and changes suggested during that time are > possible to implement

Re: [DISCUSS] Switch to using GitHub pull requests?

substantial, I vastly prefer to summarise my feedback (and see others’ feedback summarised) in JIRA comments - an opinion I and other contributors have shared in one or two similar threads over the years. > On 24 Jan 2020, at 12:21, Aleksey Yeshchenko > wrote: > > The person introduci

Re: [DISCUSS] Client protocol changes (Was: 20200217 4.0 Status Update)

For what it’s worth, we could trivially implement support for passing down the timeout in 4.0.0, so that both the server and the client are able to parse the frames with and without them, but delay implementation of the server side logic necessary for terminating requests early until a further

Re: [VOTE] Release Apache Cassandra 4.0-alpha4

+1 > On 11 Apr 2020, at 00:02, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0-alpha4 for release. > > sha1: d00c004cc10986fc41c2070f9c5d0007e03a45c3 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha4-tentative > Maven

Re: Simplify voting rules for in-jvm-dtest-api releases

+1 > On 15 Apr 2020, at 14:35, Oleksandr Petrov wrote: > > Hi everyone, > > Apache release rules were made for first-class projects. I would like to > propose simplifying voting rules for in-jvm-dtest-api project [1]. > > A bit of background: in-jvm-dtest-api is a project that is used by all

Re: server side describe

Yeah, I feel like it’s a bad example to use to highlight 4.0 scope creep (which is less of a thing than some fear). The work there is already done, and it’s extremely unintrusive. There is no reason whatsoever to block 4.0 on it, but no reason not to commit - now, in a beta, in the first RC,

Re: Discussion: addition to CEP guide

+1 > On 23 Apr 2020, at 12:58, Benjamin Lerer wrote: > > +1 for both > > > > On Thu, Apr 23, 2020 at 3:49 AM Jordan West wrote: > >> +1 (nb) on both counts. Thanks for bringing this up! >> >> Jordan >> >> On Wed, Apr 22, 2020 at 11:53 AM Joshua McKenzie >> wrote: >> Maybe

Re: Calling for release managers (Committers and PMC)

Please add me as well. > On 12 May 2020, at 09:51, Sam Tunnicliffe wrote: > > Me too. > >> On 11 May 2020, at 20:23, Jake Luciani wrote: >> >> Happy to lend a hand >> >> On Mon, May 11, 2020 at 3:12 PM Eric Evans >> wrote: >> >>> I can take a turn. >>> >>> On Fri, May 8, 2020 at 11:10 AM

Re: [DISCUSS] Change style guide to recommend use of @Override

+1. Some of us have already adopted this change some time ago, but it’d be nice to make it official for everybody. > On 1 Sep 2020, at 19:27, David Capwell wrote: > > Currently our style guide recommends to avoid using @Override and updates > intellij's code style to exclude it by default; I

Re: Problem in updating schema in Cassandra 3.11.4

I’m reasonably certain that this is one of the things that I fixed in 4.0. It’d be too invasive a change for 3.11, unfortunately. > On 1 Sep 2020, at 16:52, Benjamin Lerer wrote: > > Hi, > > Could you precise what you mean by " will only validate the schema while > changing in memory, and

Re: naming development branches consistently

Last thing I want is to bikeshed, but seems like ‘main’ is what’s being adopted by GitHub, so we might as well rename all ‘master’ and ’trunk’ branches to that. > On 24 Aug 2020, at 17:22, Joshua McKenzie wrote: > > Ah! Totally didn't even think of that. Good point. > > On Mon, Aug 24, 2020

Re: [VOTE] Accept the Harry donation

+1 > On 16 Sep 2020, at 16:09, Sumanth Pasupuleti > wrote: > > +1 (non-binding) > > On Wed, Sep 16, 2020 at 7:41 AM Jon Meredith wrote: > >> +1 (non-binding) >> >> On Wed, Sep 16, 2020 at 8:28 AM David Capwell >> wrote: >>> >>> +1 >>> >>> Sent from my iPhone >>> On Sep 16, 2020,

Re: [Vote] Remove Windows support from 4.0+

+1 > On 10 Aug 2020, at 04:14, Yuki Morishita wrote: > > As per the discussion(*), I propose to remove Windows support from 4.0 > release and onward. > > Windows scripts are not maintained and we lack windows test > environments. WIndows users can use docker or cloud environments to > set up

Re: [VOTE] Project governance wiki doc (take 2)

+1 > On 20 Jun 2020, at 16:12, Joshua McKenzie wrote: > > Link to doc: > https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance > > Change since previous cancelled vote: > "A simple majority of this electorate becomes the low-watermark for votes > in favour

Re: [VOTE] Release Apache Cassandra 3.0.21

+1 > On 14 Jul 2020, at 23:49, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.0.21 for release. > > sha1: e39d1da325f5853ab3a64d92ecf52f8271239b9e > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.21-tentative > Maven Artifacts: >

Re: [DISCUSS] Limitting the 4.0 GA scope

I believe we wouldn’t knowingly ship a release with [CASSANDRA-16619 > Loss of commit log data possible after sstable ingest] in it, so I’d say at least that one needs to be fixed, even

Re: [VOTE] Release Apache Cassandra 3.0.24

+1 > On 29 Jan 2021, at 14:31, Ekaterina Dimitrova wrote: > > +1(nb) > > On Fri, 29 Jan 2021 at 8:21, Oleksandr Petrov > wrote: > >>> Proposing the test build of Cassandra 4.0-beta4 for release. >> >> Correction: test build of 3.0.24. The rest looks right. >> >> On Fri, Jan 29, 2021 at

Re: [VOTE] Release Apache Cassandra 4.0-rc1

+1 > On 29 Mar 2021, at 14:05, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0-rc1 for release. > > sha1: 2facbc97ea215faef1735d9a3d5697162f61bc8c > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative > Maven Artifacts: >

Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

+1 > On 23 Apr 2021, at 08:51, Sam Tunnicliffe wrote: > > +1 > >> On 23 Apr 2021, at 04:19, Jasonstack Zhao Yang >> wrote: >> >> +1 >> >> On Fri, 23 Apr 2021 at 08:16, Nate McCall wrote: >> >>> +1 >>> >>> >>> On Thu, Apr 22, 2021 at 6:59 AM Mick Semb Wever wrote: >>> Proposing

Re: [VOTE] Release Apache Cassandra 4.0.0

-1 from me unfortunately because of https://issues.apache.org/jira/browse/CASSANDRA-16797 being legit (but also beyond trivial to fix). > On 13 Jul 2021, at 12:49, bened...@apache.org wrote: > > Do we support aarch64? If we don’t we

Re: [DISCUSS] Vector type and empty value

Allowing zero-length byte arrays for most old types is just a legacy from Darker Days. It’s a distinct concern from columns being nullable or not. There are a couple types where this makes sense: strings and blobs. All else should not allow this except for backward compatibility reasons. So,

Re: [VOTE] Accept java-driver

+1 > On 5 Oct 2023, at 10:35, Benedict wrote: > > Surely it needs to be shared with the foundation and the PMC so we can > verify? Or at least have ASF legal confirm they have received and are > satisfied with the tarball? It certainly can’t be kept private to DS, AFAICT. > > Of course it

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

I’m not so sure that many folks will choose to go 4.0->5.0->5.1 path instead of just waiting longer for TCM+Accord to be in, and go 4.0->5.1 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

Re: [DISCUSS] Adding dependency on agrona

Almost added it twice myself. High quality library with many nifty classes, +1 from me. > On 21 Sep 2022, at 13:28, Branimir Lambov wrote: > > Hi everyone, > > CASSANDRA-17240 (Trie memtable implementation) introduces a dependency on the > agrona library

Re: Shall 4.2 become 5.0 ?

Don’t have an opinion on designating 4.2 as 5.0 instead, though it might be a nice idea for marketing reasons, if enough splashy features make it into it. If or when we go with 5.0 however, we don’t have to drop any compatibility with older versions just because our SemVer rules technically

Re: [VOTE] Revising release gating criteria and CI systems

Sure, +1 > On 11 Oct 2022, at 13:15, Andrés de la Peña wrote: > > +1 > > On Tue, 11 Oct 2022 at 11:57, Brandon Williams > wrote: > +1 > > On Sat, Oct 8, 2022 at 7:30 AM Josh McKenzie > wrote: > > > > DISCUSS thread: > >

Re: [VOTE] Release Apache Cassandra 4.1-beta1

+1 > On 3 Oct 2022, at 06:27, Berenguer Blasi wrote: > > +1 > > On 30/9/22 16:20, Brandon Williams wrote: >> I'm +1 under these conditions as well. >> >> Kind Regards, >> Brandon >> >> On Thu, Sep 29, 2022 at 3:34 PM Mick Semb Wever wrote: The vote will be open for 72 hours

Re: dtests to reproduce the schema disagreement

The absolute easiest way would be to down one of the two nodes first, run CREATE TABLE on the live node, shut it down, get the other one up, and run the same CREATE TABLE there, the bring up the down node. > On 9 Aug 2022, at 07:48, Konstantin Osipov via dev > wrote: > > * Cheng Wang via dev

Re: Should we change 4.1 to G1 and offheap_objects ?

Switching a major default in a minor release is way worse than doing it in a GA - less notice and visibility, many folks don’t even read minor version NEWS.txt before upgrading. Trunk is fine by me though. > On 12 Jan 2023, at 13:14, Mick Semb Wever wrote: > >> Ok, wrt G1 default, this is

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

Public APIs are 1) essentially forever-lasting and 2) are what our users actually get to interact with. A suboptimal public API can be annoying to work with at best, and at worst force and cement suboptimal implementations. The goal here is to make sure that whatever public API changes we

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

v1. We >>>> see way more contention on v2 for a LOCAL_SERIALIZABLE workload that >>>> writes/reads to only 100 >>>> partitions (v2 performs better for higher partition counts). We're still >>>> investigating what's going >>>> on. >>&

Re: [DISCUSS] API modifications and when to raise a thread on the dev ML

ce > a process that has a high cost in terms of time and effort for small changes. > So far nobody has been able to provide me with examples of times where it > would have been needed. I am sorry. I see the cost not the benefit. > > > Le mar. 6 déc. 2022 à 16:18, Aleksey Yeshc

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Sure. > On 6 Dec 2022, at 18:14, Mick Semb Wever wrote: > >> Let’s get these fixes in and roll a pure RC2. > > > > Given that we're talking about two one-liners, just changing time units, what > are folks thoughts about skipping rc2 and just re-cutting 4.1.0 (GA) ? > > (I agree with the

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

+1 > On 5 Dec 2022, at 10:17, Benjamin Lerer wrote: > > +1 > > Le lun. 5 déc. 2022 à 11:02, Berenguer Blasi > a écrit : >> +1 >> >> On 5/12/22 10:53, guo Maxwell wrote: >>> +1 >>> >>> Mick Semb Wever mailto:m...@apache.org>>于2022年12月5日 >>> 周一下午5:33写道：

Re: [VOTE] CEP-25: Trie-indexed SSTable format

+1 > On 19 Dec 2022, at 13:42, Ekaterina Dimitrova wrote: > > +1 > > On Mon, 19 Dec 2022 at 8:30, J. D. Jordan > wrote: >> +1 nb >> >> > On Dec 19, 2022, at 7:07 AM, Brandon Williams > > > wrote: >> > >> > +1 >> > >> > Kind

Re: Issue when creating a stream session

Indeed, it is safe to clean up now. Normally we prefer to do cleanups like that on trunk only, but I’d say feel free to remove this dead code in 4.0+ if that’s the branch you are targeting in CASSANDRA-17199. > On 19 Dec 2022, at 03:53, Yuki Morishita wrote: > > I dug the git history and it

Re: [VOTE] Release Apache Cassandra 4.1-rc1

+1 > On 18 Nov 2022, at 12:10, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.1-rc1 for release. > > sha1: d6822c45ae3d476bc2ff674cedf7d4107b8ca2d0 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1-rc1-tentative > Maven Artifacts: >

Re: Should we change 4.1 to G1 and offheap_objects ?

All right. I’ll clarify then. -0 on switching the default to G1 *this late* just before RC1. -1 on switching the default offheap_objects *for 4.1 RC1*, but all for it in principle, for 4.2, after we run some more test and resolve the concerns raised by Jeff. Let’s please try to avoid this kind

Re: Merging CEP-15 to trunk

hat the reviews that have > already happened in the feature branch are sufficient and there isn't a need > for a new full blown review. > > As far as I can tell, this email thread is exactly that process and I imagine > was at least one of the reasons to send this heads up ema

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

Re: Should we change 4.1 to G1 and offheap_objects ?

I assume not with 4.0/4.1 though. It might be a better default than CMS, but switching a major default like this (an memtable allocation) is not something that should be snuck in at the very last moment. In case of GC, reasonably extensive performance testing should be the expectations.

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

> Saying that there is never any complexity and we should keep formats in > perpetuity, and I'm sitting here having a heart attack, srsly. Nobody is claiming that. Don’t let a straw man give you a heart attack. > Though I _always_ recommend users upgrade all sstables, before and after > every

Re: [VOTE] Release Apache Cassandra 4.1.1

+1 > On 17 Mar 2023, at 13:54, Mick Semb Wever 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 at least three binding +1s and no -1's. > > >

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

Raising messaging service minimum, I have a less strong opinion on, but on dropping m* sstable code I’m strongly -1. 1. This is code on a rarely touched path 2. It’s very stable and battle tested at this point 3. Removing it doesn’t reduce much complexity at all, just a few branches are

Re: Should we cut some new releases?

+1 > On 14 Mar 2023, at 05:50, Berenguer Blasi wrote: > > +1 > > On 13/3/23 21:25, Jacek Lewandowski wrote: >> +1 >> >> pon., 13 mar 2023, 20:36 użytkownik Miklosovic, Stefan >> mailto:stefan.mikloso...@netapp.com>> napisał: >>> Yes, I was waiting for CASSANDRA-18125 to be in. >>> >>> I can

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

I’m not sure we have an explicit rule at the moment. Would probably based on calendar time in addition to release versions if we had one. Addressing these on case by case basis for now is fine IMO. I’d say the general principle should be treat extended compatibility (between releases in

  1   2   >