On Mon, 29 Jun 2020 at 16:50, Jon Haddad <j...@jonhaddad.com> wrote: > > > I have been against the freeze from day one. In my opinion it had a > negative impact on the project. > > I'm curious how you're measuring this. Based on my time as an evangelist > at DataStax and as a consultant with the Last Pickle, I can say I rarely > talked to people looking for shiny new features. Most of the time they > wanted the features we've shipped for years to actually work. The storage > engine for *years* didn't work correctly. Some features still don't, like > MVs, incremental repair and SASI. We have a reputation for shipping broken > features, being unstable, and generally being a DB you shouldn't actually > count on.
This is my _personal_ opinion as well. Don't take me wrong, I am really appreciating a lot of work which went to Cassandra over the years, all hats down, but when it comes to it, for example, MV views are "better not to use, man", secondary indexes are "do not overuse it, you know what ... just dont use it", now transient replication will be "you know what, this is quite experimental and some corner cases will never be supported", sasi and incremental repairs - yeah it works "but", etc etc. So what I am finding myself in is a lot of buts and ifs and howevers and one realizes that the best way to use Cassandra is just to use simple straightforward scenarios. "Always on" for most teams is marketing speak - it's difficult > to defend when someone's cluster goes into a death spiral because they ran > a "nodetool repair", or is using row cache, or creates an MV because they > were hyped up as part of a release [1]. Five years later, still so > horribly broken that they are all but guaranteed to not work if you have a > non trivial amount of data and we had to mark them as experimental > post-release. There's a list here [1] for reference, in case anyone wants > a refresher. > > The trunk freeze has gone on for a while, it's the result of recklessly > merging in untested features with very little consideration for scale. > What's happening now couldn't be avoided, because the alternative is people > just don't use the DB anymore. > > > For Cassandra to grow we need both new features/improvements and > stability. > > People won't use the shiny new features if they don't trust the DB, and > right now they don't trust it. Had we unfrozen trunk a year ago, we just > would have shipped another super buggy .0 release and kept our reputation > going. > > Once we've proven we can actually ship a working database, new features > sound great to me. > > [1] https://tinyurl.com/30seriousissues > [2] > https://www.datastax.com/blog/2015/06/new-cassandra-30-materialized-views > [3] https://www.postgresql.org/docs/9.1/tutorial-window.html > > > On Mon, Jun 29, 2020 at 5:28 AM Benjamin Lerer <benjamin.le...@datastax.com> > wrote: > > > > > > > If this is in response to my email, you misunderstand me. > > > > > > > Sorry, that was not a response. > > Increasing stability was mentioned a lot in that thread. I am all for it. I > > just wanted to raise the issue that the plan for that is not clear at least > > for me. > > > > That is not to say there should not be agreed minimum deliverables, but > > > they should be readily achievable in that time-frame. > > > > > > > I am totally in favor of determining what the deliverables should be. > > > > I am pointing to the implied signals about an organisation's priorities and > > > values that are communicated by its actions. > > > > > > > I believe that we should try to assume that everybody has positive > > intentions. :-) > > I have been against the freeze from day one. In my opinion it had a > > negative impact on the project. Now it is just a personal feeling and it > > does not mean that I am not all in favor of delivering a product of better > > quality. > > I have spent most of my first 2 years working on C* writing test for the > > CQL code and that paid off in the long term as it seems that we do not have > > too many bugs in that area. > > For Cassandra to grow we need both new features/improvements and stability. > > It is natural that some people push a bit more towards new > > features\improvements and others towards stability. > > I would be worried if everybody wanted to go in the same direction. > > > > On Mon, Jun 29, 2020 at 12:22 PM Benedict Elliott Smith < > > bened...@apache.org> > > wrote: > > > > > If this is in response to my email, you misunderstand me. There are > > > distinct issues at play. To respond directly to the issue you raise: I > > am > > > personally inclined to pursue a release of 4.0 within some time-box - say > > > 3-6 months. We have already done a huge amount to improve the quality of > > > the project since 3.x. That is not to say there should not be agreed > > > minimum deliverables, but they should be readily achievable in that > > > time-frame. We can soon be confident of the highest quality .0 release > > to > > > date in the project, even if we have not delivered all that we originally > > > hoped on the quality assurance front. > > > > > > However, I am looking forward to the way the project delivers 5.0, and > > > whether we will continue to improve. I am pointing to the implied > > signals > > > about an organisation's priorities and values that are communicated by > > its > > > actions. These signals are read by actors both internal and external to > > > the organisation, and shape their actions in turn. If there is a > > > disconnect between the implied and expressed priorities, this leads to > > > tensions; usually to the detriment of the expressed priorities, since > > > actions speak louder than words. > > > > > > > > > On 29/06/2020, 10:10, "Benjamin Lerer" <benjamin.le...@datastax.com> > > > wrote: > > > > > > I believe that we all need to see 4.0.0 being released. We have been > > > frozen > > > for too long in my opinions and some people simply believe that the > > > project > > > is dead. That is hurting us. > > > > > > That does not mean that I am not in favor of making that release as > > > stable > > > as possible. > > > What we miss in my opinion is a clear target and some metrics. When > > > will we > > > know that we can release 4.0? How are we measuring its quality? > > > If we cannot provide some answers to those questions we can end up > > > spending > > > our life searching for bugs and 4.0 will never be released. > > > > > > Maybe there is a clear plan in the mind of some of you guys. It is > > > just not > > > the case for me. So chances are that I am not the only one in this > > > case. > > > > > > The 4.0 Beta is nearly there, more than ever we need a clear testing > > > plan > > > that will lead us to releasing 4.0. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 28, 2020 at 12:07 AM Benedict Elliott Smith < > > > bened...@apache.org> > > > wrote: > > > > > > > > Just a heads up - this comes across as passive aggressive > > sniping. > > > I'm > > > > sure you didn't mean it as such > > > > > > > > I think indirect criticism is a normal part of discourse, > > > particularly in > > > > public fora where it can be more polite and less disruptive than > > > direct > > > > criticism. Ironically, this snippet of yours seem (to me) to be > > more > > > > readily ascribed your epithet; which is fine, of course, and > > > pleasingly > > > > meta. > > > > > > > > > very little has publically materialized on the project to this > > > point > > > > that I know of > > > > > > > > I think you are wrong, here. Firstly, you overlook recent work > > such > > > as > > > > (but not limited to): FQL, cassandra-diff, in-jvm dtests; also the > > > steady > > > > drip of dozens of critical bugs found, and the work to fix those > > > bugs. It > > > > is perhaps unfair to label "very little" work that has spanned > > > several > > > > years and uncovered perhaps the majority of serious correctness > > bugs. > > > > > > > > Secondly, there is an important distinction to draw, between QA > > > projects > > > > that are in progress but not yet published, and an absence of such > > > > projects. We might also note feature development endeavours that > > > have been > > > > initiated, and whether work aims to improve quality or expand > > > > functionality. I look forward to seeing the balance of investments > > > shift > > > > to match stated priorities in the near future. > > > > > > > > > > > > > > > > On 27/06/2020, 03:10, "Joshua McKenzie" <jmcken...@apache.org> > > > wrote: > > > > > > > > > > > > > > I've seen a lot of talk from some quarters of a new approach > > to > > > > quality, > > > > > but so far there have been few contributions from the same > > > quarters > > > > > > > > > Just a heads up - this comes across as passive aggressive > > > sniping. I'm > > > > sure > > > > you didn't mean it as such but it does read that way (at least > > > to me). > > > > > > > > When it comes to quality, much like you said in another thread > > > > Benedict I > > > > think we all need to be honest with ourselves. There's been a > > > lot of > > > > talk > > > > from *all* quarters but outside a lot of expression of intent > > > across > > > > many > > > > fronts (verbal, ML, JIRA, slack), very little has publically > > > > materialized > > > > on the project to this point that I know of. > > > > > > > > I cleared out assignees on 40_quality_testing tickets earlier > > > this week > > > > (overloading shepherds in this field was a mistake IMO - that's > > > on me) > > > > which has clarified for some contributors that they can take > > > that work > > > > on. > > > > There's still considerable uncertainty as to what the scope is > > > for > > > > those > > > > tickets and nobody really replied to Jordan pinging shepherds > > for > > > > clarification a long while ago. > > > > > > > > > > > > > > > > On Fri, Jun 26, 2020 at 8:44 PM Dinesh Joshi < > > djo...@apache.org> > > > > wrote: > > > > > > > > > > On Jun 26, 2020, at 3:45 PM, David Capwell < > > > dcapw...@gmail.com> > > > > wrote: > > > > > > > > > > > > the ability to test their impact. Even simple things > > become > > > hard > > > > given > > > > > the > > > > > > fact only committers can run Jenkins tests, or you pay > > money > > > to be > > > > able > > > > > to > > > > > > run the tests... If the intent is to make it easier for > > new > > > > people to > > > > > > contribute to the project, shouldn't the focus be on fixing > > > their > > > > pain > > > > > > points such as testing? > > > > > > > > > > +1 on not branching and keeping focus on testing and fixing > > > 4.0. > > > > > > > > > > I am sorry about the situation for non-committers. I tried > > > reaching > > > > out to > > > > > legal and infra in the past without a great response. If > > > someone in > > > > the > > > > > community has a way to reach out and get clarity on problems > > > > affecting our > > > > > contributors, it would be great. Otherwise, I will try to bug > > > them > > > > again. > > > > > > > > > > Dinesh > > > > > > > > --------------------------------------------------------------------- > > > > > 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 > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > 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
