RC Means Release Candidate, Not Remix Continues

Dad joke first, RC means Release Candidate, not Remix Continues, if you keep piping new features onto a cake while it is cooling you do not get extra frosting, you get a slide, Kent kept decorating during RCs, Linus said stop and actually enforced it, so bcachefs moves out of tree and into DKMS, where your distro and your patience become the build farm, SUSE is turning it off starting in 6.17, Arch will probably ship the DKMS module because of course it will, inode what you did there.

So what is actually happening, Kent is aiming high, a modern filesystem with ZFS or Btrfs grade features without the bulk, plus performance you can brag about to friends who pretend to care, that ambition is good, the timing is not, RC windows exist to stabilize and fix, not to sneak in surprises, he kept proposing and landing features anyway, and real users started reporting corruption and data loss, there is no quicker way to hit a bright line in kernel land, Linus said no, then made no stick, result, bcachefs is now externally maintained, which is the polite way to say out of tree, and every sharp edge is now yours to sand.

Treating an RC like add a feature hour is like swapping brake pads at a yellow light, it sounds bold, it mostly ends with you coasting into a mailbox, the kernel runs on the rule that RC time is for regression hunting and hardening, not for story points, when that line gets crossed the aftershocks bounce into other subsystems, other maintainers spend their RCs triaging churn they did not cause, morale drops, and the release cadence gets wobbly for everyone.

Meanwhile, the packaging dominoes are doing what they do, SUSE is disabling bcachefs in 6.17, Arch will likely pick up the DKMS module because Arch gonna Arch, the label externally maintained sounds tidy, the practical meaning is you carry the risk, your kernel updates, your module must rebuild against whatever changed underneath, it usually works until it does not, then your Tuesday turns into a storage forensics seminar while your boss asks why the dashboard is red.

Why you should care even if ext4 is your emotional support filesystem, mainline buys you integration, broad test coverage, and fixes that move together across subsystems, you benefit from other people’s bug hunts without filing a ticket, DKMS buys you flexibility, the code lives and compiles on your machine, which is handy for tinkerers and early adopters, it is also fragile, one minor kernel bump, one compiler quirk, one symbol rename, and you are debugging a storage stack instead of doing finance or sequencing or literally anything else, if you tinker for fun that is a weekend, if those disks hold payroll or lab data or the only copy of a first birthday, that is not a hobby, that is a risk, and no, fsck around and find out is not a disaster recovery plan.

Here is how you tell who is doing the work versus staging a demo, Kent keeps speed and control, fewer gatekeepers, quicker merges, which feels amazing when you are soloing, Linus keeps kernel discipline, which protects everyone else’s RCs from turning into firefights, distros split on how much they want to babysit the edge, users pay now with extra setup and choppier updates, vendors pay later if they ship it then take support calls when a kernel outruns a DKMS release, reliability first, accountability second, new features third, broken backups do not care how excited you were.

About failure, it rarely shows up with sirens, filesystems drift, then tip, you notice when scrub starts complaining or mounts get flaky, if bcachefs locks the on disk format and widens tests, DKMS becomes a manageable nuisance you can schedule around, if not, the pain lands on people who believed production ready and learn otherwise by restoring from backups they never actually tested, which is a rough classroom, and yes you need to practice your restore, not just admire your backup job’s green checkmarks, run it end to end and write down how long it took, that number is your real risk, not the marketing page.

Where that leaves you, if you already run bcachefs and you are happy, pin your kernel or plan for DKMS rebuilds, keep backups you have restored at least once, watch the issue tracker closely, double that if fresh corruption reports pop up, if you are choosing today, be deliberate, do you want feature velocity or the calm that comes with in tree conservatism, both choices can be reasonable right up until they are not, which is why grown up engineering puts guardrails first, then speed, you will thank yourself later when upgrade day lands on a deadline week and you need boring, not surprise.

One last bit before crayons, process rules are not fussy for sport, they are how we keep promises to users, same rules for everyone, same safety for everyone, skip that during RCs and people who just updated end up holding the bag, which brings us to the unglamorous checklist you already know, backups you have proven, upgrades on a schedule you control, a willingness to walk away from shiny when your data would be the price of admission, and yes, a sarcastic aside mid sentence, you know, like this one, to remind you that discipline is the boring superpower, it feels like overcooking pasta until you remember al dente snaps under load, then it tastes like wisdom, bon, ship smart and go pet your backups, they have feelings too.

--Doc (yeah I said it!)
find me anywhere under @DocAtCDI