On Mon, Jul 07, 2025 at 04:03:27PM -0400, John Stoffel wrote: > If those users are not prepared to accept the risk of an experimental > filesystem, then screw them! They're idiots and should be treated as > such. No, that's not the attitude of a responsible filesystem developer. It doesn't matter what stage of development the code is in, if it's got users and they're hitting bugs, those bugs take priority. "Screw the user" is no way to develop a filesystem that people will actually want to run. If we want to attain rock solid, bulletproof reliability, then reliability, top to bottom, has to be the priority at every stage of development. The job is not done until it is working well and verified for everyone. > > Shipping a project as large and complex as a filesystem must be done > > incrementally, in stages where we're deploying to gradually increasing > > numbers of users, fixing everything they find and assessing where we're > > at before opening it up to more users. > > Yes! But that process also has to include rollbacks, which git has > made so so so easy. Just accept that _if_ 6.x-rc[12345] is buggy, > then it needs to be rolled back and subbmitted to 6.x+1-rc1 for the > next cycle after it's been baked. I'm very quick to kick out buggy patches; simple regressions where a revert is the correct solution almost never hit Linus's tree. This isn't the issue we're talking about. > > Right now we need to be getting those fixes out to users so > > they can keep testing and finding the next bug. When someone has > > invested time and effort learning how the system works and how to > > report bugs, we don't watn them getting frustrated and leaving - we > > want to work with them, so they can keep testing and finding new > > bugs. > > So post patches on your own tree that they can use, nothing stops you! That is indeed what it comes down to, isn't it? I support my code. I triage every bug report, prioritizing the critical bugs, and I spend most of my day working with users to track bugs down and make sure the fixes work. That's my job. If fixes aren't going into Linus's tree, that means the working, supported bcachefs tree is no longer his tree, it's mine. We've been down that road with other subsystems in the past (e.g. Lustre), and it doesn't work. Going down that road means the first thing I have to do with every bug report is ask "which tree are you running? stock mainline or mine?" - and then we might as well go all the way and go the DKMS route, for the sake of everyone's sanity.
