This is an update on the development of Flirt. Make sure to read the announcement post before this one, otherwise it won't make sense: Announcing Development on Flirt. According to the roadmap, my goal for December and January was:

Develop a reasonably detailed specification of the feature set, taking care to support a broad variety of backends while keeping the user experience across backends consistent. Implement this feature set for the "Git native" backend.

I have mostly achieved this goal, although the native backend is unfortunately not yet feature-complete. The basic mechanism of storing, sending and receiving review information via a Git remote is working though. Let's get into it!

I've started working on Flirt, which stands for "Fabulous, Legendary, Incremental Review Tool". Firstly, what is it and why might you be interested in it?

• It avoids the need to review the same code multiple times when the code author amends or rebases their commits. This is relevant for people who value good commit history and see it as something to be iterated on during code review.

• It's agnostic with respect to the code sharing / code review platform. That means: You can jump between open-source projects using GitHub, a mailing list etc. and your code review experience stays consistent.

• It's a local-first tool, so it integrates seamlessly with your other tools. Using your editor to read, test and comment on code you review is a breeze.

If any of those points tickle your neurons, keep reading!

I recently got into Linux kernel development by rewriting a driver from C to Rust. To support this driver, I needed to add Rust abstractions for kernel APIs written in C. Some of this work is making its way upstream and now seems like a good time to write about that experience.

Because I was a noob when I started (and mostly still am), this post should be pretty approachable for people who don't have any kernel development experience.

Spoiler alert: Writing the code was the easy part!