About a month ago, I did a video on this file system that Michael Larabel of Phoronix seems to be absolutely obsessed with
I don't think I've seen a single other person talk about it as much and for as long as he has
Outside of the developer of the project, and you know what? That's great
It's always nice to have a passion, but we're not talking about Michael Larabel today
We are talking about the developer of the project Kent Overstreet the developer of bcachefs
Sometimes people learn after a negative encounter
Sometimes it's the 1st one maybe the 2nd maybe the 5th maybe the 10th, but eventually they learn
other times
People learn what they have to say to get through the current encounter and then don't change anything that got them there
Once again Linus Torvolds is sick of working with this project
This all started with bcachefs fixes for 6.12-rc2
Submitted by Kent Overstreet now to be fair
He made a slight improvement over one of the prior situations
Don't submit a giant patch set during the RC period. This is 18 separate patches across
551 lines of changed code across 20 files
This is a lot more reasonable than some of the unruly patch sets from before on the surface
This all looks aboveboard
Linus Torvolds had a big problem with something he was doing
I'm getting really fed up here Kent these have commit times from last night
Which makes me wonder how much testing they got?
Now to be fair to Kent here
The commit messages are from last night because I polished up commit messages and reordered until last night
I always push smaller fixes up front and fixes that are likely to need rework to the back
The vast majority of those fixes are all two weeks old
Understandable back to Linus and before you start whining again about how you are fixing bugs
Let remind you about the build failures you had on big endian because your patches had gotten zero testing
outside your tree
That was last week and I'm getting the strong feeling that
Absolutely nothing was learnt from the experience now to be fair like we saw the patches weren't actually from last night
What he's referring to here is this interaction right here
Where because of a patch that was not sent upstream beforehand a patch that was clearly not at all tested not even a basic build test
They had a broken version of the kernel into the upstream kernel
I have pulled this referring to the patch set we are currently looking at but I search for a couple of the commit messages on the list and
found
Nothing, okay. I found your pull request which obviously mentioned the first line of the commit message
So the only thing you found is the thing that he's currently looking at which
Obviously is not what he's looking for
He's looking for the commits being sent up to the kernel beforehand so they can have a discussion
Not just sending a patch set out of nowhere
I'm seriously thinking just stopping pulling from you because I simply don't see you improving on your model if you want to have an
Experimental tree you can damn will have one outside the mainline kernel
I've told you before and nothing seems to really make you understand
I was hoping and expecting that bcachefs being mainlined would actually help development
It has not you're still basically the only developer and there's no real sign that will change to be fair
There are other developers on the project
But those are developers that are involved in the project outside the kernel anyway being involved in the kernel
Hasn't really changed anything and you seem to feel like sending me untested stuff that nobody else has ever seen
The day before the next RC release is just fine. You're a smart person
I feel like I've given you enough hints
Why don't you sit back and think about it and let's make it clear you have exactly?
Two choices here choice number one play better with others choice number two
Take your toy and go home
Those are the choices basically learn to work in the kernel or get out of the kernel
And we're not going to accept your patches any longer. Here's the thing
bcachefs might be a great file system and sometime down the line might be what distros default to but right now
That's not the case
It has a niche audience that seems to really like it
But it is a fairly small and niche audience
The main line kernel has survived thus far without bcachefs and it's gonna survive into the future without bcachefs
Removing it whilst it'll be annoying for the people who use it
Won't be the end of the world and you don't get to this point with Linus with just one mistake
It is a mistake that you make over and over and over and over again and not different mistakes
Right if you make a mistake you make a different mistake
Obviously those are different things to learn from but it's the refusal to learn from making the same mistake
Over and over again that makes this happen. Now, let's see Kent's response. This bit here is just the PR bot
Let's skip that here. It is this first part. We already looked at let's go past that one
Now referring to the big endian part. No, there simply aren't that many people running a big endian
I have users building and running my trees on a daily basis if I push something broken before I go to bed
I have bug reports waiting for me the next morning when I wake up. I
You I you are you sure about that?
Are you sure about this? Are you sure there's not a single person building on a big Indian system?
that noticed that it wouldn't build
With the change because I think that might be a lie if it is not a lie
What you are saying is you pushed it up to the kernel
before someone had tested the tree which I don't know if it's better to lie or
Push things with zero testing at this point. It's honestly debatable whether the experimental label should apply
I'm getting bug reports that talk about production use and working on metadata dumps where the super block indicates the file system
Has been in continuous use for years and many many people talking about how even at this relatively early point
It doesn't fall over like btrfs does let that sink in
btrfs has been mainline for years and it still craps out on people
I was just in a meeting two days ago closing funding and a big reason
It was an easy sell was because they have to run btrfs in read only mode because otherwise it craps out
So if the existing process the existing way of doing things
Hasn't been able to get btrfs to a point where people can rely on it after 10 years
Perhaps you and the community don't know quite as much as you think you do about the realities of what it takes to ship a working file system
Here's the important thing the goal of the kernel processors
isn't to have something completely bug-free
If btrfs is buggy, I've not heard anyone besides this developer complain about btrfs being terrible
But let's just assume the btrfs is buggy
That's fine because they are following the processors to bring code into the kernel because
Your project btrfs any other project in the kernel is not the only project in the kernel
Linus is dealing with thousands of commits
Every single release if people were just randomly throwing up code with no testing no discussions prior to it being released
How do you manage that the only way you manage this much code is to have strict processors about
Discussions being done beforehand when you can submit code to Linus's tree
What you have to do beforehand because it doesn't work otherwise
And if it is true that bcachefs is being used in production does need update at this really fast rate
That's fine
But that might not be a project that is currently suitable for the kernel
It might be suitable in a couple of years, but it might be too soon right now
I've got a team lined up and just secured funding to start paying them
And it looks like I'm about to secure more and the community is growing
I'm reviewing and taking patches from more people and regularly monitoring them on the code base
And on top of all that you shouting about process rings pretty hollow
When I remember the days when you guys were rewriting core MM code in RC kernels
Given where bcachefs is at the life cycle of a big code base being stabilized
You should be expecting to see stuff like that here stuff is getting found and fixed and then we ship those fixes
So we can find the next stuff having clearly not taking the ultimatum as a serious threat
Linus also decides to clap back in reference to those fixes from earlier being over two weeks old with the patches not appearing in the list
That seems entirely irrelevant
Apparently they are two weeks in your tree and absolutely nowhere else
This is a problem that a lot of the projects see Wayland is a very good example of this where
Discussion is happening
But nobody knows the discussion is happening because it happened at FOSDEM it happened in a matrix room on IRC chat and
Maybe the discussion happened, but nobody on the actual issue track and nobody in the centralized location where discussion should be happening
knows any discussion happened
seriously you
Completely dodged my actual argument
Except for pointing out how we didn't have processes two decades ago if you can't actually even face this
What's the point anymore two decades ago?
You could get away with just letting people do things really nearly and all patches being submitted that are making breaking changes during an RC
It's 2004 we don't know how to run the kernel yet
We do now though we know how to run a really big project like this and you have to have strict
Processes, but do not worry. It only keeps getting better
Here is the next response from Kent if what you want is patches appearing on the list
I'm not unwilling to make that change. This is not a matter of you being willing or not
This is a matter of this is the bare minimum requirement
Everybody else can manage to do it
I take issue and indeed even dig my heels in when the only people asking for that are only yelling about that and aren't involved
Otherwise, it's the kernel
Linus is the most involved in everything. He is the BDFL. It doesn't matter if he doesn't write your code
It's the Linus Torvalds project
But you'll find that if you talk to me as one human being to another where we can share and listen to each other's concerns
I'm more than happy to be reasonable, but I'm not going to just toe the line when it's just yelling
Seriously, remember this is like ten different encounters into him not listening to reasonable issues and
Continuously doing the exact same thing and now he is trying to play the victim
Because the last time you flipped out over a pull request
I spent the rest of the cycle telling people X Y and Z are fixed
But you have to build my tree instead of running a released kernel and that gets tiresome
Some of the bugs were significant and no issues to date have been found in the stuff
You kicked back which tell me my process is just fine
It might be fine for something outside the kernel, but you're not doing something outside the kernel
If you're in the kernel, you have to follow the kernel processes like imagine, right? I don't know
What's what's a what's a good example here? Here we go
Let's say you're sitting an exam and there are specific rules about you know being silent not having notes
Using a specific kind of pencil and you're like hmm. Well, I
Don't actually care about that process. I want to go and have all my notes written out. I want to have a laptop here
I want to blast music and I'm gonna do it with a pen like it doesn't matter what your process is
Your process is an important here
So let that sink in in order to support my user base as well as iterate to find the next set of bugs
I have to be able ship bug fixes in a timely manner
And if that's going to keep being an issue, perhaps I should be having those conversations with district kernels now
Instead of later
I do like how he's trying to act as if he's like ext4 or btrfs
You know file systems that are actually really important where if he did have it removed from the kernel
It would be a giant issue
If you want to do that great because that process seems like it's going to work better for you
This problem is not unique to bcachefs
This is the same problem that every single other kernel developer has to work within
There is a release model for the kernel. There are rules for the kernel
You are not special. You don't get special treatment because your file system is going to save everyone
Face what exactly is at this point? I kind of until what is you want what you're reacting to keeps shifting
That's because you keep doing the same thing and there are multiple issues with what you're doing and you don't change
Any of them and more than that
I'm done with trying to cater and I'm done with these long-winded rants
Look, I quite enjoy the direct approach
But I'm done with having to apologize for you in order to calm people down every time this happens
If you're so convinced you know best, I invite you to start writing your own file system
Go for it. Now if he said that to me fair enough, you know what? I've not written my own file system
I'm just a dude on the internet
Remember there's a conversation with Linus Torvalds, you know the guy that started the Linux kernel the guy that runs the project
Maybe he hasn't written his own file system
But he you know was kind of involved in the whole architecture around the file system to make your file system useful
Just in case you don't realize how stupid this sounds
Let's say you made skateboards during Tony Hawk's prime and Tony Hawk was like hey this skateboard sucks
I don't know anything about skateboards. It sucks for some reason and you say well, you don't know what you're talking about
What did I make in your own skateboard?
Maybe isn't me his own skateboard, but I think he knows what a good skateboard is now Linus remembers that he is the BDFL
He's kind of in charge of the project
So he's not gonna take the bait here. 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 20 years ago is just stupid
We have them now because we learned 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
Okay, I probably only searched for half of them and then I gave up in disgust
We literally had a bcachefs build failure last week
I 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 complain
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?
And you know what that is honestly a really really good question
Don't worry Kent has more to say
This has to work both ways because when I explain my reasoning and processes and it's ignored and the same basic stuff is
Repeatedly yelled back. I'm just going to tune it out
I'm more than happy to work with people, but that's got to be a conversation and one based on mutual respect
It actually doesn't have to be that because you are not the special
Contributor that everyone needs to appease to make the kernel work if you don't have the basic respect
to follow the
kernel processes
Why would anybody ever listen to what you're saying if you want to change the kernel processors?
You don't change it by just breaking the rules
you change it by opening up that discussion and
Laying out the changes you want to see happen if you just break the rules
You're just breaking the rules now referring to the point about the kernel not having processors 20 years ago
That wasn't my argument
My point was that a code base at an earlier phase of development that hasn't had as long to stabilize is
Inherently going to be more in flux early in development fixing bugs is going to be a higher priority
Relatively speaking versus avoiding regressions sometimes the important thing is to make forward progress
iterate and ship and get feedback from users
I think the way you guys were doing development 20 years ago was entirely appropriate at the time and that's what I need to be doing now
I need to be less conservative than the kernel as a whole then why are you mainlined into the kernel?
Why
Those fixes were all pretty basic and broadly speaking I know what everyone else who's been working on bcachefs is doing and what they're working on
It's not a matter of you
knowing what they're working on
Sure, you know what they're working on but the kernel upstream has no idea what they're working on
I do apologize for the build failure and I'll get on the automated multi-architecture build testing that needed to happen
Anyways, but here we go. You got to get a jab in somewhere
I also remind you that I'm one of the few people who's actually been pushing for more and better automated testing
Really really I now have infrastructure for the community that anyone can use just ask me for an account and
That's been another solo effort because so few people are even interested
So the fact that this even came up great on me
This is a problem with a technical solution and instead we're all just arguing
He really really loves playing the victim in response to that comment
There was a reply from an XFS developer who was very bothered by the fact that he was saying that nobody else does testing like bcachefs
Who does have automated testing and also does make the testing available for others, so I
Don't know bcachefs has got to be special even in ways which are just
Completely untrue now referring to people getting involved in bcachefs
Here's what Kent says Linus just because you don't see it doesn't mean it doesn't exist
I spend a significant fraction of my day on ISC and the phone with both users and other developers
No one cares because that's happening outside the kernel like if you spend time on things outside the kernel
It's fine, but like we're talking about what's happening in the kernel and upstream rules has always been a fairly ad hoc thing
Which even you barely seem to be able to spell out he spelled it out like ten times already
It's taken forever to get to yes, you do want patches on the list. That's because it is such a basic requirement
the
There should be no reason to spell it out like oh, I didn't know you wanted us using git
I didn't know you wanted the code written in C
Yeah
Yeah, that's the project like you're laying out the minimum requirements
Not even the process rules just the bare minimum requirements of the way things are done here
And you seem to have some feelings the volume of fixes is an issue for you
But God only knows if that's more than a hazy feeling for you
I
Don't know how anybody works with this person. This might be one of the most insufferable developers
I've seen in the entire FOSS world. He is a really talented developer, but oh
My god, is he annoying the reason he has an issue with you submitting giant unruly patches
During the RC is because you're not the only developer on the project
If everybody did that the kernel would never release
Now here's the reason why he wanted to be mainlined because I want Linux to have a file system
We can all be proud of the users can rely on that has a level of robustness and polish that we can all aspire to
That needs to break kernel processes at every possible moment to submit
Absolutely crucial patches today. Otherwise people might lose their data
Right I
Definitely buy that now. I know there is this meme that ooh Linus is so mean Linus is hard to work with Linus is a
Saint, I
Don't know how you deal with someone like this and don't just say okay. I'm just done with this conversation
I don't even want to hear your input anymore
This is gone or I'm gonna go talk to other people involved in
Maintain a ship and we get to the side if this is gone. I'm not listening to you anymore. I
Have no idea how that hasn't happened already and I really do wonder
How many more times this needs to happen?
For it to actually be pulled
But you know what I kind of don't want it to be pulled because oh my god
This is a gold mine of conversations every single time there is a patch set
It is a mess. It is a disaster and it seems like everybody is starting to hate this person
But let me know your thoughts down below
Obviously, please don't go on harass Kent Overstreet. There's like there's no point doing that. Don't that's stupid
Leave your stupid comments in the comment section down below or put them on Twitter
I guess I don't know anyway if you liked the video go like the video and if you really like video and you want to become one of
These amazing people over here check out the Patreon, Subscribestar, Liberapay, linked in the description down below
That's gonna be it for me and
What would you have done in this situation?