Re: [DISCUSS] CEP-48: First-Class Materialized View Support

ized views, since the source > of truth (the base table) still holds the correct data. > > On Mon, Jun 23, 2025 at 12:05 PM Blake Eggleston wrote: >> __ >> > Sorry, Blake—I was traveling last week and couldn’t reply to your email >> > sooner. >> >> No

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

reas normal > anti-entropy repair needs to run regularly. This means we shouldn’t treat MV > repair the same way as existing repairs. When an operator initiates MV > repair, they need to ensure that sufficient resources are available to > support it. > > > On Thu, Jun 12, 2025 a

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

>> mutation as part of the repair process, it’s unclear whether there could be >> edge cases we’re missing. This approach may risk unexpected side effects if >> the repair logic is not carefully aligned with write path semantics. >> >> >> On Thu, Jun 12, 20

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

nimize impact there, > the original proposal was to rebuild the affected ranges using > anti-compaction, just to be safe. > > > On Wed, Jun 11, 2025 at 1:20 AM Blake Eggleston wrote: >> __ >>> Extra row in MV (assuming the tombstone is gone in the base table) — how &

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> have higher timestamps? > > Do we need to introduce a new kind of tombstone to shadow the rows in the MV > for cases 2 and 3? If yes, how will this tombstone work? If no, how should we > fix the MV data? > > > On Mon, Jun 9, 2025 at 11:00 AM Blake Eggleston wrote: >&

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

t, but with CEP-37, we should be able to handle this > coordination without adding too much burden on the operator side. > > > On Sat, Jun 7, 2025 at 8:28 AM Blake Eggleston wrote: >> __ >>> I don't see any outcome here that is good for the community though.

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

'll be noping out for a while, as I don't see much value here > right now. > > > On 2025/06/06 18:31:08 Blake Eggleston wrote: > > Hi Benedict, that’s actually not true. > > > > Here’s a link to the project governance page: > > _https://cwiki.apache.org/co

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

or incremental repairs which must run regularly. > > > > On Fri, Jun 6, 2025 at 4:32 PM Benedict Elliott Smith > wrote: >> > but the snapshot repair design is not a viable path forward. It’s the >> > first iteration of a repair design. We’ve proposed a second iter

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

rocess has no vetoes, so you are not empowered to declare > that a design is not viable without the input of the wider community. > > > On 2025/06/05 03:58:59 Blake Eggleston wrote: > > You can detect and fix the mismatch in a single round of repair, but the > > amoun

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

; Then you send that data over to the view, the view does it's anti-compaction >> thing, again, once per affected range. So now the view has to do an >> anti-compaction once per block on the board that's affected by the missing >> data. >> >> Doing hundr

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> Adds overhead in the hot path due to maintaining indexes. Extra memory needed > during write path and compaction. I’d make the same argument about the overhead of maintaining the index that Jon just made about the disk space required. The relatively predictable overhead of maintaining the ind

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

: > In the case of bitrot / losing an SSTable, wouldn't a normal repair (just the > MV against the other nodes) resolve the issue? > > On Wed, May 14, 2025 at 11:27 AM Blake Eggleston wrote: >> __ >> Mutation tracking is definitely an approach you could take for MVs. Muta

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Mutation tracking is definitely an approach you could take for MVs. Mutation reconciliation could be extended to ensure all changes have been replicated to the views. When a base table received a mutation w/ an id it would generate a view update. If you block marking a given mutation id as recon

Re: Welcome Abe Ratnofsky as Cassandra committer!

congrats Abe! On Mon, May 12, 2025, at 10:36 AM, Alexandre DUTRA wrote: > Congrats Abe! > > Le lun. 12 mai 2025 à 14:26, Francisco Guerrero a écrit : >> Congrats Abe! >> >> On 2025/05/12 16:45:22 Alex Petrov wrote: >> > Hello folks of the dev list, >> > >> > The Apache Cassandra PMC is very gl

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

+1 On Mon, May 12, 2025, at 7:27 AM, Ariel Weisberg wrote: > Hi dev@, > > I would like to start the voting for CEP-46: Finish Transient > Replication/Witnesses > > Proposal: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=353601959 > Discussion: https://lists.apache.org/thre

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

s that can't be touched. It never made sense to me to try to > bundle new features / bug fixes with improvements to code quality. > > Making the code more reliable should be a goal in itself, rather than a side > effect of other work. > > Jon > > > >

Re: Cassandra 5+ JDK Minimum Compatibility Requirement

This seems like a cool feature that will be useful in future development work, but not something we should be proactively refactoring the project to make use of. On Fri, May 9, 2025, at 10:18 AM, Vivekanand Koya wrote: > I would say that https://openjdk.org/jeps/394 (instanceOf) aims to provide

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> Yes, you need to read the original row before the transaction begins in order > to get the initial state, but could be done at local one by the coordinator, > reading itself. The performance overhead of an additional, local one read > should be significantly less than a Paxos transaction that

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

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 reconciled. The main difference is that they won’t be promoted as part of a

Re: March 2025 project status update

Technically March, but Abe Ratnofsky was also added as a committer. Looks like the announcement for that was missed On Fri, Mar 7, 2025, at 10:45 AM, Josh McKenzie wrote: > Did you know I sometimes fail at email filtering? > > 4 new committers! FOUR. Welcome to Bernardo Botella Corbi as well! >

Re: [VOTE][IP CLEARANCE] Cassandra Cluster Manager (CCM)

+1 On Sun, Mar 9, 2025, at 5:17 AM, Mick Semb Wever wrote: > Please vote on the acceptance of the Cassandra Cluster Manager (CCM) > and its IP Clearance: > https://incubator.apache.org/ip-clearance/cassandra-ccm.html > > All consent from original authors of the donation, and tracking of > collect

Re: March 2025 project status update

ahem, sorry looks like we're still waiting on something from Abe on that one. Nevermind for now :) On Fri, Mar 7, 2025, at 1:05 PM, Blake Eggleston wrote: > Technically March, but Abe Ratnofsky was also added as a committer. Looks > like the announcement for that was missed > &

Re: CEP-15 Update

perations PaxosV2 supports” or “performs as well or >>> better than PaxosV2 on [workload(s)]”? >>> >>> I understand waiting asks a lot of the authors in terms of baring the >>> burden of a more complex merge. But I think we also need to consider what >

Re: CEP-15 Update

at 18:15, Jon Haddad wrote: > >> > >> > > >> > >> > Very exciting! > >> > >> > > >> > >> > I have a client that's very interested in Accord, so I should have > >> > budget to dig into it, espec

Re: CEP-15 Update

orting ByteOrderPartitioner, and live migration > from/to Paxos is undergoing fine-tuning and validation; probably there are > some other things I am forgetting. > > Altogether the feature is fairly mature, despite these caveats. This is the > fruit of the labour of a long list

Re: [VOTE] CEP-45: Mutation Tracking

t 8:15 PM C. Scott Andreas > > >>> wrote: > > >>> > > >>> +1 > > >>> > > >>>> On Feb 5, 2025, at 2:50 PM, Alex Petrov wrote: > > >>> > > >>> > > >>> +1 > > >>> > >

Re: [VOTE] CEP-45: Mutation Tracking

Ok ok, I've jumped gun here, sorry, small off by 24 error. Please continue voting, and I'll be back tomorrow :D On Wed, Feb 5, 2025, at 1:49 PM, Blake Eggleston wrote: > The vote passes with 10 +1s (4 nb) and no -1. > > Thanks everyone! > > Blake > > On We

Re: [VOTE] CEP-45: Mutation Tracking

The vote passes with 10 +1s (4 nb) and no -1. Thanks everyone! Blake On Wed, Feb 5, 2025, at 1:07 PM, Jon Meredith wrote: > +1 (nb) > > On Tue, Feb 4, 2025 at 5:07 PM guo Maxwell wrote: >> +1 >> Dmitry Konstantinov 于2025年2月5日 周三上午6:04写道： >>> +1 (nb) >>> >>> On Tue, 4 Feb 2025 at 22:00, Abe Ra

[VOTE] CEP-45: Mutation Tracking

are at least 3 binding +1s and no binding vetoes. Thanks, Blake Eggleston

Re: [DISCUSS] CEP-45: Mutation Tracking

Hi dev@, Looks like it's been about 10 days since the last message here. Are there any other comments before I put it up for a vote? Thanks, Blake > On Jan 18, 2025, at 12:33 PM, Blake Eggleston wrote: > > That's an interesting idea. Basically allow for a window of unc

Re: [DISCUSS] Snapshots outside of Cassandra data directory

Somewhat tangential, but I’d like to see Cassandra provide a backup story that doesn’t involve making copies of sstables. They’re constantly rewritten by compaction, and intelligent backup systems often need to be able to read sstable metadata to optimize storage usage. An interface purpose bui

Re: [DISCUSS] Bracing style on trunk

gt; > > > > On Sat, Jan 18, 2025 at 12:32 PM Ekaterina Dimitrova <mailto:e.dimitr...@gmail.com>> wrote: >> I also do not see huge benefit in switching the style, honestly. And I see >> risks more than benefits. >> >> I also share Blake’s opinion that this wou

Re: Checkstyle as style contract for Cassandra

Let’s also keep in mind that this is a discussion about the pros and cons of automatic formatting. Everyone wants what’s best for the project, although they may have different views about how to get there. One person thinking we should use a tool does not make them lazy, nor does it affect the

Re: [DISCUSS] CEP-45: Mutation Tracking

t mutation id to a table every few >> seconds asynchronously > > For accord we will write reservation records in advance so we can guarantee > we don’t go backwards. That is, we will periodically declare a point eg 10s > in the future that on restart we will have to first let

Re: [DISCUSS] Bracing style on trunk

I lean pretty strongly towards -1 on this. If we were starting a new project, then yeah it would make sense. As an older project though, I don’t see any clear benefits for switching the style at this point, and can foresee it causing a lot of pain. Even if we were to wait for accord before going

Re: [DISCUSS] CEP-45: Mutation Tracking

o on restart. I’m sure this work can use the same feature, though I agree > with Blake it’s likely an unrealistic case in anything but adversarial test > scenarios. > >> On 17 Jan 2025, at 22:52, Blake Eggleston wrote: >> >>  >> Hi Jon, thanks for the excellent ques

Re: [DISCUSS] CEP-45: Mutation Tracking

#x27;m missing something. > > Bootstrap/topology changes - what about RF changes. I don't think TCM > currently handles that. Would it need to be added to make mutation tracking > work? Where would the metadata be stored to indicate preferred sources for > missing mutations? Would

Re: [DISCUSS] CEP-45: Mutation Tracking

self from peers >> proactively using the seekable commitlog. >> >> Can you explain the reason you prefer to reconcile on read? Having a >> consistent commitlog would solve so many problems like CDC, PITR, MVs >> etc. >> >> Jake >> >> On Thu, Ja

Re: [DISCUSS] CEP-45: Mutation Tracking

stent commitlog would solve so many problems like CDC, PITR, MVs > etc. > > Jake > > On Thu, Jan 16, 2025 at 12:13 PM Blake Eggleston wrote: >> >> I’ve been thinking about the paging atomicity issue. I think it could be >> fixed with mutation tracking and with

Re: [DISCUSS] CEP-45: Mutation Tracking

payload, so if the application is taking long enough between pages that the log has been truncated, we’d have to throw an exception. This is mostly just me brainstorming though, and wouldn’t be something that would be in a v1. > On Jan 9, 2025, at 2:07 PM, Blake Eggleston wrote: > > S

Re: [DISCUSS] CEP-45: Mutation Tracking

 >>>>> > It's true that we can't offer multi-page write atomicity without some >>>>> > sort of MVCC. There are a lot of common query patterns that don't >>>>> > involve paging though, so it's not like the benefit of fixing

Re: [DISCUSS] CEP-45: Mutation Tracking

>>> > In the case of read repair, since we are only reading and correcting the >>> > parts of a partition that we're reading and not the entire contents of a >>> > partition on each read, read repair can break our guarantee on partition >>> >

Re: [DISCUSS] CEP-45: Mutation Tracking

say guarantee. From the CEP: >>>>> >>>>> > In the case of read repair, since we are only reading and correcting >>>>> > the parts of a partition that we're reading and not the entire contents >>>>> > of a partition on each read, read repair can break

Re: [DISCUSS] CEP-45: Mutation Tracking

P which has the mutation. > > I've worked with users who have been surprised by this behavior, because > pagination happens transparently. > > So even without repair mucking things up, we're unable to fulfill this > promise except under the specific, ideal circumsta

[DISCUSS] CEP-45: Mutation Tracking

atacenters The CEP is linked here: https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-45%3A+Mutation+Tracking, but please keep the discussion on the dev list. Thanks! Blake Eggleston

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. Its initial scope was for those use cases, but it’s potential for enabling more sophisticated functionality was one of its selling points and is l

Re: [VOTE] Release Apache Cassandra 5.0-rc1

Looking at the ticket, I’d say Jon’s concern is legitimate. The segfaults Jon is seeing are probably caused by paxos V2 when combined with off heap memtables for the reason Benedict suggests in the JIRA. This problem will continue to exist in 5.0. Unfortunately, it looks like the patch posted is

Re: [VOTE] Release dtest-api 0.0.16

+1On Aug 17, 2023, at 12:37 AM, Alex Petrov wrote:+1On Thu, Aug 17, 2023, at 4:46 AM, Brandon Williams wrote:+1Kind Regards,BrandonOn Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi wrote:>> Proposing the test build of in-jvm dtest API 0.0.16 for release.>> Repository:> https://gitb

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

+1 > On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa wrote: > > Hi Everyone! > > I would like to start a vote thread for CEP-34. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators > JIRA

Re: [VOTE] CEP-21 Transactional Cluster Metadata

+1 > On Feb 6, 2023, at 8:15 AM, Sam Tunnicliffe wrote: > > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata > > Discussion: > https://lists.apache.org/thread/h25skwkbdztz9

Re: [DISCUSS] Removing support for java 8

efficient so that people on all > ends can progress with whatever they work on. Let’s talk to Mick and put down > the pin-points and assess the plan? How about that? > > On Mon, 29 Aug 2022 at 17:25, Blake Eggleston <mailto:beggles...@apple.com>> wrote: > Can you say som

Re: [DISCUSS] Removing support for java 8

we add 17, to avoid making extra work. > > Kind Regards, > Brandon > > On Mon, Aug 29, 2022 at 3:40 PM Blake Eggleston wrote: >> >> Sorry, I meant trunk, not 4.1 :) >> >>> On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: >>> >>> Hi al

Re: [DISCUSS] Removing support for java 8

Yes I'd seen the 11+17 thread, but didn't see anything about an explicit jdk8 removal (ie: removal from CI etc). Ekaterina informed me there was an earlier thread covering that though > On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: > > Hi all, I wanted to propose re

Re: [DISCUSS] Removing support for java 8

Sorry, I meant trunk, not 4.1 :) > On Aug 29, 2022, at 1:09 PM, Blake Eggleston wrote: > > Hi all, I wanted to propose removing jdk8 support for 4.1. Active support > ended back in March of this year, and I believe the community has built > enough confidence in java 1

[DISCUSS] Removing support for java 8

Hi all, I wanted to propose removing jdk8 support for 4.1. Active support ended back in March of this year, and I believe the community has built enough confidence in java 11 to make it an uncontroversial change for our next major release. Let me know what you think. Thanks, Blake

Re: CEP-15 multi key transaction syntax

I think we’ve converged on a starting syntax. Are there any additional comments before I open a JIRA? > On Jun 16, 2022, at 10:33 AM, Blake Eggleston wrote: > > I think in any scenario where the same cell is updated multiple times, the > last one would win. The final result fo

Re: CEP-15 multi key transaction syntax

hmetic (that itself yields NULL) > > This is explicitly stipulated in ANSI SQL 92, in 6.12 expression>: > > General Rules > > 1) If the value of any simply contained in a > is the null value, then the result of > the is the null val

Re: CEP-15 multi key transaction syntax

Yeah I'd say NULL is fine for condition evaluation. Reference assignment is a little trickier. Assigning null to a column seems ok, but we should raise an exception if they're doing math or something that expects a non-null value > On Jun 16, 2022, at 8:46 AM, Benedict Elliott Smith > wrote: >

Re: CEP-15 multi key transaction syntax

I see what you mean. We have the EXISTS/NOT EXISTS condition for explicitly checking for the existence of a row. One thing the old syntax did is how it handled references to columns that don't exist. Previously, if any column reference didn't resolve, the update wouldn't apply. With the new synt

Re: CEP-15 multi key transaction syntax

, this would simplify the initial implementation, and let feature requests and first hand experience inform where and how the syntax develops from there. Blake > On Jun 13, 2022, at 12:14 PM, Blake Eggleston wrote: > > Does the IF <...> ABORT simplify reasoning though? If you rest

Re: CEP-15 multi key transaction syntax

on't have a clear answer, but I would love hearing from people > on what they think. > > > Patrick > > > On Fri, Jun 10, 2022 at 12:07 PM bened...@apache.org > <mailto:bened...@apache.org> <mailto:bened...@apache.org>> wrote: > > This mi

Re: CEP-15 multi key transaction syntax

> IF q1.a != 1 ROLLBACK TRANSACTION > UPDATE tbl SET a = q1.a + 1 WHERE k = 1 AS q2 > COMMIT TRANSACTION > > This is less succinct, but might be more familiar to users. We could also > eschew the ability to read from UPDATE statements entirely in this scheme, as > this woul

Re: CEP-15 multi key transaction syntax

o single rows we are updating, so we could simply maintain a > collections of rows and upsert into them as we process the execution. Most > transactions won’t need it, I suspect, so we don’t need to worry about > perfect efficiency. > > > From: Blake Eggleston > Date: Tuesday, 7 J

Re: CEP-15 multi key transaction syntax

is I think highly desirable for user experience, but this > does complicate it a bit if we want to remain intuitive. > > > > > From: Blake Eggleston > Date: Monday, 6 June 2022 at 23:17 > To: dev@cassandra.apache.org > Subject: Re: CEP-15 multi key transaction syn

Re: CEP-15 multi key transaction syntax

Hi all, Thanks for all the input and questions so far. Glad people are excited about this! I didn’t have any free time to respond this weekend, although it looks like Benedict has responded to most of the questions so far, so if I don’t respond to a question you asked here, you can interpret t

CEP-15 multi key transaction syntax

Hi dev@, I’ve been working on a draft syntax for Accord transactions and wanted to bring what I have to the dev list to solicit feedback and build consensus before moving forward with it. The proposed transaction syntax is intended to be an extended batch syntax. Basically batches with selects,

Re: [DISCUSS] Mentoring newcomers

I’m happy to help out > On Nov 12, 2021, at 9:04 AM, Benjamin Lerer wrote: > > Hi everybody > > As discussed in the *Creating a new slack channel for newcomers* thead, a > solution to help newcomers engage with the project would be to provide a > list of mentors that newcomers can contact when

Re: [VOTE] CEP-15: General Purpose Transactions

1. +1 2. +1 3. +1 > On Oct 14, 2021, at 9:31 AM, bened...@apache.org wrote: > > Hi everyone, > > I would like to start a vote on this CEP, split into three sub-decisions, as > discussion has been circular for some time. > > 1. Do you support adopting this CEP? > 2. Do you support the transacti

Re: Tradeoffs for Cassandra transaction management

the way while a vote on CEP-15 seemed > imminent. But discussing this tradeoffs thread with Jonathan, he encouraged > me to say these points in my own words, so here we are. > > > On Sun, Oct 10, 2021 at 7:17 AM Blake Eggleston > mailto:beggles...@apple.com.invalid>> wrot

Re: Tradeoffs for Cassandra transaction management

Let’s get back on topic. Jonathan, in your opening email you stated that, in your view, the 2 main areas of tradeoff were: > 1. Is it worth giving up local latencies to get full global consistency? Now we’ve established that we don’t need to give up local latencies with Accord, which leaves:

Re: Tradeoffs for Cassandra transaction management

I want to avoid it also, but if we’re going to compare Accord against a hypothetical SQL feature that seems to lack design goals, or any clear ideas about how it might be implemented, I don’t think we can rule it out. > On Oct 11, 2021, at 6:02 AM, Jonathan Ellis wrote: > > On Sat

Re: Tradeoffs for Cassandra transaction management

1. Is it worth giving up local latencies to get full global consistency? Most LWT use cases use LOCAL_SERIAL. This isn’t a tradeoff that needs to be made. There’s nothing about Accord that prevents performing consensus in one DC and replicating the writes to others. That’s not in scope for the

Re: [DISCUSS] CEP-15: General Purpose Transactions

You could establish a lower timestamp bound and buffer transaction state on the coordinator, then make the commit an operation that only applies if all partitions involved haven’t been changed by a more recent timestamp. You could also implement mvcc either in the storage layer or for some perio

Re: [DISCUSS] CEP-15: General Purpose Transactions

Hi Jake, > 1. Will this effort eventually replace consistency levels in C*? I ask > because one of the shortcomings of our paxos today is > it can be easily mixed with non serialized consistencies and therefore > users commonly break consistency by for example reading at CL.ONE while > also > us

Re: [VOTE] Release Apache Cassandra 4.0.1

+1 > On Sep 1, 2021, at 4:54 AM, Sam Tunnicliffe wrote: > > Proposing the test build of Cassandra 4.0.1 for release. > > sha1: 6709111ed007a54b3e42884853f89cabd38e4316 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative > Maven Artifacts: > http

Re: [VOTE] CEP-14: Paxos Improvements

+1 > On Aug 27, 2021, at 12:48 PM, bened...@apache.org wrote: > > Hi everyone, I’m proposing this CEP for approval. > > Proposal: > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements > Discussion: > https://lists.apache.org/thread.html/r1af3da2d875ef93479e387407

Re: [DISCUSS] Repair Improvement Proposal

+1 from me, any improvement in this area would be great. It would be nice if this could include visibility into repair streams, but just exposing the repair state will be a big improvement. > On Aug 25, 2021, at 5:46 PM, David Capwell wrote: > > Now that 4.0 is out, I want to bring up improvin

Re: [VOTE] CEP-10: Cluster and Code Simulations

+1 > On Jul 27, 2021, at 9:21 PM, Scott Andreas wrote: > > +1 nb > > > From: Sam Tunnicliffe > Sent: Tuesday, July 27, 2021 12:54 AM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] CEP-10: Cluster and Code Simulations > > +1 > >> On 26 Jul 2021,

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

+1 > On Jul 23, 2021, at 6:39 AM, Branimir Lambov > wrote: > > +1 > >> On Fri, Jul 23, 2021 at 4:15 PM Aleksey Yeschenko >> wrote: >> >> +1 >> On 23 Jul 2021, at 14:03, Joshua McKenzie wrote: >>> >>> +1 >>> >>> On Fri, Jul 23, 2021 at 8:07 AM Dinesh Joshi >> >>> wrote: >>> +

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

+1 > On Jul 14, 2021, at 8:21 AM, Aleksey Yeschenko wrote: > > +1 > >> On 14 Jul 2021, at 15:37, Jonathan Ellis wrote: >> >> +1 >> >>> On Tue, Jul 13, 2021 at 5:14 PM Mick Semb Wever wrote: >>> >>> Proposing the test build of Cassandra 4.0.0 for release. >>> >>> sha1: 924bf92fab182094213

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

+1 > On Apr 21, 2021, at 2:25 PM, Scott Andreas wrote: > > +1nb, thank you! > > > From: Ekaterina Dimitrova > Sent: Wednesday, April 21, 2021 12:23 PM > To: dev@cassandra.apache.org > Subject: Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2) > > +1

Re: [VOTE] Release Apache Cassandra 4.0-rc1

+1 > On Mar 29, 2021, at 6:05 AM, 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: > h

Re: [VOTE] Release dtest-api 0.0.7

+1, sorry for the html barf :) > On Dec 3, 2020, at 9:53 AM, Blake Eggleston > wrote: > > Proposing the test build of in-jvm dtest API 0.0.7 for > release. > > Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags

Re: [VOTE] Release dtest-api 0.0.7

Proposing the test build of in-jvm dtest API 0.0.7 for release. Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.7 Candidate SHA:https://github.com/apache/cassandra-in-jvm-dtest-api/commit/d5174b1f44b7d9cb919d4975b4d437041273c09c tagged w

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

for choosing correctness is easier to live with ;-) >> >> Benjamin >> >> PS: I tried to push the choice on Sylvain but he dodged the bullet. >> >> On Sat, Nov 21, 2020 at 12:30 AM Benedict Elliott Smith < >> bened...@apache.org> >> wrote: >>

Re: [DISCUSS] CASSANDRA-12126: LWTs correcteness and performance

I’d also prefer #3 over #4 > On Nov 20, 2020, at 10:03 AM, Benedict Elliott Smith > wrote: > > Well, I expressed a preference for #3 over #4, particularly for the 3.x > series. However at this point, I think the lack of a clear project decision > means we can punt it back to you and Sylvain

Re: [VOTE] Accept the Harry donation

+1 > On Sep 16, 2020, at 2:45 AM, Mick Semb Wever wrote: > > This vote is about officially accepting the Harry donation from Alex Petrov > and Benedict Elliott Smith, that was worked on in CASSANDRA-15348. > > The Incubator IP Clearance has been filled out at > http://incubator.apache.org/ip-cl

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

+1 > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > Currently our style guide recommends to avoid using @Override and updates > intellij's code style to exclude it by default; I would like to propose we > change this recommendation to use it and to update intellij's style to > include it

Re: [VOTE] Release Apache Cassandra 4.0-beta2

+1 > On Aug 28, 2020, at 7:18 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 4.0-beta2 for release. > > sha1: 56eadf2004399a80f0733041cacf03839832249a > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta2-tentative > Maven Artifacts:

Re: [VOTE] Release Apache Cassandra 3.0.22

+1 > On Aug 28, 2020, at 6:09 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.0.22 for release. > > sha1: 45331bb612dc7847efece7e26cdd0b376bd11249 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.22-tentative > Maven Artifacts: > htt

Re: [VOTE] Release Apache Cassandra 2.1.22

+1 > On Aug 28, 2020, at 8:55 AM, Jeff Jirsa wrote: > > +1 > > > On Fri, Aug 28, 2020 at 8:42 AM Mick Semb Wever wrote: > >> Proposing the test build of Cassandra 2.1.22 for release. >> >> sha1: 94e9149c22f6a7772c0015e1b1ef2e2961155c0a >> Git: >> >> https://gitbox.apache.org/repos/asf?p=ca

Re: [VOTE] Release Apache Cassandra 2.2.18

+1 > On Aug 28, 2020, at 5:44 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 2.2.18 for release. > > sha1: d4938cf4e488a9ef3ac48164a3e946f16255d721 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.18-tentative > Maven Artifacts: > htt

Re: [VOTE] Release Apache Cassandra 3.11.8

+1 > On Aug 28, 2020, at 6:37 AM, Mick Semb Wever wrote: > > Proposing the test build of Cassandra 3.11.8 for release. > > sha1: 8b29b698630960a0ebb2c695cc5b21dee4686d09 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.8-tentative > Maven Artifacts: > htt

Re: Check in on CASSANDRA-15393

landing? The later, the more risk to stability of > GA due to lack of time soaking. > > On Thu, Aug 27, 2020 at 4:01 PM Blake Eggleston > wrote: > >> Hi dev@, >> >> Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's >> some co

Check in on CASSANDRA-15393

Hi dev@, Mick asked that I check in w/ the dev list about CASSANDRA-15393. There's some concern regarding the patch and it's suitability for inclusion in 4.0-beta. CASSANDRA-15393 reduces garbage created by compaction and the read paths by about 25%. It's part of CASSANDRA-15387, which, includi

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

+1 > On Jul 20, 2020, at 9:56 AM, Jon Haddad wrote: > > +1, thanks Mick for rerolling. > > On Mon, Jul 20, 2020 at 6:42 AM Joshua McKenzie > wrote: > >> +1 >> >> On Mon, Jul 20, 2020 at 8:51 AM Jake Luciani wrote: >> >>> +1 >>> >>> On Mon, Jul 20, 2020 at 8:08 AM Andrés de la Peña < >>> a

Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)

Characterizing alternate or conflicting points of view as assuming bad intentions without justification is both unproductive and unhealthy for the project. > On Jul 20, 2020, at 9:14 AM, Joshua McKenzie wrote: > > This kind of back and forth isn't productive for the project so I'm not > taking

Re: Media coordination (was: [VOTE] Release Apache Cassandra 4.0-beta1)

I don't think Benedict mentioned anything about people's motives or intentions, he simply had a concern about how marketing timelines became a factor in a release vote without the approval of the PMC. I think this is a reasonable concern, and doesn't mean that he's assuming bad intentions. That'

Re: [DISCUSS] Future of MVs

+1 for deprecation and removal (assuming a credible plan to fix them doesn't materialize) > On Jun 30, 2020, at 12:43 PM, Jon Haddad wrote: > > A couple days ago when writing a separate email I came across this DataStax > blog post discussing MVs [1]. Imagine my surprise when I noticed the dat

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

+1 > On Jun 20, 2020, at 8:12 AM, 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

  1   2   >