+1 “This thread was not about sacrificing stability. It is a pity that it came across like that.“
On Mon, 29 Jun 2020 at 13:35, Stefan Miklosovic < stefan.mikloso...@instaclustr.com> wrote: > 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 > >
