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

+1 > On 5 May 2025, at 23:24, Blake Eggleston wrote: > > As mutation tracking relates to existing backup systems that account for > repaired vs unrepaired sstables, mutation tracking will continue to promote > sstables to repaired once we know they contain data that has been fully > reconcile

Re: [VOTE] Simplifying our release versioning process

+1 > On 22 Apr 2025, at 10:33, Sylvain Lebresne wrote: > > +1 > -- > Sylvain > > > On Tue, Apr 22, 2025 at 10:47 AM Maxim Muzafarov > wrote: >> Also +1 >> >> On Tue, 22 Apr 2025 at 07:57, guo Maxwell > > wrote: >> >> >> >> We have alread

Re: [VOTE] CEP-45: Mutation Tracking

+1 > On 4 Feb 2025, at 21:39, Bernardo Botella > wrote: > > +1 (nb) > >> On Feb 4, 2025, at 12:34 PM, Dinesh Joshi wrote: >> >> +1 >> >> On Mon, Feb 3, 2025 at 10:35 AM Blake Eggleston > > wrote: >>> Hi dev@, >>> >>> I’d like to start the voting for CEP-45: Mut

Re: Checkstyle as style contract for Cassandra

> I’m not letting anyone near my carefully crafted code with an automated > formatter. Ha. Same. Let’s not get carried away. The main problem here seems to be overzealous code reviewers, and this can be solved with better reviewer onboarding / guide. The minor formatting nits can and should be

Re: Capabilities

out being disrupted. > On 6 Jan 2025, at 16:54, Aleksey Yeshchenko wrote: > > I agree that this would be useful, yes. > > An LWT/Accord variant plus a plain writes eventually consistent variant. A > generic-by-design internal-only per-table mechanism with optional caching + >

Re: Capabilities

d have that be a generic system that is designed for >> everyone to use. Then we have a gossip replacement, reduce config clutter, >> and people have something that can be used without adding another bespoke >> system into the mix. >> >> Jon >> >> On Mon, J

Re: Capabilities

TCM was designed with a couple of very specific correctness-critical use cases in mind, not as a generic mechanism for everyone to extend. It might be *convenient* to employ TCM for some other features, which makes it tempting to abuse TCM for an unintended purpose, but we shouldn’t do what's c

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

it'd be pretty implicitly > clear to people they shouldn't use it in production right? > > It seems to me that the 3 categories would be sufficient even to handle our > current scenario where we have some things in the system that are a Bad Idea > to use in productio

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

be tried by end users but has caveats and most likely >>> >> is not api stable. >>> >> Beta - Feature complete/API stable but has not had enough testing to be >>> >> considered rock solid. >>> >> GA - Ready for use, no known issue, PMC is satisfi

Re: [DISCUSS] 5.1 should be 6.0

We don’t really practice canonic sermver, we never really have, and it’s impossible to properly follow anyway. Should be perfectly fine to bump to 6.0, so long as we don’t take the bump as a license to break compatibility in a way that we wouldn’t have for 5.1. > On 11 Dec 2024, at 00:11, Jon

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

There is room for a few different grades of ‘flawed’. From broken (you should really not use this anymore) to “generally usable but be careful and aware of these caveats” - with different degrees of gating/warning applied. > On 10 Dec 2024, at 11:46, Aleksey Yeshchenko wrote: > > W

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

What we’ve done is we’ve overloaded the term ‘experimental’ to mean too many related but different ideas. We need additional, more specific terminology to disambiguate. 1. Labelling released features that were known to be unstable at release as ‘experimental’ retroactively shouldn’t happen and

Re: Markdown JavaDoc

It won’t work *properly* with current versions but the tooling should still handle it gracefully without blowing up. It just won’t generate the full docs. But arguably we don’t really care about that much - as other have mentioned, C* javadoc comments are mainly consumed from inside IDEs. So mi

Re: [DISCUSS] Usage of "var" instead of types in the code

Allow in tests, forbid elsewhere for now would be my vote. > On 30 Oct 2024, at 11:45, Štefan Miklošovič wrote: > > against vars: > > Benjamin > Stefan > Benedict > Yifan > > somewhere in the middle: > > Dinesh > > Caleb +1 in tests and +0 in prod code. > David - against flat out banning, li

Re: [DISCUSS] The way we log

I reckon we could start using slf4j/logback Markers to tag individual logging statements as foreground/background (or, ideally, with more granularity than that - separate out repair, compaction, schema, reads/wrties, etc.). > On 24 Jul 2024, at 16:02, Josh McKenzie wrote: > > I argued this poi

Re: [DISCUSS] Replace airlift/airline library with Picocli

uld be willing >> to assist in this effort) or get picocli under the ASF umbrella, assuming >> that Remko wants to do either of these things. >> >> I believe that subcommands would be a welcome addition to commons-cli. An >> annotation processor likewise may also be welco

Re: [DISCUSS] Replace airlift/airline library with Picocli

Hi Maxim, I think I’m not fully sold on the need to do anything at all here. The library may no longer be maintained, but so what if it isn’t, really? Parsing command line arguments is a pretty well defined problem, it’s not the kind of code that rots and needs to be updated to stay operational

Re: [VOTE] Release Apache Cassandra 5.0-rc1

Not voting on this, however, if we expect to fix something specific between an RC and GA, then we shouldn’t be starting a vote on RC. In that case it should be another beta. > On 27 Jun 2024, at 18:30, Brandon Williams wrote: > > The last time paxos v2 blocked us in CASSANDRA-19617 which also

Re: [VOTE][IP CLEARANCE] GoCQL driver

+1 > On 26 Jun 2024, at 07:38, Ekaterina Dimitrova wrote: > > +1 > > On Wed, 26 Jun 2024 at 6:14, Jon Haddad > wrote: >> +1. >> >> On Wed, Jun 26, 2024 at 1:50 AM J. D. Jordan > > wrote: >>> +1 nb. Good to see this heavily used dr

Re: [DISCUSS] Stream Pipelines on hot paths

It am okay with its use off hot paths in principle, and I’ve done it myself. But as others have mentioned, it’s not obvious to every contributor what is and isn’t a hot path. Also, the codebase is a living, shifting thing: a cold path today can suddenly become hot tomorrow - it’s not uncommon.

Re: [DISCUSS] Stream Pipelines on hot paths

Ban in all new non-test code seems like the most pragmatic approach to me as well. > On 7 Jun 2024, at 06:32, Jordan West wrote: > > Similarly in the "don't use them in the main project but am ok with tests" > camp > > On Thu, Jun 6, 2024 at 4:46 AM Štefan Miklošovič

Re: [DISCUSS] Harry in-tree

+1 > On 29 Nov 2023, at 07:23, Marcus Eriksson wrote: > > +1! > > /Marcus > > On Fri, Nov 24, 2023 at 04:43:36PM +0100, Alex Petrov wrote: >> Hi everyone, >> >> With TCM landed, there will be way more Harry tests in-tree: we are using it >> for many coordination tests, and there's now a simu

Re: [VOTE] Release Harry 0.0.2

+1 > On 29 Nov 2023, at 11:35, Sam Tunnicliffe wrote: > > +1 > >> On 29 Nov 2023, at 11:14, Alex Petrov wrote: >> >> Even though we would like to bring harry in-tree, this is not an immediate >> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no >> custom jars. We

Re: [VOTE] Release Apache Cassandra 5.0-beta1

-1 on cutting a beta1 in this state. An alpha2 would be acceptable now, but I’m not sure there is significant value to be had from it. Merge the fixes for outstanding issues listed above, then cut beta1. With TCM and Accord pushed into 5.1, SAI is the headliner user-visible feature. It is what

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 a

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 sho

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

Re: Changing the output of tooling between majors

As Eric said, a major release is not a license to make externally visible breaking changes. We are too mature a project now. I have OCD tendencies like many people here, but one must learn to live with aesthetically imperfect tool output. Internal changes are fine, external changes that are act

Re: Improved DeletionTime serialization to reduce disk size

Distant future people will not be happy about this, I can already tell you now. Sounds like a reasonable improvement to me however. > On 23 Jun 2023, at 07:22, Berenguer Blasi wrote: > > Hi all, > > DeletionTime.markedForDeleteAt is a long useconds since Unix Epoch. But I > noticed that with

Re: [DISCUSSIONS] Replace ant eclipse-warnings with CheckerFramework

Sounds like a clear improvement to me. Only once this check flagged a legitimate issue I missed, if I’m remembering correctly. All other instances have just been annoyances, forcing to add a redundant suppressed annotation. > On 15 Jun 2023, at 19:01, Ekaterina Dimitrova wrote: > > Hi everyon

Re: [VOTE] CEP-8 Datastax Drivers Donation

+1 > On 15 Jun 2023, at 15:19, Chris Lohfink wrote: > > +1 > > On Wed, Jun 14, 2023 at 9:05 PM Jon Haddad > wrote: >> +1 >> >> On 2023/06/13 14:14:35 Jeremy Hanna wrote: >> > Calling for a vote on CEP-8 [1]. >> > >> > To clarify the intent, as Benjamin said

Re: [VOTE] CEP-30 ANN Vector Search

+1 > On 26 May 2023, at 07:19, Berenguer Blasi wrote: > > +1 > > On 26/5/23 6:07, guo Maxwell wrote: >> +1 >> >> Dinesh Joshi mailto:djo...@apache.org>>于2023年5月26日 >> 周五上午11:08写道： >>> +1 >>> On May 25, 2023, at 8:45 AM, Jonathan Ellis >>> > wrote: >

Re: Agrona vs fastutil and fastutil-concurrent-wrapper

This ^ It’s an absolutely beautifully written library by Martin Thompson, my go-to for years if I’m ever asked for an example of a Java codebase to study. I have read it essentially entirely, and more than once, and it makes me feel a little happier but also inadequate every time I do. It does

Re: [DISCUSS] The future of CREATE INDEX

This. I would also consider adding CREATE LEGACY INDEX syntax as an alias for today’s CREATE INDEX, the latter to be deprecated and (in very distant future) removed. > On 12 May 2023, at 13:14, Benedict wrote: > > This creates huge headaches for everyone successfully using 2i today though, >

Re: [VOTE] Release Apache Cassandra 3.0.29

+1 > On 8 May 2023, at 09:44, Miklosovic, Stefan > wrote: > > Proposing the test build of Cassandra 3.0.29 for release. > > sha1: 087cffce636b63c12e328994d52bdf8f4ccc9750 > Git: https://github.com/apache/cassandra/tree/3.0.29-tentative > Maven Artifacts: > https://repository.apache.org/conten

Re: [VOTE] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

+1 > On 4 May 2023, at 17:46, Doug Rohrer wrote: > > Hello all, > > I’d like to put CEP-28 to a vote. > > Proposal: > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics > > Jira: > https://issues.apache.org/jira/brow

Re: [VOTE] Release Apache Cassandra 3.11.15

+1 > On 2 May 2023, at 07:37, Miklosovic, Stefan > wrote: > > Proposing the test build of Cassandra 3.11.15 for release. > > sha1: 6cdcf5e56a77cf40c251125d68856a614eccbc53 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.15-tentative > Maven Artifacts:

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

Dig deeper :) It’s existed since day one in both CQL2 and CQL3. https://github.com/apache/cassandra/blob/cassandra-1.0/src/java/org/apache/cassandra/cql/Cql.g#L526-L527 > On 10 Apr 2023, at 00:35, Patrick McFadin wrote: > > I was trying to remember when SCHEMA got added to the CQL parser. With

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

FYI we support SCHEMA as an alias to KEYSPACE today (have since always). Can use CREATE SCHEMA in place of CREATE KEYSPACE, etc. > On 4 Apr 2023, at 19:23, Henrik Ingo wrote: > > I find the Postgres terminology overly complex. Where most SQL databases will > have several *databases*, each con

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

+1 > On 4 Apr 2023, at 16:56, Ekaterina Dimitrova wrote: > > +1 > > On Tue, 4 Apr 2023 at 11:44, Benjamin Lerer > wrote: >> +1 >> >> Le mar. 4 avr. 2023 à 17:17, Andrés de la Peña > > a écrit : >>> +1 >>> >>> On Tue, 4 Apr 2023 at 15:09,

Re: CASSANDRA-18247 committed

Hurray! Great work, thanks for making it happen. — AY > On 20 Mar 2023, at 17:19, Ekaterina Dimitrova wrote: > > Hi everyone, > > Happy Monday! > > CASSANDRA-18247 was just committed. It adds testing CircleCI configuration > for JDK11+JDK17. Full description and how to use it can be found i

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)

> 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: [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 general

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)

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 affected

Re: [DISCUSS] Next release date

Don’t need to revert it so long as the feature they are for is not enabled by default. Or, if it’s a bit away from being useful enough to even test - mad hard-disabled without a way to enable. > On 1 Mar 2023, at 16:34, Henrik Ingo wrote: > > already merged 3 patches, but still has 2 to go? Ca

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

ssing the > volatile keyword. > > Le mer. 22 févr. 2023 à 11:36, Aleksey Yeshchenko <mailto:alek...@apple.com>> a écrit : >> FWIW most of those volatile fields, if not in fact all of them, should NOT >> be volatile at all. Someone started the trend and most folks

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

FWIW most of those volatile fields, if not in fact all of them, should NOT be volatile at all. Someone started the trend and most folks have been copycatting or doing the same for consistency with the rest of the codebase. Please definitely don’t rely on that. > On 21 Feb 2023, at 21:06, Maxim

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 > On 6 Feb 2023, at 17:24, Benedict wrote: > > +1 > >> On 6 Feb 2023, at 16:17, Brandon Williams wrote: >> >>  >> +1 >> >> On Mon, Feb 6, 2023, 10:15 AM Sam Tunnicliffe > > wrote: >>> Hi everyone, >>> >>> I would like to start a vote on this CEP. >>> >>> Proposa

Re: Implicitly enabling ALLOW FILTERING on virtual tables

Just make virtual table implementations decide? Add a method to VirtualTable interface to indicate if this is desirable, and call it a day? > On 6 Feb 2023, at 09:41, Benjamin Lerer wrote: > > Making ALLOW FILTERING a table option implies giving the right to the person > creating the table t

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

Bringing light to new proposed APIs no less important - if not more, for reasons already mentioned in this thread. For it’s not easy to change them later. Voting B. > On 2 Feb 2023, at 10:15, Andrés de la Peña wrote: > > If it's a breaking change, like removing a method or property, I think w

Re: Merging CEP-15 to trunk

ree that 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 he

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 ?

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 won

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 l

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 Regards

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 rul

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

> 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: [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 introd

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

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

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] 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: > ht

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: 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. Potent

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: > > https://lists.apa

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

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 allo

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 (https://github.com/real-logic/agrona

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: [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 shou

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 th

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

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 1:48

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

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 wo

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 will

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 at

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 C

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

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 ne

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

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: [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 Artifacts:

Re: Keeping test-only changes out of CHANGES.txt

+1 > On 8 Apr 2020, at 15:08, Mick Semb Wever wrote: > > Can we agree on keeping such test changes out of CHANGES.txt ? > > We already don't put entries into CHANGES.txt if it is not a change > from any previous release. > > There was some discussion before¹ about this, and the problem that >

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

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 m

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

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

The person introducing flakiness to a test will almost always have run it locally and on CI first with success. It’s usually later when they first start failing, and it’s often tricky to attribute to a particular commit/person. So long as we have these - and we’ve had flaky tests for as long as

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 I

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: > https://repo

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: > https://repo

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: > https://repo

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

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 i

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 final

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

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

  1   2   >