Here is a user's perspective from someone who's built a career from Linux (thanks to all of you)... The big hardship with testing bcachefs before it was merged into the kernel was that it couldn't be built as an out-of-tree module and instead a whole other kernel tree needed to be built. That was a pain. Now, the core kernel infrastructure changes that bcachefs relies on are in the kernel and bcachefs can very easily and quickly be built as an out-of-tree module in just a few seconds. I submit to all involved that maybe that's the best way to go **for now**. Switching to out of tree for now would make it much easier for Kent to have the fast-paced development model he desires for this stage in bcachefs' development. It would also make using and testing bcachefs much easier for power users like me because when an issue is detected we could get a fix or new feature much faster than having to wait for a distribution to ship the next kernel version and with less ancillary risk than building and using a less-tested kernel tree. Distributions themselves also are very familiar with packaging up out-of-tree modules and distribution tools like dkms make using them dead simple even for casual users. The way things are now isn't great for me as a Linux power user. I often want to use the latest or even RC kernels on my systems to get some new hardware support or other feature and I'm used to being able to do that without too many problems. But recently I've had to skip cutting-edge kernel versions that I otherwise wanted to try because there have been issues in bcachefs that I didn't want to have to face or work around. Switching to an out of tree module for now would be the best of all worlds for me because I could pick and choose which combination of kernel / bcachefs to use for each system and situation. Just my 2¢. Carl > On 2024-10-05 5:14 PM PDT Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > On Sat, 5 Oct 2024 at 16:41, Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > > If what you want is patches appearing on the list, I'm not unwilling to > > make that change. > > I want you to WORK WITH OTHERS. Including me - which means working > with the rules and processes we have in place. > > Making the argument that we didn't have those rules twenty years ago > is just stupid. We have them NOW, because we learnt better. You don't > get to say "look, you didn't have rules 20 years ago, so why should I > have them now?" > > Patches appearing on the list is not some kind of sufficient thing. > It's the absolute minimal requirement. The fact that absolutely *NONE* > of the patches in your pull request showed up when I searched just > means that you clearly didn't even attempt to have others involved > (ok, I probably only searched for half of them and then I gave up in > disgust). > > We literally had a bcachefs build failure last week. It showed up > pretty much immediately after I pulled your tree. And because you sent > in the bcachefs "fixes" with the bug the day before I cut rc1, we > ended up with a broken rc1. > > And hey, mistakes happen. But when the *SAME* absolute disregard for > testing happens the very next weekend, do you really expect me to be > happy about it? > > It's this complete disregard for anybody else that I find problematic. > You don't even try to get other developers involved, or follow > upstream rules. > > And then you don't seem to even understand why I then complain. > > In fact, you in the next email say: > > > If you're so convinced you know best, I invite you to start writing your > > own filesystem. Go for it. > > Not at all. I'm not interested in creating another bcachefs. > > I'm contemplating just removing bcachefs entirely from the mainline > tree. Because you show again and again that you have no interest in > trying to make mainline work. > > You can do it out of mainline. You did it for a decade, and that > didn't cause problems. I thought it would be better if it finally got > mainlined, but by all your actions you seem to really want to just > play in your own sandbox and not involve anybody else. > > So if this is just your project and nobody else is expected to > participate, and you don't care about the fact that you break the > mainline build, why the hell did you want to be in the mainline tree > in the first place? > > Linus
