Trying really hard to do this as close to weekly as possible, but it's been pretty quiet and I've been pretty busy.
A few things to note: 1) Sylvain opened a JIRA ( https://issues.apache.org/jira/browse/CASSANDRA-13910) about deprecating (dclocal_)read_repair_chance (the probabilistic async read repair that you probably don't need anyway, because hints and blocking read repair are probably doing it for you anyway). Related to that, Aleksey made a comment on CASSANDRA-10726 (a patch to allow foreground/mismatch read repair inserts not to be blocking): https://issues.apache.org/jira/browse/CASSANDRA-10726?focusedCommentId=16219254&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16219254 "The question I asked myself was: what kind of tuning do we want for read repair, once those two are gone? And I'm leaning towards these three settings: 1. Perform blocking RR (current default, left default) 2. Write hints instead of sending RR mutations, and let hint delivery repair the inconsistency, in a manner decoupled from the original read request 3. Do nothing, for those who rely on regular repair for one reason or another (thinking TWCS, DTCS users?) Any opinions?" So, any opinions? 2) Static Analysis stuff: - Malcolm Taylor sent over a patch that fixed a bunch of alerts from lgtm.com ( https://issues.apache.org/jira/browse/CASSANDRA-13799 ). - There are still plenty left to fix, if anyone wants some low hanging java issues ( https://lgtm.com/projects/g/apache/cassandra/alerts/?mode=tree&severity=error ), in particular stuff like using a hashed value without implementing hashCode() is probably a genuine bug ( https://lgtm.com/projects/g/apache/cassandra/alerts/?mode=tree&severity=error&rule=2980070 ), but it may be interesting for the project to develop some sort of process to check this regularly. - There's a team at Oregon State that's working on some static tooling to detect unnecessary boxing caused by lambdas, and they've been running their tool against our codebase ( https://github.com/apache/cassandra/pull/116 , https://github.com/apache/cassandra/pull/131 ). The newest one ( https://github.com/apache/cassandra/pull/168 / https://issues.apache.org/jira/browse/CASSANDRA-13982 ) is up and needs a reviewer (diff is generated by automated tool, it looks fine to me at first glance; one of the fixes appears to be in the hot path on reads, so that's pretty cool). 3) 4.0 changelog is ~150+ items - https://github.com/apache/cassandra/blob/trunk/CHANGES.txt. Most of them are bugfixes, I think, but I bet none of us knows for certain. Any interest in actually labelling CHANGES entries with FIX/FEATURE/DOC ? Too much boilerplate for too little ROI? Or worthwhile? - Jeff
