kenneth: could you please send your jira information? i'm unable to even find an account on http://issues.apache.org with your name despite multiple attempts. thanks!
best, kjellman > On Feb 21, 2018, at 2:20 PM, Kenneth Brotman <kenbrot...@yahoo.com.INVALID> > wrote: > > Jon, > > Very sorry that you don't see the value of the time I'm taking for this. I > don't have demands; I do have a stern warning and I'm right Jon. Please be > very careful not to mischaracterized my words Jon. > > You suggest I put things in JIRA's, then seem to suggest that I'd be lucky if > anyone looked at it and did anything. That's what I figured too. > > I don't appreciate the hostility. You will understand more fully in the next > post where I'm coming from. Try to keep the conversation civilized. I'm > trying or at least so you understand I think what I'm doing is saving your > gig and mine. I really like a lot of people is this group. > > I've come to a preliminary assessment on things. Soon the cloud will clear > or I'll be gone. Don't worry. I'm a very peaceful person and like you I am > driven by real important projects that I feel compelled to work on for the > good of others. I don't have time for people to hand hold a database and I > can't get stuck with my projects on the wrong stuff. > > Kenneth Brotman > > > -----Original Message----- > From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon Haddad > Sent: Wednesday, February 21, 2018 12:44 PM > To: u...@cassandra.apache.org > Cc: dev@cassandra.apache.org > Subject: Re: Cassandra Needs to Grow Up by Version Five! > > 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 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org >
