koverstreet

The kernel doesn't have any kind of coherent testing strategy. That was a big part of the problem, because that means the subsystems that do test their code, like bcachefs, get stuck picking up the slack for the subsystems that don't.

I was spending a lot of my time just doing QA for the rest of the kernel.

You seem to just be painfully misinformed - or you're outright trolling.

People keep saying it takes 10 years, but that presupposes methods that never improve. Why would we keep doing the same thing over and over again? Wouldn't be much point in that.

If you want to be a filesystem maintainer, you start out by doing the work involved.

I'm afraid not all opinions are created equal, this isn't design by committee :)

There's always one of two of you rabble going "You dared defy the kernel community! You dared defy Linus! Rabble rabble rabble!"

Meanwhile, I no longer have to stress about whether I'll be about to get bugfixes out, actual users seem happy and my life is far better :)

It's hard to show with any accuracy how likely a filesystem is to not break when the SHTF or something weird happens, or if they've handled all the weird corner cases, with any kind of automated test.

For that you have to dig into the methodology, look at the code, look at user reports, etc.

But you can get a pretty good approximation just from the philosophies and attitudes of the engineers and what they're talking about.

The talk I just gave at the Rust for Linux conference was all about that - how do we make the system debugable, the community aspect of how we respond to bug reports and talk to users, the prep work for the Rust conversion and formal verification and how we're approaching all that.

Reliability doesn't come out of nowhere, "all bugs are shallow with enough eyeballs" really doesn't apply to filesystems. You just have to plan for it, come up with a methodology, and do the work.

Within the last year? I think bcachefs is going to be overtaking btrfs soon on active developers, from the trends I saw in the commit logs

Uhh, do you know what the upstream stance is on testing and fixing bugs?

I doubt there'd be any real interest in a bastardized fork that only exists so the deep pocketed vendors can get away with code dump and run.

Yes, has been for awhile

NixOS thoroughly solves all the external module fragility. They also do distro level CI testing.

No urgency over fixing bugs? What do you think this is, btrfs? :)

All this has been discussed to death, we don't need people armchair quarterbacking a year later. It's over, it's time to move on.

bcachefs on Arch is a bit better supported, we have the distro package maintainer in the bcachefs IRC channel, and I've never lagged on mainline support like ZFS has.

Actual distro support, and doing it right with people actually communicating with each other, has always been a priority for the project.

I think the Phoronix test suite does pretty well for the end user who wants something easy to digest; the exact choice of benchmarks is sometimes odd but the harness itself is quite good.

At some point I'd like to get our own automated pts runs going, since Michael is not consistent with what hardware he tests on and he hasn't been consistent with getting them out.

If you have "refine until it's perfect and don't screw with things you don't understand" thoroughly ingrained, along with the dangers of overconfidence, you'll do fine with AI.

Not everyone gets it though, that's for sure.

And, if you want to know if it's mature, I'd trust the user reports over the one liners :)

NixOS. You can't go wrong.

Speaking as someone who consumes this, I appreciate how it's laid out. As a developer, we can often see at a glance where the bottleneck is if we have enough data laid out - IOW, data overload for you is me feeling like a kid in a candy store.

Sometimes there are ways to make things easier without dumbing them down, but way too many people conflate the two; I get nervous when non engineers say "I've studied this, it should be easy".