It's been a long time since I sent out a status update. Let's round up 2024,
and let's see if we can't have more regular updates in 2025 shall we?
First, some vanity metrics on the year in review:
Community Health and Activity:
- Tickets created: 840
- Tickets fixed: 518
- Tickets created in 2024 and closed: 463
- Commits to trunk: 343 (excluding merge commits)
- `git diff --stat` against 1st commit in 2024: 1549 files changed, 77170
insertions(+), 28184 deletions(-)
- 42 unique committers committed to the project (compared with 47 in both 2022
and 2023), with our top 4 being:
- Stefan Miklosovic at 172 commits
- Brandon Williams at 117
- Mick Semb Wever at 98
- Caleb Rackliffe at 63
Releases:
- 4.0 line: 4 releases
- 4.1 line: 4 releases
- 5.0 line: 3 releases
We deprecated the 3.0 and 3.X line, which was a *huge* improvement in QoL for
merging patches for all of us.
Email:
- 230 topics on the dev@ list
- 122 topics on the user@ list
Slack:
- 1949 members in #cassandra on the-asf.slack.com
- 869 members in #cassandra-dev on the-asf.slack.com
We've had a solid year for progress, engagement, discussion, and diversity when
it comes to the project.
---------------------------------------------------------------------------------------------
So that's the Ghost of Cassandra Past. What about the present?
First off, as always, how can you get involved if you're looking to contribute?
Follow this link:
https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2162&quickFilter=2160&quickFilter=2652
This will give you a list of all the relatively low complexity tickets that
currently lack an assignee.
You can find us on the ASF slack: https://the-asf.slack.com, in #cassandra-dev
for dev discussion and #cassandra for user discussion. If you need an invite to
the slack server, let me know and I'll get you setup.
For the code, let's look at the present workflow on trunk / our next major:
- https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484
I've updated our project release kanban board to be aligned with the current
branches and workflows. Of note, just over 50% of the work flagged as in flight
on the project is on trunk. I went ahead and bumped the 4 in "Awaiting
Feedback" back to Triage since they were sitting for months to years at a time
and contributor questions on the tickets had been answered.
*We currently have 35 tickets on trunk that need review*; any committers with
some spare cycles, your help there would be greatly appreciated; I'll try and
kick out another email for us to [DISCUSS] this as it's a longstanding struggle
for us. I don't have longitudinal data for the past year or two on this metric,
but having 90 tickets project-wide, 35 on trunk, that are blocked waiting on
review feels high to me.
We have 11 tickets project-wide that are in "Needs Committer" state, 8 of which
are on trunk.
All in all, things feel like they're in a pretty healthy balanced spot heading
into the last stretch of the holiday season.
---------------------------------------------------------------------------------------------
That's the present. What about the Future? Let's take a look from a "next major
release perspective."
We released 5.0 GA on September 5th, 2024. If we target a release 12 months
after the prior went GA, that would put our new target at early September 2025
for 6.0. If we plan to cut a branch 8 weeks prior to that (did we ever
formalize this?), that would mean we're coming up on a frozen / stabilizing
release branch cut target of July 5th, 2025. 6 months, or 29 weeks, or 208
calendar days, or 149 working days (M-F) between now and then. Which honestly?
That's a decent amount of time for us all to keep chugging away, especially
given how much is already in trunk:
- We currently have 121 new features and improvements unique to trunk.
- We currently have 217 bugfixes unique to the branch as well.
So the future looks bright and busy. And not yet too chaotic from a calendar
perspective. Yet.
---------------------------------------------------------------------------------------------
*[Key mailing list discussions]:*
Been a long time since we did one of these so I'm going to hand pick some
highlights of what's in flight.
- Paulo Motta kicked off a discussion about our default compaction strategy,
immediately making it clear that compaction is Complicated and picking defaults
is Hard: https://lists.apache.org/thread/kny0csz4wr9vm5owh0m0pt39qjdx4x6v. This
kicked off a separate discussion about:
- How do we handle experimental flagging? Is it time to evolve it?
https://lists.apache.org/thread/9ptpkd3yymy5wok137c5jytysw373v52. That thread
appears to be narrowing down on a consensus with some stress testing of ideas
sneaking in at the end there. Please chime in if you're interested and have
some experience or opinions you'd like to share to the Stone Soup of our
process.
- Jon Haddad with admirable brevity opened up the thread "[DISCUSS] 5.1 should
be 6.0": https://lists.apache.org/thread/5vxk2mh1rt1r07yt5mqjm6nqgp16c48x. He's
giving me ideas on click-baiting my email subjects in the future, but that
aside, that thread also appears to be converging as well. If you have a +1, a
-1, or anything in between to add to the discussion please chime in.
- After doing incredible work with and for the community, Melissa Logan and the
team at Constantia are stepping back from running meetups for Cassandra and
have a call out to ask for help from volunteers to keep it going:
https://lists.apache.org/thread/pft9ynl1vclxo68hmdgn8optlnp2ld0w. If this is
something you're interested in, please speak up! As geographically spread out
as we are as a community, these opportunities to get together and see each
others' faces and talk about what we're doing as well as connecting with our
users are super valuable.
- Branimir is clearly as disgruntled with our javadoccing as everyone else but
he's uniquely willing to start a conversation about alternatives (/clap).
Markdown-based commenting in our code anyone?
https://lists.apache.org/thread/trgyoo7vfdws1r0mthdtpzxdrc0nrsdk. I've had a
dangling item on a todo list to try and generate javadocs for our project
for... months? years? at this point, so I'm personally in favor of a more
unified less hideous approach to commenting our code. We can't do an "ant
javadoc" style build target until JDK23, but that's just more incentive for us
to keep updating our support and moving forward right?
- The last thing I want to call out is Jaydeep Chovatia reaching out about the
idea of external tooling to support anti-entropy and correctness validation for
Materialized Views:
https://lists.apache.org/thread/qwkcjxgg4g3x042g8vq6j2tt91dh54jh. Given how
that feature intersects with the "how do we lifecycle features", plus how
complex and fraught the topic of the architecture of MV's has been for us, this
is an interesting one and I'm personally glad to see energy going into
considering what next steps for MV's might best be. And not just because I
reviewed that ticket back in the day. :disappear:
---------------------------------------------------------------------------------------------
That'll do for now; don't want to overextend ourselves on the status email
front. Like I said, I'm going to make it a point to try and get back on the
wagon with these with your first monthly update coming end of January.
As always, thanks everyone for the code you write, the discussions you engage
in, and the professionalism, candor, and open-mindedness you bring to the table
that make this project possible.
Happy 2024 everyone and I hope you all have a safe and lovely holiday season.
~Josh
