Trying out a monthly-ish cadence as traffic over the holiday season was a bit sparse. Let's see how this goes.
Congratulations to Patrick McFadin on being made a committer on the project! So many of us on the project have benefited from your assistance, input, guidance, and efforts over the years. Well deserved! Some of us have even had the opportunity to have to get physical therapy thanks to you. (≖_≖ ) So that aside, there was the disappointing but understandable news that the Cassandra Summit is being delayed until later in the year, December 12-13 to be exact. See Patrick's email on the topic here: https://lists.apache.org/thread/g4rsqjysn4fqw34z6ro5q6ywml6mnrzd. In lieu of the summit, DataStax is sponsoring a virtual session covering some of what's coming up in Cassandra 5.0 from a variety of participants in the community. See here for details: https://www.cassandrasummit.org/cassandra-forward The world Post-Covid remains unpredictable; it's good to see our community rising to the challenge and driving forward. [New Contributors Getting Started] (Unassigned) (Starter Tickets): this is the set of filters you want to pull from on our project's Kanban board: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2160 There are a _lot_ of these flagged as good starter tickets; focus on the column marked "To Do" on the far left. If any of those catch your fancy, join us in the #cassandra-dev channel on https://the-asf.slack.com (reply to me on this email if you need an invite for your account), and hit up the @cassandra_mentors alias if you need any help getting situated. If there's anything else specifically you're interested in on the project, just hop in the slack channel and let everyone know. [Dev mailing list] Let's see whether this time span is sustainable for a summary: https://lists.apache.org/list?dev@cassandra.apache.org:dfr=2023-1-23|dto=2023-3-2: 46 Topics. This is going to be interesting. Benedict reached out about our contribution guidelines looking for feedback: https://lists.apache.org/thread/v4wn4jh23nv3xpvmrky0zwt2sdbkb5xh. The gdoc with quite a bit of engagement can be found here: https://docs.google.com/document/d/1qt7xmvEAXm_w9ARb2lVutapB_3il2WWEWuq_zYlu_9s/edit#heading=h.it3eez49gg10 Maxim Muzafarov has been doing some interesting work around building a framework to keep our VTables and JMX params in sync and make maintenance lower effort: https://lists.apache.org/thread/26j9hhy39okw0wy79mtylb753w6xjclg. Some more about the progression of this work can be found in this thread here: https://lists.apache.org/thread/8kywzv24n0dp07mhvch7hwhjypssoh0l and on this jira: https://issues.apache.org/jira/browse/CASSANDRA-15254. The discussion surrounding review of long-lived feature branches continued (CEP-15 prompted the initial discussion): https://lists.apache.org/thread/rotjm3dr36mbx24wbflkt35g7z7wz7ks. This prompted a follow up discussion about how we want to manage long-lived feature branches: https://lists.apache.org/thread/c39yrbdszgz9s34vr17wpjdhv6h2oo61. While we didn't hit a formal (or informal) consensus on the topic, Henrik did summarize both his position and many of the conversation points succintly and I think it's worth reiterating here: "Basically what you want to avoid is to paint yourself into a corner, and particularly the wrong corner. So the way I would answer this question is that large bodies of work should: - Refactoring that is a) harmless, and/or b) improves the codebase anyway, should be merged early into trunk. - The main body of the new functionality should be developed in a feature branch up until some kind of MVP stage. This means that by the time it is proposed for merge, a) it has been tested to both be of good quality and that it actually provides the benefit it set out to implement. This means that merging it to trunk will be a net improvement, always. - After that first big MVP merge, additional functionality of course could be developed directly against trunk. - For patches that are very clean and self contained, for example in their own Java package, it doesn't really matter, because they are easy to roll back if needed. They can be developed against trunk." As my partner has told me for years "Very little is black and white in this world. The right answer is nuanced and somewhere in the middle". I think if we keep taking this on a case-by-case basis and try and be proactive when we think we might be doing something where we might disrupt others, we'll be good. Lorina reached out about a documentation plan for C* 5.0: https://lists.apache.org/thread/on116v3thbqjhp001z1ovko2kdf97z6n. The gdoc with this work can be found here: https://docs.google.com/document/d/1FAACcAxtV9qLJS05RLt85S_6Gb4C4t4g9DhmfLufjOk/edit#heading=h.f2d8nyksbd13. Stefan Miklosovic opened up a discussion about how we want to handle ALLOW FILTERING on VTables: https://lists.apache.org/thread/104fld746d6qtggq5132n3hqtjqqpkjp. The work that fell out from that was tracked and completed here: https://issues.apache.org/jira/browse/CASSANDRA-18238 Marianne Lyne Manaog let everyone know about a public repository with Fallout performance testing tools and results: https://lists.apache.org/thread/yc1z8qn7cxlc5xlrymb4mz1119f6cbzk. The repo with the first 6 performance tests they've worked on can be found here: https://github.com/datastax/fallout-tests. Maxim Muzafarov is fighting the good fight on our management and handling of system properties: https://lists.apache.org/thread/wxvqozhjs7dq50scgf1p4d8ht16dqoct. The vote for CEP-21 (transactional metadata) passed with flying colors: https://lists.apache.org/thread/0lk0yll0mkd7858hqndqjgcyz3bgxkoz. Exciting to see this work progressing! David worked on some subproject integration into our build system, specifically driven by the need for better integration of Accord to avoid some of the pain we've faced with the in-jvm dtests. The email thread can be found here: https://lists.apache.org/thread/tscsl95dl1twdfs43pqjx1plk81q39l7, and the submodule for Accord was added as part of https://issues.apache.org/jira/browse/CASSANDRA-18204. A discussion popped up about how we handle sstable format changes; when we make those changes, in what versions, how we strive to avoid breaking backwards compatibility when possible, and how we potentially facilitate downgradability: https://lists.apache.org/thread/tcp339k5ph8ql35wxr085to4qgp8tpg7. No real conclusion quite yet and the thread's been quiet for a bit over a week. The code for CEP-17: Pluggable SSTable format is close to merge: https://lists.apache.org/thread/pntnthyb0bww99w0d7gmrdp63wx76ytt. See https://issues.apache.org/jira/browse/CASSANDRA-17056 for details on that work that's currently under review. A discussion about our release date for the next major release came up; given the delay on 4.1 until late last year, there's a couple axes here worth considering. See the thread here and engage for more context: https://lists.apache.org/thread/fncbr50xg1otw8xtpyn0b3ys02bfnwv1. No clear consensus yet, however there's an undercurrent of "we need to figure out why 4.1 certification took so long and work to remediate that for the next major release window." Last but _definitely_ not least, Ekaterina's work to support JDK17 continues: https://lists.apache.org/thread/ps5lvp3nxpwzwnpf472v02qyl9kjqybh. The umbrella ticket for this work can be found here: https://issues.apache.org/jira/browse/CASSANDRA-16895. She's looking for assistance with some specific tickets if anyone has some bandwidth: https://issues.apache.org/jira/browse/CASSANDRA-18180, and https://issues.apache.org/jira/browse/CASSANDRA-18263. [Checking in on CI] https://butler.cassandra.apache.org/#/ How did we fare in Feb? 3.0: 13 -> 11 3.11: 13 -> 19 4.0: 4 -> 3 4.1: 6 -> 3 trunk: 12 -> 7 Having active build leads over the past month has made a difference as has the effort people have been investing in this process. It's also pretty clear that 4.0+ is in a better place than the 3.X line. [What's been closed out] Here's a custom quick filter to give us an overview of 30 days: https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2278 4.2 / 5.0: 12 issues: - fixed a comparator problem that prevented nodes from joining the ring: CASSANDRA-18292 - The CustomClassLoader for loading triggers was fixed: CASSANDRA-18264 - Added a test conf for JDK17: CASSANDRA-18258 - Fixed sstabledump for secondary indexes error: CASSANDRA-18254 - Fixed a race in snapshot removal leading to a NoSuchFileException: CASSANDRA-18211 - git submodule for Accord added to the repo: CASSANDRA-18204 - Fixed an AttributeError in multiple tests: CASSANDRA-18198 - build.xml update for JDK 17 support: CASSANDRA-18179 - Handling of min/max clustering in sstable improved: CASSANDRA-18134 - A couple of flaky test fixes - Tidy up diagnostic snapshots on preview repair repair mismatch: CASSANDRA-17561 4.1.x: 2 issues - Update and unify copyright year: CASSANDRA-18261 - Add missing information about whether to drop sstables or not when dropping schema objects: CASSANDRA-17582 3.x: 1 issue: - CQLSH copy defaults appear to be incorrect on website: CASSANDRA-16573 No fixversion (should probably tidy these up...): - Some test fixes - Some Accord fixes Lots of great work on the 4.2/5.0 line, and lots of great discussions on the mailing list. I'll keep an eye on things and if they pick up / continue to be active over the next couple of weeks might do an update mid-month. Thanks as always everyone for the hard work and collaboration on the project! ~Josh
