Re: Submit enhancements via pull requests?

JIRA + patch or link to git branch -Jeremiah On Dec 5, 2013, at 9:44 AM, Brian O'Neill b...@alumni.brown.edu wrote: Sorry guys, it¹s been a while since I submitted a patch. I see there are a number of outstanding pull requests: https://github.com/apache/cassandra/pulls Are we able to

Re: CQL unit tests vs dtests

The only thing I worry about here is that the unit tests don't come into the system the same way user queries will. So we still need the system level dtests. So I don't think all CQL tests should be unit tests, but I am all for there being unit level CQL tests. On May 22, 2014, at 10:58 AM,

Re: [VOTE] Release Apache Cassandra 2.0.10

I'm -1 on this until we get CqlRecordReader fixed (which will also fix the newly added in 2.0.10 Pig CqlNativeStoarge): https://issues.apache.org/jira/browse/CASSANDRA-7725 https://issues.apache.org/jira/browse/CASSANDRA-7726 Without those two things anyone using CqlStorage previously (which

Re: Staging Branches

Our process is our own - always remember this. On May 7, 2015, at 9:25 AM, Ariel Weisberg ariel.weisb...@datastax.com wrote: Hi, Whoah. Our process is our own. We don't have to subscribe to any cargo cult book buying seminar giving process. And whatever we do we can iterate and

Re: Requiring Java 8 for C* 3.0

With Java 7 being EOL for free versions I am +1 on this. If you want to stick with 7, you can always keep running 2.1. On May 7, 2015, at 11:09 AM, Jonathan Ellis jbel...@gmail.com wrote: We discussed requiring Java 8 previously and decided to remain Java 7-compatible, but at the time we

Re: March 2015 QA retrospective

CASSANDRA-8687 https://issues.apache.org/jira/browse/CASSANDRA-8687 Jeremiah Jordan Keyspace should also check Config.isClientMode Is there a way to test for missing Config.isClientMode checks? We should probably redo the client mode type stuff. Code should assume we are in a tool until

Re: Cassandra Java Driver and DataStax

The Apache Cassandra project has always left development of its drivers up to the community. The DataStax Java Driver is not part of the Apache Cassandra project, it is an open source project created by DataStax. You can find a large list of drivers for Cassandra here:

Re: State of Unit tests (1 out of 100 passes in trunk)

> Josh, add me to the "test fixers" queue, as well. However, I think the > authors of patches that break the build should also be on the hook for > fixing problems, as well. +1 I have always been a fan of “you broke it, you fix it"

Re: DSE vs Open Source

Hi John, I work for the DSE team. What you're seeing is the result of DSE having its own release schedule distinct from Apache Cassandra. We'll start qualifying an Apache release to build on, such as 3.0.7 for DSE 5.0, but if 3.0.8 comes out while we're still working on 5.0.1 we won't

Re: Reminder: critical fixes only in 2.1

Looking at those tickets in all three of them the “is this critical to fix” question came up in the JIRA discussion and it was decided that they were indeed critical enough to commit to 2.1. > On Jul 18, 2016, at 11:47 AM, Jonathan Ellis wrote: > > We're at the stage of the

Re: A proposal to move away from Jira-centric development

I like keeping things in JIRA because then everything is in one place, and it is easy to refer someone to it in the future. But I agree that JIRA tickets with a bunch of design discussion and POC’s and such in them can get pretty long and convoluted. I don’t really like the idea of moving all

Re: A proposal to move away from Jira-centric development

e select major JIRAs you care about. > >-- >AY > >On 15 August 2016 at 18:08:20, Jeremiah D Jordan > (jeremiah.jor...@gmail.com) wrote: > >I like keeping things in JIRA because then everything is in one place, and > it is easy to refer someone to it in

Re: A proposal to move away from Jira-centric development

When getting down to the >>> actual work and discussion about that focused work, that’s where a tool >>> like Jira comes in. Then it is reference-able in the changes.txt and other >>> things. >>> >>> I think the approach proposed by Jonathan is a nice

A proposal to get dev@ more involved

The original thread I posted this in got hi-jacked with other discussions, so I’m making a new thread for this. People have expressed interest in having more information flow to the dev@ list about major features/decisions, so that those who don’t follow commits@ or JIRA can still keep up with

Re: Perf regression between 2.2.5 and 3.11

You may be getting perf issues from message coalescing depending on what CL you are testing with: https://issues.apache.org/jira/browse/CASSANDRA-12676 Try you tests with: otc_coalescing_strategy: DISABLED > On Jan 19, 2017, at 4:28 PM, Andrew Whang wrote: > > Hi, > >

Re: Gossip 2.0

He denied it when I asked him that earlier. But we know he did. http://wilderness.apache.org/channels/?f=cassandra-dev/2016-09-01#1472732219 > On Sep 1, 2016, at 11:02 AM, Eric Evans

Re: #cassandra-dev IRC logging

Also just to make sure, this is logging for #cassandra-dev not #cassandra right? -Jeremiah > On Aug 30, 2016, at 3:11 PM, Jeff Jirsa wrote: > > http://wilderness.apache.org/channels/ > > > > On 8/30/16, 1:04 PM, "Jonathan

Re: Proposal - 3.5.1

I’m with Jeff on this, 3.7 (bug fixes on 3.6) has already been released with the fix. Since the fix applies cleanly anyone is free to put it on top of 3.5 on their own if they like, but I see no reason to put out a 3.5.1 right now and confuse people further. -Jeremiah > On Sep 15, 2016, at

Re: Proposal - 3.5.1

~$100k it would cost my organization to validate 3.7 prior to >>> upgrading, and I don’t think it’s reasonable to ask users to recompile a >>> release for a ~10 line fix for a very nasty bug. >>> >>> I’m also very strongly recommend we (committers/PMC

Re: Proprietary Replication Strategies: Cassandra Driver Support

What kind of support are you thinking of? All drivers should support them already, drivers shouldn’t care about replication strategy except when trying to do token aware routing. But since anyone can make a custom replication strategy, drivers that do token aware routing just need to handle

Re: sstableloader from java

Yes using the SSTableLoader class. You can see the CqlBulkRecordWriter class for an example of writing out sstables to disk and then using the SSTableLoader class to stream them to a cluster. -Jeremiah > On Sep 21, 2016, at 7:18 PM, Paul Weiss wrote: > > Hi, > > Is

Re: Github pull requests

+1 for PR’s but if we start using them I think we should get them sent to commits@ instead of the dev@ they are currently sent to. -Jeremiah > On Aug 26, 2016, at 1:38 PM, Andres de la Peña wrote: > > +1 to GitHub PRs, I think it will make things easier. > > El

Re: Proposal - 3.5.1

My thinking was we keep doing tick/tock for the 4.x. Basically continue on for 4.0.x / 4.x like we have been with 3.0.x / 3.x, just with some added guidance to people that 4.x is “development releases”. The main problem I hear with the tick tock stuff is that we won’t ever have “LTS” branches

Re: Low hanging fruit crew

Unless the reviewer reviews the for content, then you don’t know if they do or not. -Jeremiah > On Oct 19, 2016, at 10:52 AM, Jonathan Haddad wrote: > > Shouldn't the tests test the code for correctness? > > On Wed, Oct 19, 2016 at 8:34 AM Jonathan Ellis

Re: Proposals for releases - 4.0 and beyond

I think the monthly releases are important, otherwise releases become an “event”. The monthly releases mean they are just a normal thing that happens. So I like any of 3/4/5. Sylvain's proposal sounds interesting to me. My only concern would be with making sure we label things very clearly

Re: [jira] [Commented] (CASSANDRA-12490) Add sequence distribution type to cassandra stress

I would guess Jake replied to the JIRA message that was sent to commits@ expected the reply to end up going back to the ticket (which happens if you reply to something JIRA sends directly to you because you watched the ticket), but instead went to dev@ because the emails sent to commits@ from

Re: Collecting slow queries

Per the Fix Version on the ticket it is going to be in 3.10 when that is released. Probably in the next week provided we don’t find any more show stopper bugs. -Jeremiah > On Dec 6, 2016, at 10:38 AM, Jan wrote: > > Hello Yoshi-san; > is this fix rolled into

Re: CASSANDRA-9472 Reintroduce off heap memtables - patch to 3.0

> On Jul 31, 2017, at 12:17 PM, Jeff Jirsa wrote: > On 2017-07-29 10:02 (-0700), Jay Zhuang wrote: >> Should we consider back-porting it to 3.0 for the community? I think >> this is a performance regression instead of new feature. And we have

Re: Integrating vendor-specific code and developing plugins

> On May 15, 2017, at 6:57 PM, 大平怜 wrote: > > Thanks for the discussion, all, > >>> * What's included when shipped in tree? >>> >>> Does every idea get merged in? Do we need 30 different Seed providers? Who >>> judges what's valuable enough to add? Who maintains it

Re: Potential block issue for 3.0.13: schema version id mismatch while upgrading

If 3.0.13 causes schema mismatch on upgrade, then maybe we should pull that and release 3.0.14 once 13559 is fixed. As that is a pretty bad place to get into. > On May 30, 2017, at 6:39 PM, Jay Zhuang wrote: > > Seems the mail is marked as spam. So try forwarding with another

Re: Is concurrent_batchlog_writes option used/implemented?

The project hosted docs can be found here: http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html If you find something wrong in those open a JIRA. DataStax has a documentation feedback

Re: Compact Storage and SuperColumn Tables in 4.0/trunk

I think that all the work to support Compact Storage tables from CQL seems like wasted effort if we are going to tell people “just kidding, you have to migrate all your data”. I do not think supporting “COMPACT STORAGE” as a table option matters one way or the other. But I do think being able

Re: [VOTE] Release Apache Cassandra 3.11.1

Jeff, TL;DR 3.11.0 shows it for them as well. See https://issues.apache.org/jira/browse/CASSANDRA-13900 for the rest of the story. -Jeremiah > On Oct 2, 2017, at 4:47 PM, Jeff Jirsa wrote: > > Thomas, did you see

Re: Proposal to retroactively mark materialized views experimental

e sitting >>>> there in the base code but forbidden from version xxx onward. >>>> >>>> Since when do we start removing feature in a patch release ? >> (forbidding >>> to >>>> create new MV == removing t

Re: Proposal to retroactively mark materialized views experimental

Hindsight is 20/20. For 8099 this is the reason we cut the 2.2 release before 8099 got merged. But moving forward with where we are now, if we are going to start adding some experimental flags to things, then I would definitely put SASI on this list as well. For both SASI and MV I don’t know

Re: Proposal to retroactively mark materialized views experimental

. > > — > AY > > On 2 October 2017 at 18:18:52, Jeremiah D Jordan (jeremiah.jor...@gmail.com) > wrote: > > These things are live on clusters right now, and I would not want someone to > upgrade their cluster to a new *patch* release and suddenly someth

Re: Proposal to retroactively mark materialized views experimental

So for some perspective here, how do users who do not get the guarantees of MV’s implement this on their own? They used logged batches. Pseudo CQL here, but you should get the picture: If they don’t ever update data, they do it like so, and it is pretty safe: BEGIN BATCH INSERT tablea blah

Re: V5 as a protocol beta version in 3.11

My 2 cents. When we added V5 to 3.x wasn’t it added as a beta protocol for tick/tock stuff and known that when a new version came out it would most possibly break the older releases V5 beta stuff? Or at the very least add new things to V5. So I see no reason to need to add more new features

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

The community of people doing python development and the community of people running Cassandra servers are not the same. I am not fine riding the coat tails of libraries used in python development. As others have stated we need to be following the lead of the OS vendors that people will be

Re: URGENT: CASSANDRA-14092 causes Data Loss

If you aren’t getting an error, then I agree, that is very bad. Looking at the 3.0 code it looks like the assertion checking for overflow was dropped somewhere along the way, I had only been looking into 2.1 where you get an assertion error that fails the query. -Jeremiah > On Jan 25, 2018,

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

I don’t think we need to stop the vote. This CVE has been around for a while (3/13/2017), and does affect any install I have ever seen. It affects users who manually enable some specific logback features using the SocketServer or ServerSocketReceiver component which are not used in our

Re: CASSANDRA-14183 review request -> logback upgrade to fix CVE

s/does affect/does not affect/ > On Feb 13, 2018, at 11:57 AM, Jeremiah D Jordan <jeremiah.jor...@gmail.com> > wrote: > > I don’t think we need to stop the vote. This CVE has been around for a while > (3/13/2017), and does affect any install I have ever seen. It affects

Re: Expensive metrics?

re: nanoTime vs currentTimeMillis there is a good blog post here about the timing of both and how your choice of Linux clock source can drastically effect the speed of the calls, and also showing that in general on linux there is no perf improvement for one over the other.

Re: GitHub PR ticket spam

Oh nice. I like the idea of keeping it but moving it to the worklog tab. +1 on that from me. > On Aug 6, 2018, at 5:34 AM, Stefan Podkowinski wrote: > > +1 for worklog option > > Here's an example ticket from Arrow, where they seem to be using the > same approach: >

Re: Proposing an Apache Cassandra Management process

Not sure why the two things being in the same repo means they need the same release process. You can always do interim releases of the management artifact between server releases, or even have completely decoupled releases. -Jeremiah > On Aug 17, 2018, at 10:52 AM, Blake Eggleston wrote: >

Re: Side Car New Repo vs not

I think the following is a very big plus of it being in tree: >> * Faster iteration speed in general. For example when we need to add a >> new >> JMX endpoint that the sidecar needs, or change something from JMX to a >> virtual table (e.g. for repair, or monitoring) we can do all changes >>

Re: Evolving the client protocol

The protocol does already support optional/custom payloads to do such things. IIRC the zipkin tracing implementation https://github.com/thelastpickle/cassandra-zipkin-tracing for example uses this to pass the zipkin id to the server. > On Apr 20, 2018, at 1:02 PM, Max C.

Re: Debug logging enabled by default since 2.2

People seem hung up on DEBUG here. The goal of CASSANDRA-10241 was to clean up the system.log so that it a very high “signal” in terms of what was logged to it synchronously, but without reducing the ability of the logs to allow people to solve problems and perform post mortem analysis of

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

> Stefan's elastic search link is rather interesting. Looks like they are > compiling for both a LTS version as well as the current OpenJDK. They > assume some of their users will stick to a LTS version and some will run > the current version of OpenJDK. > > While it's extra work to add JDK

Re: Paying off tech debt and correctly naming things

+1 if you are willing to take it on. As the person who performed the Table->Keyspace rename of 2.0, I say good luck! From hindsight of doing that, as others suggested, I would come at this in multiple tickets. I would suggest a simple class rename with intellij refactoring tools or something

Re: Deprecating/removing PropertyFileSnitch?

As long as we are correctly storing such things in the system tables and reading them out of the system tables when we do not have the information from gossip yet, it should not be a problem. (As far as I know GPFS does this, but I have not done extensive code diving or testing to make sure all

Re: Deprecating/removing PropertyFileSnitch?

view of this host will be wrong. >>>>>>> >>>>>>> Won't this happen even with PropertyFileSnitch as the token(s) for >> this >>>>>>> host will be missing from gossip/system.peers? >>>>>>> >>>>>>> Em

Re: Deprecating/removing PropertyFileSnitch?

hli wrote: > > No worries...I mentioned the issue not the JIRA number > >> On Oct 22, 2018, at 8:01 PM, Jeremiah D Jordan wrote: >> >> Sorry, maybe my spam filter got them or something, but I have never seen a >> JIRA number mentioned in the thread before thi

Re: Moving tickets out of 4.0 post freeze

So as to not confuse people, even if we never put out a 4.1, I think we should keep it 4.0.x, in line with 2.2.x, 3.0.x, 3.11.x. And yes our .. versioning of the past never followed semver. -Jeremiah > On Sep 24, 2018, at 11:45 AM, Benedict Elliott Smith > wrote: > > I’d like to propose we

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

+1 But I also think getting this through incubation might take a while/be impossible given how large the contributor list looks… > On Sep 12, 2018, at 10:22 AM, Jeff Jirsa wrote: > > +1 > > (Incubation looks like it may be challenging to get acceptance from all > existing contributors,

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

No, doesn’t change it. Any code donation has to go through the incubation process, which is where all the legal stuff about it being donated is handled. This would be like the dtest repo which was donated a little while back, and followed this same process. -Jeremiah > On Sep 12, 2018, at

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

ugmenting the scope of a project makes it >>>>> better: >>>>>> I feel >>>>>> keeping this project focused on the core server is better. I see >> risks >>>>>> here, but >>>>>> the upsides haven't been made v

Re: UDF

Be careful when pulling in source files from the DataStax Java Driver (or anywhere) to make sure and respect its Apache License, Version 2.0 and keep all Copyright's etc with said files. -Jeremiah > On Sep 11, 2018, at 12:29 PM, Jeff Jirsa wrote: > > +1 as well. > > On Tue, Sep 11, 2018 at

Re: Audit logging to tables.

AFAIK the Full Query Logging binary format was already made more general in order to support using that format for the audit logging. -Jeremiah > On Mar 1, 2019, at 11:38 AM, Joshua McKenzie wrote: > > Is there a world in which a general purpose, side-channel file storage > format for

Re: [Discuss] num_tokens default in Cassandra 4.0

+1 for 8 + algorithm assignment being the default. Why do we have to assume random assignment? If someone turns off algorithm assignment they are changing away from defaults, so they should also adjust the num tokens. -Jeremiah > On Feb 18, 2020, at 1:44 AM, Mick Semb Wever wrote: > > -1 >

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

I think as long as we don’t publish the artifacts to maven central or some other location that is for “anyone” we do not need a formal release. Even then since the artifact is only meant for use by people developing C* that might be fine. If artifacts are only for use by individuals actively

Re: [DISCUSS] CASSANDRA-13994

+1 strongly agree. If we aren’t going to let something go into 4.0.0 because it would "invalidate testing” then we can not let such a thing go into 4.0.1 unless we plan to re-do said testing for the patch release. > On May 27, 2020, at 1:31 PM, Benedict Elliott Smith > wrote: > > I'm being

Re: [DISCUSS] CASSANDRA-13994

mostly a way of saying: >> – I like the cadence/sequencing Benedict proposes below. >> – I think improvements in test engineering can reduce/eliminate >> invalidation and may increase the scope of what can be a candidate for >> merge on a given branch >> – And if not, the

Re: [DISCUSS] Future of MVs

> So from my PoV, I'm against us just voting to deprecate and remove without > going into more depth into the current state of things and what options are > on the table, since people will continue to build MV's at the client level > which, in theory, should have worse correctness and performance

Re: [VOTE] Project governance wiki doc

I think we need to assume positive intent here. If someone says they will participate then we need to assume they are true to their word. While the concerns are not un-founded, I think the doc as is gives a good starting point for trying this out without being too complicated. If this turns

Re: [VOTE] Project governance wiki doc

+1 non-binding. Thanks for the work on this! > On Jun 16, 2020, at 11:31 AM, Jeff Jirsa wrote: > > +1 (pmc, binding) > > > On Tue, Jun 16, 2020 at 9:19 AM Joshua McKenzie > wrote: > >> Added unratified draft to the wiki here: >> >>

Re: Welcome Jordan West, David Capwell, Zhao Yang and Ekaterina Dimitrova as Cassandra committers

Congratulations everyone! Good to see the project getting new committers. > On Dec 16, 2020, at 10:55 AM, Benjamin Lerer > wrote: > > The PMC's members are pleased to announce that Jordan West, David Capwell, > Zhao Yang and Ekaterina Dimitrova have accepted the invitations to become >

Re: [DISCUSS] Releases after 4.0

I think we are confusing things between minor vs patch. Can we talk about branch names? I think we can agree on the following statements? Releases made from stable maintenance branches, cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit features being added to them and

Re: [DISCUSSION] Should we mark DROP COMPACT STORAGE as experimental

We had many discussions around this back when this was added. There is a transition ability in place. Users can set a native protocol flag to have the server return results as if DROP COMPACT STORAGE was already run. In this way you can update your applications to support the new way results

Re: [DISCUSS] Semantic versioning after 4.0

+1 for doing this (or something similar). It will give more clarity to downstream users about the compatibility of a given release. -Jeremiah > On Apr 30, 2021, at 12:45 PM, Mick Semb Wever wrote: > > *** Proposal *** > Aligned to the agreed-upon annual cadence of supported releases, let's >

Re: [DISCUSS] CASSANDRA-15234

> Also, if you run the above command you will see we actually have a lot of > things show (129 lines)… it would be nice to clean it up as only a small > subset is required and most shown normal users won’t care +1 for this. It would be good to clean up the config code and yaml such that only

Re: [DISCUSS] CASSANDRA-16922 CEP-10: Major Prerequisites (Phase 1)

> As these progress through review, the aim is to roll them up into a single > branch and merge that to trunk together, keeping the separate commits for the > specific JIRAs. I think this is a great idea. Where do you see the “Roll Up Branch” living? Does the project want to start keeping

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

I tend to agree with Paulo that a major refactoring of some internal interfaces sounds like something to be explicitly avoided in a patch release. I thought this was the type of change we all agreed we should stop letting in to patch releases, and that we would attempt to release more often

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

Too many nots. I do not think fixing 12126 is a new feature. > On Jul 13, 2021, at 8:40 AM, Jeremiah D Jordan wrote: > > I do not think fixing CASSANDRA-12126 is not a new feature. I do think > adding the ability to do “Cluster and Code Simulations” is a new feature. &g

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

only would it be burdensome (given the divergences in > the codebase), but I would not consider it acceptably safe (given the > divergence). > > > From: Jeremiah D Jordan > Date: Tuesday, 13 July 2021 at 14:15 > To: Cassandra DEV > Subject: Re: [DISCUSS] CEP-10: Clust

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

duces the highest quality outcome. > > > > > From: Jeremiah D Jordan > Date: Tuesday, 13 July 2021 at 14:41 > To: Cassandra DEV > Subject: Re: [DISCUSS] CEP-10: Cluster and Code Simulations > I do not think fixing CASSANDRA-12126 is not a new feature. I do think > a

Re: Cassandra CI Systems confluence page

+1 from me. There is a lot of good info on that page, no need to keep it draft that I can see. > On Aug 9, 2021, at 1:00 AM, Mick Semb Wever wrote: > > Any objections if this confluence page comes out of draft? > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=153815764 > >

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> On Nov 14, 2021, at 3:53 PM, Stefan Miklosovic > wrote: > > Hey, > > there are two points we are not completely sure about. > > The first one is streaming. If there is a cluster of 5 nodes, each > node has its own unique encryption key. Hence, if a SSTable is stored > on a disk with the

Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection

If it is per query, then I would think protocol level might be easier to “test” a given application with. Rather than having to append "WITH ADDITIONAL LATENCY” to all your queries, you just set some option in your query based object or such. We already have support at the protocol level for

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> On Nov 15, 2021, at 2:25 PM, Stefan Miklosovic > wrote: > > On Mon, 15 Nov 2021 at 19:42, Jeremiah D Jordan > mailto:jeremiah.jor...@gmail.com>> wrote: >> >> >> >>> On Nov 14, 2021, at 3:53 PM, Stefan Miklosovic >>&g

Re: [DISCUSS] CEP-18: Improving Modularity

their own right. > > I air all this just to contribute perspective to the discussion; all that > said, I think refactoring APIs as a pure reflection of what the DB is doing > today just risks ossifying something that grew up organically and probably > isn't going to do us any favors, so havin

Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17056)

We already have many interfaces similar to these for Compaction Strategy, Indexing, Query Handler. I would hope that commiters are already following a policy along the lines of trunk -> anything goes, not trunk -> try not to change these interfaces. I would expect that to be the same policy

Re: [DISCUSS] CEP-17: SSTable format API (CASSANDRA-17056)

ould be as simple as an annotation like >> @ExposedTo3rdParties (Hadoop does this to show an interface is exposed and >> must be maintained), or it could be something like split directories >> (src/java = private, src/java-exposed = public); I am trying not to dictate >

Re: [DISCUSS] CEP-18: Improving Modularity

, 2021, at 1:22 PM, Jeremiah D Jordan wrote: >> >> The currently proposed changes in CEP-18 should all include improved test >> coverage of the modules in question. We have been developing them all with >> a requirement that all changes have at least %80 code coverage

Re: [DISCUSS] CEP-18: Improving Modularity

As Henrik said we have been refactoring access to these different internal APIs as part of some larger work. For this CEP we pulled together a bunch of the smaller ones into one place, similar to the refactoring proposed in CEP-10, as we felt doing many small CEPs, one per module, would be

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

If we want to have “called out development snapshots” then I think we need some way to distinguish build from those commits the from ongoing work in the version number that is in the build file. I do not think the “development snapshots” being 4.1.0-SNAPSHOT and current trunk also being

Re: [DISCUSS] Periodic snapshot publishing with minor version bumps

stuff. > On Dec 16, 2021, at 10:29 AM, Jeremiah D Jordan > wrote: > > If we want to have “called out development snapshots” then I think we need > some way to distinguish build from those commits the from ongoing work in the > version number that is in the build fil

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

+1 from me for the proposal ignoring the "where it goes". I think the refactors proposed in it make sense no matter what, and the simulation ability should provide some very much needed testability improvements. In particular replacing File with Path is something we have been looking to do

Re: [DISCUSS] CEP-11: Pluggable memtable implementations

+1 from me. I like the direction many of these proposals are going to clean up/add internal interfaces along with the new features proposed. -Jeremiah > On Jul 20, 2021, at 1:27 PM, bened...@apache.org wrote: > > I think it would be a mistake to combine the Memtable with CommitLog; several >

Re: [DISCUSS] Diagnostic events in virtual tables

Yes, I think it would make sense to have the events available in a virtual table, especially if we are trying to move our operational management in that direction. But, why does it need to be bin log or virtual tables? Why not both? The virtual tables could even return the data stored in the

Re: [VOTE] Formalizing our CI process

+1 nb > On Jan 10, 2022, at 1:00 PM, Joshua McKenzie wrote: > > Wiki draft article here: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 > > > The vote will be open for 72 hours (it's

Re: [VOTE] Formalizing our CI process

I agree with Scott’s sentiments. If we are keeping a green CI then an urgent release with green CI should not be hard. In the worst case you do the “urgent” release as a single commit fix on top of the previous release tag, not by cutting the current dev branch, in that case you should easily

Re: [DISCUSS] Next release cut

I agree with Josh here. If we can’t be adding things that pass review up until the moment we decide to cut the release it means people are not following our stated goals/process for suitability for merge. If that is the case then we should work to fix that, not add arbitrary soft freeze

Re: [DISCUSS] CASSANDRA-17292 Move cassandra.yaml toward a nested structure around major database concepts

I don’t really care much about what the actual structure ends up being. My main suggestion would be that we do not do anything “incremental” here. I think that would just cause more confusion to have some properties using a new format and some using the current format. There should be some

Re: [DISCUSS] CEP-7 Storage Attached Index

mparison. >>>>>>>>> >>>>>>>>> As long as prefix BTree supports range/prefix aggregation (which is >>>>>>> used >>>>>>>> to >>>>>>>>> speed up >>>>>>>>

Re: Is removal of dead code bug or feature?

As has been previously discussed, the project does not actually define what internal things are meant to be public apis, and what are not. So that is one more reason to consider removal of un-used functions an improvement / not for patch releases. Some third party plugin, for custom indexes,

Re: [VOTE] Release Apache Cassandra 4.0.2

-1 nb So we just voted on an approved the CI process page recently: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530280 Where we said: "All releases by default are expected to have a green test

Re: [VOTE] Release Apache Cassandra 3.0.26

-1 nb for same reason as I said for the 4.0.2 vote here: https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr > On Feb 8, 2022, at 6:15 AM, Mick

Re: [VOTE] Release Apache Cassandra 3.11.12

-1 nb for same reason as I said for the 4.0.2 vote here: https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr > On Feb 8, 2022, at 4:10 AM, Dorian ROSSE wrote: > > Hello Scott, > > > Yours links should work but

Re: [DISCUSS] CEP-19: Trie memtable implementation

I don’t really see most users touching the default implementation. I would expect the main reason someone would change would be 1. They run into some bug that is only in one of the implementations. 2. They have persistent memory and so want to use

  1   2   >