I would second Jon in the arguments he made. Contributing outside work is draining and really requires a lot of commitment. If someone requires features around usability etc, just pay for it, period.
On Wed, 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: user@cassandra.apache.org > Cc: d...@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: d...@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 > > -- Akash
