[stycznik]

>it is inevitable that at some point there was and will be a need to push a new feature into a stable release for the purpose of data recovery

It's really not, the proper way to recover your important data is to restore from backups, not to force other people to bend longstanding rules for you.

>Do you really want to live in a world where data losses in stable releases is considered Okay?

Bcachefs is an experimental filesystem.

[bcrl]

Experimental does not mean "should be blocked from receiving timely updates" last I checked.

[stycznik]

If it really was so urgent why didn't Kent just tell people to get those updates from his personal tree? There are rules in place if you want your stuff to get into Linus's tree, expecting Linus to pull whatever you sent him without any resistance whatsoever is likely just going to end up with him deleting your project, just like what happened here.

[bcrl]

Because distributions don't ship Kent's kernel tree, and they're not going to. Distributions like Fedora ship as close to mainline as possible these days because of the pain experienced from shipping a heavily patched kernel in the past. Release cycles are upwards of 3 months for Linus' tree. With that kind of lengthy release cycle, for an experimental codebase which is undergoing rapid stabilization it was the right call: you don't want old code to linger around longer than necessary when they're predominantly bug fixes that successfully pass regression tests. The choice should be with the maintainer.

[solarkraft]

Now they don’t ship bcachefs at all. Seems like a weird trade to me, but hey, no version is being shipped without recovery features now, huh.

[akimbostrawman]

Experimental means assume your data could disappear at anytime.

There is no reason to break kernel guidelines to deliver a fix.