Ken, Maybe it’s not clear how open source projects work, so let me try to explain. There’s a bunch of us who either get paid by someone or volunteer on our free time. The folks that get paid, (yay!) usually take direction on what the priorities are, and work on projects that directly affect our jobs. That means that someone needs to care enough about the features you want to work on them, if you’re not going to do it yourself.
Now as others have said already, please put your list of demands in JIRA, if someone is interested, they will work on it. You may need to contribute a little more than you’ve done already, be prepared to get involved if you actually want to to see something get done. Perhaps learning a little more about Cassandra’s internals and the people involved will reveal some of the design decisions and priorities of the project. Third, you seem to be a little obsessed with market share. While market share is fun to talk about, *most* of us that are working on and contributing to Cassandra do so because it does actually solve a problem we have, and solves it reasonably well. If some magic open source DB appears out of no where and does everything you want Cassandra to, and is bug free, keeps your data consistent, automatically does backups, comes with really nice cert management, ad hoc querying, amazing materialized views that are perfect, no caveats to secondary indexes, and somehow still gives you linear scalability without any mental overhead whatsoever then sure, people might start using it. And that’s actually OK, because if that happens we’ll all be incredibly pumped out of our minds because we won’t have to work as hard. If on the slim chance that doesn’t manifest, those of us that use Cassandra and are part of the community will keep working on the things we care about, iterating, and improving things. Maybe someone will even take a look at your JIRA issues. Further filling the mailing list with your grievances will likely not help you progress towards your goal of a Cassandra that’s easier to use, so I encourage you to try to be a little more productive and try to help rather than just complain, which is not constructive. I did a quick search for your name on the mailing list, and I’ve seen very little from you, so to everyone’s who’s been around for a while and trying to help you it looks like you’re just some random dude asking for people to work for free on the things you’re asking for, without offering anything back in return. Jon > On Feb 21, 2018, at 11:56 AM, Kenneth Brotman <kenbrot...@yahoo.com.INVALID> > wrote: > > Josh, > > To say nothing is indifference. If you care about your community, sometimes > don't you have to bring up a subject even though you know it's also > temporarily adding some discomfort? > > As to opening a JIRA, I've got a very specific topic to try in mind now. An > easy one I'll work on and then announce. Someone else will have to do the > coding. A year from now I would probably just knock it out to make sure it's > as easy as I expect it to be but to be honest, as I've been saying, I'm not > set up to do that right now. I've barely looked at any Cassandra code; for > one; everyone on this list probably codes more than I do, secondly; and > lastly, it's a good one for someone that wants an easy one to start with: > vNodes. I've already seen too many people seeking assistance with the vNode > setting. > > And you can expect as others have been mentioning that there should be > similar ones on compaction, repair and backup. > > Microsoft knows poor usability gives them an easy market to take over. And > they make it easy to switch. > > Beginning at 4:17 in the video, it says the following: > > "You don't need to worry about replica sets, quorum or read repair. > You can focus on writing correct application logic." > > At 4:42, it says: > "Hopefully this gives you a quick idea of how seamlessly you can bring > your existing Cassandra applications to Azure Cosmos DB. No code changes are > required. It works with your favorite Cassandra tools and drivers including > for example native Cassandra driver for Spark. And it takes seconds to get > going, and it's elastically and globally scalable." > > More to come, > > Kenneth Brotman > > -----Original Message----- > From: Josh McKenzie [mailto:jmcken...@apache.org] > Sent: Wednesday, February 21, 2018 8:28 AM > To: dev@cassandra.apache.org > Cc: User > Subject: Re: Cassandra Needs to Grow Up by Version Five! > > There's a disheartening amount of "here's where Cassandra is bad, and here's > what it needs to do for me for free" happening in this thread. > > This is open-source software. Everyone is *strongly encouraged* to submit a > patch to move the needle on *any* of these things being complained about in > this thread. > > For the Apache Way <https://www.apache.org/foundation/governance/> to work, > people need to step up and meaningfully contribute to a project to scratch > their own itch instead of just waiting for a random corporation-subsidized > engineer to happen to have interests that align with them and contribute that > to the project. > > Beating a dead horse for things everyone on the project knows are serious > pain points is not productive. > > On Wed, Feb 21, 2018 at 5:45 AM, Oleksandr Shulgin < > oleksandr.shul...@zalando.de> wrote: > >> On Mon, Feb 19, 2018 at 10:01 AM, Kenneth Brotman < >> kenbrot...@yahoo.com.invalid> wrote: >> >>> >>>>> Cluster wide management should be a big theme in any next major >> release. >>>>> >>>> Na. Stability and testing should be a big theme in the next major >> release. >>>> >>> >>> Double Na on that one Jeff. I think you have a concern there about >>> the need to test sufficiently to ensure the stability of the next >>> major release. That makes perfect sense.- for every release, >>> especially the major ones. Continuous improvement is not a phase of >>> development for example. CI should be in everything, in every >>> phase. Stability and testing a part of every release not just one. >>> A major release should be >> a >>> nice step from the previous major release though. >>> >> >> I guess what Jeff refers to is the tick-tock release cycle experiment, >> which has proven to be a complete disaster by popular opinion. >> >> There's also the "materialized views" feature which failed to >> materialize in the end (pun intended) and had to be declared >> experimental retroactively. >> >> Another prominent example is incremental repair which was introduced >> as the default option in 2.2 and now is not recommended to use because >> of so many corner cases where it can fail. So again experimental as an >> afterthought. >> >> Not to mention that even if you are aware of the default incremental >> and go with full repair instead, you're still up for a sad surprise: >> anti-compaction will be triggered despite the "full" repair. Because >> anti-compaction is only disabled in case of sub-range repair (don't >> ask why), so you need to use something advanced like Reaper if you >> want to avoid that. I don't think you'll ever find this in the >> documentation. >> >> Honestly, for an eventually-consistent system like Cassandra >> anti-entropy repair is one of the most important pieces to get right. >> And Cassandra fails really badly on that one: the feature is not >> really well designed, poorly implemented and under-documented. >> >> In a summary, IMO, Cassandra is a poor implementation of some good ideas. >> It is a collection of hacks, not features. They sometimes play >> together accidentally, and rarely by design. >> >> Regards, >> -- >> Alex >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
