> > we still produce incorrect results as shown by CASSANDRA-15313; this is a > correctness issue, so must be a blocker for v5 protocol.
That makes complete sense; I'd somehow missed the incorrect results aspect in trying to get context on the work. I'd be eager to hear about progress on it as well. Regarding the question of "why would users test if we haven't tested yet", I respectfully disagree both on the assertion we haven't tested yet as well as on the distinction between an "us vs. them" in the community. We're all users and participants in the Cassandra community and ecosystem so anyone downloading the DB to test it out is just as vital as one of us from the dev list, committer list, or pmc list testing out the DB. While we can reasonably expect a dev paid full time working on the project with a large amount of infrastructure doing testing to be crucial to getting a release out and doing certain kinds of testing, there are literally thousands of different companies out in the world basing their critical infrastructure on this project and them testing out their use-cases and migration is just as critical to this release being ready. It takes a village. Further, we have thousands of tests across all our suites, hundreds of new use-case testing that has been done against 4.0 at this point, and 30+% more bugs fixed in this release than 3.0; the blanket assertion that we haven't tested 4.0 yet doesn't resonate with me. While we haven't done the entirety of our final 40 beta phase testing yet, testing is constantly going on against this codebase by both people on the ML and off. Now, if there are major known glaring issues where we have problems that would prevent users from actually testing out the beta and kicking the tires, that's a different story entirely and I'd argue those tickets should be reflected in the alpha phase (see: CASSANDRA-15299 apparently ;) ) Does that make sense? On Tue, Jun 16, 2020 at 4:58 PM Benedict Elliott Smith <bened...@apache.org> wrote: > So, if it helps matters: I am explicitly -1 the prior version of this work > due to the technical concerns expressed here and on the ticket. So we > either need to revert that patch or incorporate 15299. > > On 16/06/2020, 21:48, "Mick Semb Wever" <m...@apache.org> wrote: > > > > > 2) Alternatively, it's been 3 years, 4 months, 13 days since the > release of > > 3.10.0 (the last time we added new features to the DB) > > > > > We did tick-tock, pushing feature releases too quickly, and without > supporting them for long enough to get stable. And then we've done "a > la no > feature releases" for over 3 years. It feels like the bar went from > too low > to too high. > > I understand the importance of CASSANDRA-15299. But it hasn't had any > comments in 12 twelve days, and in this stage of the feature freeze, > with > so few alpha bugs remaining, that's a long time. Sam, can you speak to > its > eta? > > > > > 4) If we plan on releasing 4.1 six months after the release of 4.0 > (i.e. > > calender scope vs. feature scope - not yet agreed upon but an > option), > > > > I like this. I think it's worth appreciating the different > perspectives of > this community: those involved with private clusters that don't rely on > official releases, versus those involved with the public and other > people's > clusters. The latter group needs those official releases much more, but > this also ties into putting those users more in focus and figuring out > where the bar best sits. This isn't meant to divide, we all care and > voice > for the user, but just to utilise the different strengths brought to > the > table. > > > > If we want 4.0.0 out faster, the biggest gains would be to get the > test > plans written up and get more people working on automated testing. > > > Yes, 110%. Though, as long as this continues to improve, as it has, > does > it need to be a blocker on 4.0? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
