Unless there’s 2-3 other people who expect to keep working on it, I don’t see how we justify creating a subprojectAnd if there’s not 2-3 people expressing interest, even pulling it into the main project seems riskySo: besides Jon, who in the community expects/desires to maintain this going
I think Jordan and German had an interesting insight, or at least their comment made me think about this slightly differently, and I’m going to repeat it so it’s not lost in the discussion about zerocopy / sendfile.The CEP treats this as “move a live instance from one machine to another”. I know
On 2024/02/21 09:26:53 Jarek Potiuk wrote:
> Hello dear Cassandra community,
>
> I am a fellow PMC member of Apache Airflow and recently we started to look
> at the Cassandra provider of ours in the context of Python 3.12 migration
> and the integration raised my interest.
>
> TL;DR; I am
1) If there’s an “old compatible default” and “latest recommended settings”,
when does the value in “old compatible default” get updated? Never?
2) If there are test failures with the new values, it seems REALLY IMPORTANT to
make sure those test failures are discovered + fixed IN THE FUTURE
Auth is one of those things that needs to be a bit more concrete In the scenario you describe, you already have an option to deploy the auth in piece partially during the rollout (pause halfway through) in the cluster and look for asymmetric connections, and the option to drop in a new
The problem with generalizing things is if you’re behind on compaction, reads get expensive, so you pause compaction completely, you’re SOL and you’ll eventually have to throttle traffic to recoverThe SEDA model is bad at back pressure and deferred cost makes it non-obvious which resource to slow
> On Dec 14, 2023, at 1:51 PM, Dinesh Joshi wrote:
>
>
>>
>> On Dec 14, 2023, at 10:32 AM, Ariel Weisberg wrote:
>>
>> 1. Fork OHC and start publishing under a new package name and continue to
>> use it
>
> Who would fork it? Where would you fork it? My first instinct is that this
>
I'm also torn on the CEP as presented. I think some of it is my negative
emotional response to the examples - e.g. I've literally never seen a real
use case where unfolding constants matters, and I'm trying to convince
myself to read past that.
I also cant tell what exactly you mean when you say
-0 to cutting a beta we know has a very obvious correctness flaw with a fix
already understood
On Tue, Nov 28, 2023 at 10:40 AM Patrick McFadin wrote:
> JD, that wasn't my point. It feels like we are treating a beta like an RC,
> which it isn't. Ship Beta 1 now and Beta 2 later. We need
grandfather in TCM and Accord past freeze date if they can make
> it by October".
>
> So that's the history for how we landed here.
>
> 2) Do we drop the support of 3.0 and 3.11 after 5.0.0 is out or after
> 5.1.0 is?
>
> This is my understanding, yes. Deprecation and suppor
On Mon, Oct 23, 2023 at 4:52 AM Mick Semb Wever wrote:
>
> The TCM work (CEP-21) is in its review stage but being well past our
> cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
> like to propose the following.
>
>
I think this presumes that 5.0 GA is date driven instead
+1
On Mon, Oct 2, 2023 at 9:53 PM Mick Semb Wever wrote:
> The donation of the java-driver is ready for its IP Clearance vote.
> https://incubator.apache.org/ip-clearance/cassandra-java-driver.html
>
> The SGA has been sent to the ASF. This does not require acknowledgement
> before the vote.
Claude if you’re still at POC phase does it make sense for you to perhaps help validate / qualify the work that Henrik seems willing to rebase rather than reinventing the wheel? On Sep 26, 2023, at 11:23 PM, Claude Warren, Jr via dev wrote:I spent a little (very little) time building an S3
- I think this is a great step forward.
- Being able to move sstables around between tiers of storage is a feature
Cassandra desperately needs, especially if one of those tiers is some sort
of object storage
- This looks like it's a foundational piece that enables that. Perhaps by a
team that's
To do that, the cassandra PMC can open a legal JIRA and ask for a (durable,
concrete) opinion.
On Fri, Sep 22, 2023 at 5:59 AM Benedict wrote:
>
>1. my understanding is that with the former the liability rests on the
>provider of the lib to ensure it's in compliance with their claims
13, 2023 at 9:25 AM Ekaterina Dimitrova
wrote:
> Jeff, isn’t this ok as long as it is used only in tests? If we are not
> sure we can open a Jira to legal?
>
> On Wed, 13 Sep 2023 at 12:23, Jeff Jirsa wrote:
>
>> Just to be clear - this repo?
>> https://github.co
Just to be clear - this repo?
https://github.com/haifengl/smile/blob/master/LICENSE
That shows GPL + Commercial?
On Wed, Sep 13, 2023 at 9:10 AM Brandon Williams wrote:
> I don't see any problem with this, +1.
>
> Kind Regards,
> Brandon
>
>
> On Wed, Sep 13, 2023 at 11:09 AM Mike Adamson
>
Given the disclaimer, can you just confirm why we'd cut an alpha now -
we're trying to lock protocols and give other people an integration target,
presumably?
On Fri, Aug 25, 2023 at 8:14 AM Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
>
+1
On Mon, Jul 10, 2023 at 8:42 AM Josh McKenzie wrote:
> 2) keep it there in 5.0 but mark it @Deprecated
>
> I'd say Deprecate, log warnings that it's not supported nor maintained and
> people to use it at their own risk, and that it's going to be removed.
>
> That is, assuming the
On Thu, Jun 22, 2023 at 11:23 PM Berenguer Blasi
wrote:
> Hi all,
>
> Given we're already introducing a new sstable format (OA) in 5.0 I would
> like to try to get this in before the freeze. The point being that
> sstables with lots of small partitions would benefit from a smaller DT
> at
Either would be better than today.
On Thu, Jun 22, 2023 at 1:57 PM Jordan West wrote:
> Hi,
>
> I’m wondering if there is appetite to change the default SSL provider for
> Cassandra going forward to either ACCP [1] or tc-native in Netty? Our
> deployment as well as others I’m aware of make this
+1
On Tue, Jun 13, 2023 at 7:15 AM Jeremy Hanna
wrote:
> Calling for a vote on CEP-8 [1].
>
> To clarify the intent, as Benjamin said in the discussion thread [2], the
> goal of this vote is simply to ensure that the community is in favor of
> the donation. Nothing more.
> The plan is to
On Mon, Jun 12, 2023 at 10:18 AM Mick Semb Wever wrote:
>
>
> On Mon, 12 Jun 2023 at 15:02, Maxim Muzafarov wrote:
>
>> Hello everyone,
>>
>> I would like to make the source code of the Cassandra project more
>> visible to people outside of the Cassandra Community and highlight the
>> typical
On Mon, Jun 12, 2023 at 9:50 AM Benjamin Lerer wrote:
> If you have rows that vary significantly in their size, your latencies
>> could end up being pretty unpredictable using a LIMIT BY . Being
>> able to specify a limit by bytes at the driver / API level would allow app
>> devs to get more
Changes like this always scare me, but the benefits probably outweigh the
risks. Probably obviously to whoever implements but please make sure if
this happens is super visible in both NEWS and simultaneously updates the
to-string / to-cql representation of the schema in cqlsh / drivers /
snapshots
On Thu, Apr 27, 2023 at 7:39 AM Jonathan Ellis wrote:
> It's been a while, so I may be missing something, but do we already have
> fixed-size lists? If not, I don't see why we'd try to make this fit into a
> List-shaped problem.
>
We do not. The proposal got closed as wont-fix
KEYSPACE at least makes sense in the context that it is the unit that
defines how those partitions keys are going to be treated/replicated
DATABASE may be ambiguous, but it's ambiguity shared across the industry.
Creating a new name like TABLESPACE or TABLEGROUP sounds horrible because
it'll be
On Tue, Mar 28, 2023 at 7:30 AM Jeremiah D Jordan
wrote:
> - Resources isolation. Having the said service running within the same JVM
> may negatively impact Cassandra storage's performance. It could be more
> beneficial to have them in Sidecar, which offers strong resource isolation
>
ize that
> LCS would try to reduce the scope of the compaction. I can't find in the
> branch where it handles that.
>
> Branimir, can you point to where it handles the scenario?
>
> Thanks,
>
> Jeremy
>
>>> On Mar 17, 2023, at 4:52 PM, Jeff Jirsa wrote:
>
> On Mar 17, 2023, at 1:46 PM, Jeremy Hanna wrote:
>
>
>
> One much more graceful element of UCS is that instead of what was previously
> done with compaction strategies where the server just shuts down when running
> out of space - forcing system administrators to be paranoid about
On Wed, Mar 8, 2023 at 5:25 AM Bowen Song via dev
wrote:
> At the moment, when a read error, such as unrecoverable bit error or data
> corruption, occurs in the SSTable data files, regardless of the
> disk_failure_policy configuration, manual (or to be precise, external)
> intervention is
Anyone have stats on how many people use RF > 3 per dc? (I know what it looks like in my day job but I don’t want to pretend it’s representative of the larger community) I’m a fan of fixing this but I do wonder how common this is in the wild. On Mar 7, 2023, at 9:12 AM, Derek Chen-Becker wrote:I
A huge number of people use this legal and unsafe combination - like anyone
running RF=3 in AWS us-west-1 (or any other region with only 2 accessible
AZs), and no patch is going to suddenly make that safe, and banning it
hurts users a lot.
If we're really going to ship a less-bad version of this,
When people are serious about this requirement, they’ll build the downgrade equivalents of the upgrade tests and run them automatically, often, so people understand what the real gap is and when something new makes it break Until those tests exist, I think collectively we should all stop
I'm not even convinced even 8110 addresses this - just writing sstables in
old versions won't help if we ever add things like new types or new types
of collections without other control abilities. Claude's other email in
another thread a few hours ago talks about some of these surprises -
+1
On Mon, Feb 6, 2023 at 8:16 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:
>
Usually requires an offer to donate from the current owner, an acceptance
of that offer (PMC vote), and then the work to ensure that contributions
are acceptable from a legal standpoint (e.g. like the incubator -
https://incubator.apache.org/guides/transitioning_asf.html - "For
contributions
But it's not merge-than-review, because they've already been reviewed,
before being merged to the feature branch, by committers (actually PMC
members)?
You want code that's been written by one PMC member and reviewed by 2 other
PMC members to be put up for review by some random 4th party?
Concurrent shouldn’t matter (they’re non-overlapping in the repro). And I’d personally be a bit surprised if table count matters that much. It probably just requires high core count and enough data that the streams actually interact with the rate limiter On Dec 11, 2022, at 10:32 AM, Mick Semb
On Thu, Nov 17, 2022 at 12:47 PM J. D. Jordan
wrote:
> -1 on providing a bunch of choices and forcing users to pick one. We
> should have a default and it should be “good enough” for most people. The
> people who want to dig in and try other gc settings can still do it, and we
> could provide
I'll withdraw my comment about friendliness of g1 vs cms. I think it's too
late to sneak it in, but wouldn't object formally.
offheap_objects is way too late to change given we shipped the alpha in May
and there are known, long lived bugs that multiple users have reported and
wouldn't have been
G1 you can argue for with the changes in the JDK, though it's MUCH less
friendly to small heaps (e.g. probably our default simple user).
Offheap memtables are different though. If someone wants to attest that
offheap_objects get the same level of rigorous testing as the existing
default, that'd
I don't think logging which policy violation was triggered is that big of
an ask?
"Password changed for user X, complying with policies (reuse, complexity,
entropy)"
"ERROR: Password rejected due to policy violation (reuse)"
"ERROR: Password rejected due to policy violation (complexity)"
"ERROR:
I expect that a lot of use cases will update M and insert into N tables
based on one condition, so if that's a problem with the grammar today, I
think it'd probably be worth the time to sort that out?
On Wed, Sep 21, 2022 at 12:42 PM David Capwell wrote:
> Caleb is making great progress on
“ The proposed mechanism for dealing with both of these failure types is to
enable a manual operator override mode. This would allow operators to inject
metadata changes (potentially overriding the complete metadata state) directly
on any and all nodes in a cluster. At the most extreme end of
This type of feature is very useful, but it may be easier to analyze this
proposal if it’s compared with other DDM implementations from other databases?
Would it be reasonable to add a table to the proposal comparing syntax and
output from eg Azure SQL vs Cassandra vs whatever ?
> On Aug 19,
Stop node 1 before you start node 2, essentially mocking a full network
partition.
On Tue, Aug 9, 2022 at 11:57 AM Cheng Wang via dev
wrote:
> Thank you, Aleksey,
> Yes, I have tried this approach, the problem is there is a timing window
> that node 1 runs the CREATE TABLE while node 2 is
s is when there are two CREATE TABLE
> queries running on two coordinator nodes concurrently, it might end up with
> 2 schema versions and they would never get resolved automatically because
> table id is random TimeUUID.
>
>
>
> On Mon, Aug 8, 2022 at 3:54 PM Jeff Jirsa wrote:
&
Which (of the many) schema disagreement issue(s)?
On Mon, Aug 8, 2022 at 3:29 PM Cheng Wang via dev
wrote:
> Thank you for the reply, Brandon! It is helpful!
>
> I was thinking of creating a cluster with 2 nodes and having two
> concurrent CREATE TABLE statements running. But the test will be
The hypothetical concern described is around potential data resurrection -
would you still use resumable bootstrap if you knew that data deleted
during those STW pauses was improperly resurrected?
On Wed, Aug 3, 2022 at 2:40 PM Bowen Song via dev
wrote:
> I have benefited from the resumable
And would you allow a transaction that had > 1 named select and no modification
statements, but commit if 1=1 ?
> On Jun 4, 2022, at 2:45 PM, Jeff Jirsa wrote:
>
>
>
>> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote:
>>
>> Hi dev@,
>
>
> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote:
>
> Hi dev@,
First, I’m ridiculously excited to see this.
>
> 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
An easier fix here is just to put a close action into the commit message:
Closes #nnn
e.g.
https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd
/ https://github.com/apache/cassandra/pull/1046
On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie wrote:
> I think the
We've done concurrent releases without security before, and you follow much
closer than others. I feel most people, if they saw all of the
changes reverted and a release of a single fix, would either instantly know
it's security (high confidence pointer to exactly which patch) OR assume
someone
We don't HAVE TO remove the Config.java entry - we can mark it as
deprecated and ignored and remove it in a future version (and you could
update Config.java to log a message about having a deprecated config
option). It's a much better operator experience: log for a major version,
then remove in
Accidentally dropped dev@, so adding back in the dev list, with the hopes
that someone on the dev list helps address this.
On Fri, Feb 11, 2022 at 2:22 PM Jeff Jirsa wrote:
> That looks like https://issues.apache.org/jira/browse/CASSANDRA-17132 +
> https://github.com/apache/cassandra/
(This was a +1 on the release, to be clear, not a +1 on the sentiment
below, which I appreciate but still believe we should proceed with the
release)
On Tue, Feb 8, 2022 at 3:44 PM Jeff Jirsa wrote:
> +1
>
>
> On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie
> wrote:
>
>>
+1
On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie wrote:
> I find myself agreeing with Jeremiah's sentiment here.
>
> For example, we're asking people that are on 4.0.1 to make the difficult
> choice between accepting the risk of whatever prompts an urgent release vs.
> accepting the risk of
+1
> On Jan 18, 2022, at 8:38 AM, Jonathan Ellis wrote:
>
>
> +1
>
>> On Tue, Jan 18, 2022 at 10:34 AM C. Scott Andreas
>> wrote:
>> I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an
>> interface for those who would like to supply a UDF implementation; and to
>>
Sounds like a great addition
Can you share some of the details around gc and latency improvements you’ve
observed with the list?
Any specific reason the confirmation is through schema vs yaml? Presumably it’s
so a user can test per table, but this changes every host in a cluster, so the
> On Nov 19, 2021, at 2:53 PM, Joseph Lynch wrote:
>
>
>>
>> For better or worse, different threat models mean that it’s not strictly
>> better to do FDE and some use cases definitely want this at the db layer
>> instead of file system.
>
> Do you mind elaborating which threat models?
For better or worse, different threat models mean that it’s not strictly better
to do FDE and some use cases definitely want this at the db layer instead of
file system.
> On Nov 19, 2021, at 12:54 PM, Joshua McKenzie wrote:
>
>
>>
>>
>> setting performance requirements on this regard
+1
On Mon, Nov 15, 2021 at 11:43 AM Branimir Lambov wrote:
> Hi everyone,
>
> I would like to start a vote on this CEP.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
>
> Discussion:
>
>
New developers or new users? I'd be afraid that a new developer-focused
channel might not get many eyes (or, it'll get the same 600 eyes, and it'll
have the same problem).
On Mon, Nov 8, 2021 at 8:29 AM Benjamin Lerer wrote:
> Hi everybody,
>
> Aleksei Zotov mentioned to me that it was a bit
Without bike-shedding too much, guardrails would be great, building them
into a more general purpose framework that limits various dangerous things
would be fantastic. The CEP says that the guardrails should be distinct
from the capability restrictions (
I support adopting this CEP, and the transaction semantics, and the
incremental approach to developing transactions, so I'm +1 on all three
I also think that it is preferrable that we get to a point where the -1 be
withdrawn, because I think it's a bad precedent to force the PMC to try to
Do I read this email as "Jonathan will vote against any improvement to
transactions that doesn't guarantee local latencies and interactive SQL,
even though no such proposal exists, thereby blocking any improvement over
the current status quo?"
On Thu, Oct 14, 2021 at 6:55 AM Jonathan Ellis
I'll read more of this in a bit, I want to make sure I fully digest it
before commenting on the rest, but this block here deserves a few words:
On Sat, Oct 9, 2021 at 9:54 AM Jonathan Ellis wrote:
> After putting the above together it seems to
> me that the two main areas of tradeoff are, 1.
+1
On Wed, Sep 8, 2021 at 9:31 AM Sumanth Pasupuleti <
sumanth.pasupuleti...@gmail.com> wrote:
> Hi everyone,
>
> I’m proposing this CEP for approval.
>
> Proposal:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions
> Discussion:
>
>
+1
On Wed, 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:
>
> On Aug 22, 2021, at 7:25 PM, Miles Garnsey wrote:
>
>
>>
>> The problem is that today there’s no way to reliably exclude the new DC from
>> serving reads, that I know of? If you can, then yes you would only need to
>> ensure repair were run prior to activating reads from this DC.
>
>
+1
Sent from my iPhone
> On Aug 19, 2021, at 9:19 AM, bened...@apache.org wrote:
>
> +1
>
> From: Brandon Williams
> Date: Thursday, 19 August 2021 at 17:16
> To: dev@cassandra.apache.org
> Subject: Re: [VOTE] CEP-11: Pluggable memtable implementations
> +1
>
>> On Thu, Aug 19, 2021 at
The hint behavior aside, stopping native protocol once you begin a decom
seems like something most people would benefit from, even if they dont
realize that's what they want to happen.
On Tue, Aug 10, 2021 at 12:53 PM Matt Fleming
wrote:
> Hi,
>
> With the way that hint transfer currently
Agreed. Status quo is status quo. If someone wants to change status quo,
CEP would be appreciated.
Until CEP exists and is approved, work on patches in flight seems
reasonable and valid.
On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan
wrote:
> I see no problem with continuing to add JMX
On Thu, Jul 15, 2021 at 12:59 PM Brandon Williams wrote:
> On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta
> wrote:
> >
> > Perhaps one approach to expose VirtualTables via nodetool without
> requiring
> > the user to provide CQL credentials would be to provide a generic
> >
There's a tactical issue, too, that virtual tables require native transport
to be up before it's usable, so for things pre-startup (e.g. querying
streaming state during bootstrap), so I don't think nodetool/jmx dies
entirely ever (or, a non-client-facing-virtual-tables-only port has to be
created,
Same
On Wed, Jul 14, 2021 at 9:16 AM Brandon Williams wrote:
> I am +1 to both removal from the template and "we need this"
>
> On Wed, Jul 14, 2021 at 9:05 AM Joshua McKenzie
> wrote:
> >
> > And I'm a +1 on the "I agree we need this".
>
>
+1
On Tue, Jul 13, 2021 at 3:14 PM Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0.0 for release.
>
> sha1: 924bf92fab1820942137138c779004acaf834187
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative
> Maven Artifacts:
>
>
+1
> On Jun 28, 2021, at 9:00 PM, Jeremy Hanna wrote:
>
> +1 (nb) nice to see all of the fixes and the use of newer TLS by default and
> obfuscation of passwords in the audit log for the 4.0 release.
>
>> On Jun 29, 2021, at 6:01 AM, Jon Meredith wrote:
>>
>> +1 (nb)
>>
On Mon, Jun
This would be my preference.
On Wed, Jun 23, 2021 at 2:22 PM Ben Bromhead wrote:
> I'm also comfortable with a strict approach where we just list actual
> Apache Cassandra offerings, that also provides good solid clarity to users.
>
> On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org
>
I am on the side of "this sounds like a really bad bug" for the audit
pieces, maybe less so than FQL. Anyone using audit for real probably has
meaningful audit requirements, which means they're in an industry where
they get audited for security, which means logging passwords is a big deal.
On
Given we're past the RC1, I think it's time.
Also, probably a silly question, but where's the list of issues reported in
the release candidate that need to be fixed before the GA?
On Thu, Jun 3, 2021 at 8:36 AM Brandon Williams wrote:
> Hello,
>
> In order to more safely expedite 4.0's first
On Mon, Mar 29, 2021 at 3:45 PM Justin Mclean wrote:
>
> It good to see you are taking action, but I think the situation is a
> little more seriously that you may realise, I suggest you look at what
> actions the board has taken in similar situations in the past. I'll update
> the board agenda
To quote Niclas in the legal thread:
The notion that these jars are "not open source" and must therefor not be used
in the way they are intended is a preposterous stance
This seems to genuinely be against policy in a way that is profoundly
frustrating: the source of the project is available,
No objection and strong agreement that it should happen with 4.0 for arm64
On Wed, Jan 20, 2021 at 12:44 PM Mick Semb Wever wrote:
> To get Cassandra 4.0 working on arm64 we have a number of dependencies
> we need to upgrade. See CASSANDRA-16384, CASSANDRA-16392 and
> CASSANDRA-15889.
>
>
+1 (binding)
It's not a big deal, not worth killing the release, but 15299 / a7c4ba9eeec
introduced a build warning in a burn test, I'll open a JIRA for it in a bit
(unless someone ninjas it first).
On 2020/12/18 19:16:16, Mick Semb Wever wrote:
> Proposing the test build of Cassandra
This is complicated and relatively few people on earth understand it, so
having little feedback is mostly expected, unfortunately.
My normal emotional response is "correctness is required, opt-in to
performance improvements that sacrifice strict correctness", but I'm also
sure this is going to
> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith
> wrote:
>
>
>>
>> As I understand Sankalp's primary (and quite reasonable) argument the last
>> time we discussed this
>
> The more significant cost to the project is distracting contributors focused
> on 4.0. The project is
+1
On Fri, Aug 28, 2020 at 7:43 AM Brandon Williams wrote:
> +1
>
> On Fri, Aug 28, 2020 at 8:09 AM Mick Semb Wever wrote:
> >
> > Proposing the test build of Cassandra 3.0.22 for release.
> >
> > sha1: 45331bb612dc7847efece7e26cdd0b376bd11249
> > Git:
> >
>
+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=cassandra.git;a=shortlog;h=refs/tags/2.1.22-tentative
> Maven Artifacts:
>
+1
On Fri, Aug 28, 2020 at 5:45 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:
>
>
+1
On Fri, 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:
>
>
+1
On Fri, Aug 28, 2020 at 7:19 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
I don't have any questions, but datastax folks: thanks for funding stuff
like this.
(I'd love to see it as a blog post, I'd also love to see people internalize
the negative feedback and assumed features and determine whether or not
people are working on the right things)
On Thu, Aug 27, 2020 at
> On Jul 30, 2020, at 8:08 AM, Andrew Cobley (Staff)
> wrote:
>
> Apologies, I have not been involved in this process for a few years, but I
> saw this topic pass by and thought I would like to comment.
>
> I’m a lecturer in computer science and used C* in a couple of dev classes,
>
Got it, thanks for the correction.
On Mon, Jul 20, 2020 at 4:28 PM Brandon Williams wrote:
> I believe you can run them on 11, but you can't build them on it.
>
> On Mon, Jul 20, 2020 at 6:11 PM Jeff Jirsa wrote:
> >
> > I still dont get it, because you can't use
; > Robert Stupp
> > @snazy
> >
> > > On 14. Jul 2020, at 15:02, Jeff Jirsa wrote:
> > >
> > > Zgc
> > >
> > >> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote:
> > >>
> > >>
> > >>> On 14. Ju
+1
> On Jul 17, 2020, at 4:28 PM, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0-beta1 for release.
>
> sha1: 972da6fcffa87b3a1684362a2bab97db853372d8
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta1-tentative
> Maven
Zgc
> On Jul 14, 2020, at 2:26 AM, Robert Stupp wrote:
>
>
>> On 14. Jul 2020, at 07:33, Jeff Jirsa wrote:
>>
>> Perhaps the most notable parts of jdk11 (for cassandra) aren’t even prod
>> ready in jdk11 , so what’s the motivation and what does the
> On Jul 13, 2020, at 11:42 AM, Jon Haddad wrote:
>
> Support for Java 11 was added a long time ago, and it's been about 2 years
> since it was released (Sept 2018). Had we released Cassandra 4 close to
> that date, I'd be fine with keeping the status as experimental, but at this
> point
1 - 100 of 398 matches
Mail list logo
