Regarding the dynamic snitch improvements, it's gone through several rounds of review already and there's been significant testing of it. Regarding the token change, switching a number from 256 -> 16 isn't so invasive that we shouldn't do it. There's a little extra work that needs to be done there ideally to ensure safety, but it's again small enough where it shouldn't be too big of a problem imo. Both current implementations (256 tokens + our insanely over memory allocating dynamic snitch) limit the ability of people to run large clusters, harming both availability and performance. It's been extremely harmful for Cassandra's reputation and I'd really like it if we could ship something where I don't have to constantly apologize to people I'm trying to help for the land mine defaults we put out there.
To your point, I agree as a community we're lacking in an open, well documented and up to date plan, and it needs to be addressed. I think the virtual meetings idea held at a regular might help a bit with that, I intend on participating there. On Wed, Aug 28, 2019 at 9:52 AM Joshua McKenzie <jmcken...@apache.org> wrote: > > > > dynamic snitch improvements, fixing token counts > > > > > they're small enough > > > By what axis of measurement out of curiosity? Risk to re-test and validate > a final artifact? Do we have a more clear understanding of what testing has > taken place across the community? > > The last I saw, our documented test plan > < > https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans > > > hasn't > been maintained or kept up to date > < > https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA > >. > Is there another artifact reflecting what testing people have in flight to > better reflect what risk of needing to re-test we have from these (and > other) post-freeze changes? > > > > On Wed, Aug 28, 2019 at 11:52 AM Jon Haddad <j...@jonhaddad.com> wrote: > > > Hey folks, > > > > I think it's time we cut a 4.0 alpha release. Before I put up a vote > > thread, is there a reason not to have a 4.0 alpha before ApacheCon / > > Cassandra Summit? > > > > There's a handful of small issues that I should be done for 4.0 (client > > list in virtual tables, dynamic snitch improvements, fixing token > counts), > > I'm not trying to suggest we don't include them, but they're small > enough I > > think it's OK to merge them in following the first alpha. > > > > Jon > > >