On 02.07.25 19:53, Kent Overstreet wrote: > On Wed, Jul 02, 2025 at 10:41:34AM -0700, Carl E. Thompson wrote: >> Kent, at this point in bcachefs' development you want complete control >> over your development processes and timetable that you simply can't >> get in the mainline kernel. It's in your own best interest for you to >> develop out-of-tree for now. > Carl, all I'm doing is stating up front what it's going to take to get > this done right. > > I'm not particularly pushing one way or the other for bcachefs to stay > in; there are pros and cons either way. It'll be disruptive for it to be > out, but if the alternative is disrupting process too much and driving > Linus and I completely completely nuts, that's ok. > > Everyone please be patient. This is a 10+ year process, no one thing is > make or break. > So as a user usually hanging out on IRC and running Kent's trees: I think most of those people actually testing bcachefs are either running bcachefs-master, -rc or some outdated distro kernel. From my perspective I'd think it would be good enough to push for-upstream during the merge window and then only provide further patches if there where regressions or some really bad bug appears that actually eats data (like the one that bit me). If it's "just" stability fixes, well, if people running a distro kernel hit those bugs they'll need to build a -rc kernel anyways to get fixes, those could just build bcachefs-master. When running Linus' tree I am aware and accept that I am not running the absolutely latest code. I've had some pretty bad experience with amdgpu requiring out of tree patches to get my system running free of glitches, which took months to get into upstream. It's annoying, but I accept that. I'd rather have a slightly outdated bcachefs in kernel than not at all. It is good to have a distro kernel I can fall back to if I mess up my own kernel building ;) my 0.02€ /Malte
