Flamewar Leads to Declining of Bcachefs Pull Requests During Linux 6.13 Kernel Development Cycle (phoronix.com) 56
"Get your head examined. And get the fuck out of here with this shit." That's how Bcachefs developer Kent Overstreet ended a post on the Linux kernel mailing list.
This was followed by "insufficient action to restore the community's faith in having otherwise productive technical discussions without the fear of personal attacks," according to an official ruling by committee enforcing the kernel community's code of conduct. After formalizing an updated enforcement process for unacceptable behaviors, it then recommended that during the Linux 6.13 kernel development cycle, Overstreet's participation should be restricted (with his pull requests declined). Phoronix covered their ruling, and ItsFOSS and The Register offer some of the backstory.
Overstreet had already acknowledged that "Things really went off the rails (and I lost my cool, and earned the ire of the CoC committee)" in a 6,200-word blog post on his Patreon page. But he also emphasized that "I'm going to keep writing code no matter what. Things may turn into more of a hassle to actually get the code, but people who want to keep running bcachefs will always be able to (that's the beauty of open source, we can always fork), and I will keep supporting my users..."
More excerpts from Overstreet's blog post: I got an emails from multiple people, including from Linus, to the effect of "trust me, you don't want to be known as an asshole — you should probably send him an apology"... Linus is a genuinely good guy: I know a lot of people reading this will have also seen our pull request arguments, so I specifically wanted to say that here: I think he and I do get under each other's skin, but those arguments are the kind of arguments you get between people who care deeply about their work and simply have different perspectives on the situation...
[M]y response was to say "no" to a public apology, for a variety of reasons: because this was the result of an ongoing situation that had now impacted two different teams and projects, and I think that issue needs attention — and I think there's broader issues at stake here, regarding the CoC board. But mostly, because that kind of thing feels like it ought to be kept personal... I'd like a better process that isn't so heavy handed for dealing with situations where tensions rise and communications break down. As for that process: just talk to people... [W]e're a community. We're not interchangeable cogs to be kicked out and replaced when someone is "causing a problem", we should be watching out for each other...
Another note that I was raising with the CoC is that a culture of dismissiveness, of finding ways to avoid the technical discussions we're supposed to be having, really is toxic, and moreso than mere flamewars... we really do need to be engaging properly with each other in order to do our work well.
After the official response from the committee, Overstreet responded on the kernel mailing list. "I do want to apologize for things getting this heated the other day, but I need to also tell you why I reacted the way I did... I do take correctness issues very seriously, and I will get frosty or genuinely angry if they're being ignored or brushed aside."
This was followed by "insufficient action to restore the community's faith in having otherwise productive technical discussions without the fear of personal attacks," according to an official ruling by committee enforcing the kernel community's code of conduct. After formalizing an updated enforcement process for unacceptable behaviors, it then recommended that during the Linux 6.13 kernel development cycle, Overstreet's participation should be restricted (with his pull requests declined). Phoronix covered their ruling, and ItsFOSS and The Register offer some of the backstory.
Overstreet had already acknowledged that "Things really went off the rails (and I lost my cool, and earned the ire of the CoC committee)" in a 6,200-word blog post on his Patreon page. But he also emphasized that "I'm going to keep writing code no matter what. Things may turn into more of a hassle to actually get the code, but people who want to keep running bcachefs will always be able to (that's the beauty of open source, we can always fork), and I will keep supporting my users..."
More excerpts from Overstreet's blog post: I got an emails from multiple people, including from Linus, to the effect of "trust me, you don't want to be known as an asshole — you should probably send him an apology"... Linus is a genuinely good guy: I know a lot of people reading this will have also seen our pull request arguments, so I specifically wanted to say that here: I think he and I do get under each other's skin, but those arguments are the kind of arguments you get between people who care deeply about their work and simply have different perspectives on the situation...
[M]y response was to say "no" to a public apology, for a variety of reasons: because this was the result of an ongoing situation that had now impacted two different teams and projects, and I think that issue needs attention — and I think there's broader issues at stake here, regarding the CoC board. But mostly, because that kind of thing feels like it ought to be kept personal... I'd like a better process that isn't so heavy handed for dealing with situations where tensions rise and communications break down. As for that process: just talk to people... [W]e're a community. We're not interchangeable cogs to be kicked out and replaced when someone is "causing a problem", we should be watching out for each other...
Another note that I was raising with the CoC is that a culture of dismissiveness, of finding ways to avoid the technical discussions we're supposed to be having, really is toxic, and moreso than mere flamewars... we really do need to be engaging properly with each other in order to do our work well.
After the official response from the committee, Overstreet responded on the kernel mailing list. "I do want to apologize for things getting this heated the other day, but I need to also tell you why I reacted the way I did... I do take correctness issues very seriously, and I will get frosty or genuinely angry if they're being ignored or brushed aside."
Annoying, I really want bcachefs! (Score:2)
As a btrfs user I have been looking forward to trying out bcachefs for some time now, but I haven't got the energy to work with a custom kernel.
I hope this will blow over, because it looks like a great solution, maybe what btrfs should have been if it hadn't been bought by Facebook where they now only seem to work on features that helps petabyte-level storage pools, nothing for small home users.
Re: (Score:2)
Why don't you use zfs? I use it on a bunch of servers and it works great.
Re: (Score:2)
ZFS always will be a plugin, only 1 or two distros dare to bundle it, due to licensing reasons, by bundeling it into a distro Oracle theoretically can sue you into oblivion and thats the main problem!
Re: (Score:2)
Technically oracle can sue the distro. You are free to do what you want including running ZFS in one of the distros that doesn't consider it a plugin.
That said Oracle isn't known for their patience on this matter. If they were going to go nuclear on this legally they'd have done it by now.
Re: (Score:2)
What's the problem with installing it separately? Debian started adding it only recently, before I had to use packages provided by zfs. Now I install using debian-backports repository to get a newer version.
Re: (Score:1)
Don't rant, change. It's a better use of energy.
Re: (Score:2)
Just use FreeBSD.
Re: (Score:2)
Agreed. Whether of not I end up using the filesystem, I benefit from people doing filesystem research and anything that inhibits research is Bad News. And, yeah, I very much see that it hurts those who would definitely use it.
And, agreed, the skewed development on btrfs is not helpful either.
I do understand the need to do something and the lack of good alternatives, part of it of course is the fact that good developers are rarely good communicators and good communicators are very rarely good developers, but
Re: (Score:2)
My personal guess is, that BTRFS made some early design choices which sounded good on paper, but it basically shot them in the foot long term, they are now fighting with complexity which is not really manageable anymore. Hence BCACHEFS seems to develop in record time into a solid well working FS and BTRFS while at least for non raid scenarios being relatively feature complete seems to be stuck at this level with BTRFS already surpassing it in certain scenariii like speed and error correction!
Re: (Score:2)
Precisely.
Re: (Score:2)
We lost reiserfs due to who Hans Reiser was. It seemed to me that the kernel devs rejected it just so they had an excuse to build btrfs instead.
Re: (Score:2)
I'm not sure about the last part, but I agree with the first part.
And therein lies the problem - Reiser had valuable flashes of brilliance, but the mental qualities needed for that often produce a dark, volatile personality. And, in his case, that went way past verbal abuse into physical abuse and murder. The precise details of why aren't really knowable.
You can't just exclude all the volatile folk, that doesn't help anyone, but you can't include them either, at least not directly, and Open Source doesn't r
This does not matter (Score:2)
Re: (Score:3)
In part because the kernel used to have a bad reputation for drama so thing apparently working in something like a sensible way (contributions are slowed, there's some warning to bcachefs users that there might be problems, however the work continues) is actually news for nerds.
Re: This does not matter (Score:1)
Re: (Score:2)
Linux 6.13 has the ability to support pluggable schedules, if I recall the changes correctly.
This was first done in the Linux 2.4.x days by Hewlett-Packard. (I was tracking a lot of the out of tree projects back then because they had virtually no visibility.)
One can argue whether the HP patches were the right way to go about it, but that was not the discussion that took place, IIRC.
ReiserFS and Reiser4 stopped any serious development long before Hans Reiser started going round murdering people, he was just
Read the Patreon post on this issue from him (Score:3)
The entire explanation from him on his Patreon site. There was a technical issue how Linux handled certain errors, which he wanted to have corrected. Also on top he needed some extensions for internal debugging as far as I understood, after development and a relatively long discussion where most agreed on to integrate it, one raised converons over 2 lines of header code that he is getting maintainence issues due to getting a proxy layer in due to the headers and from then onwards things went off the rails. The points Overstreet raised were all valid, but he is not very diplomatic in a sense that you sometimes have to swallow your pride to let a certain amount of stupidity through to keep calm and then try to get the fixes in differently, thats unfortunately how things work in real life sometimes you are right but others cannot see it so you have to be diplomatic to achieve the bigger goal.
I guess kernel developers are inherently difficult like many smart people who often think they know everything and if you are on the radar for being hard to handle, you sometimes have to swallow your pride and move forward by other means, but many people cannot do that!
But from my understanding and I understood only parts of it, the issues Overstreet raised were all valid and definitely were in need for a technical discussion but probably he should have raised a ticket on those issues and not intermingle it with other discussions!
Re:Read the Patreon post on this issue from him (Score:4, Insightful)
Re BCacheFS lets face it, Linux is in dire needs of a well working COFS, ZFS is out of the kernel due to licensing reaons, BTRFs basically is half on a development standstill while already very far, but they introduced complexitiies early on they are now fighting with, while BCACHEFS almost has reached the status of BTRFS only with a handful of developers, in record time and seems to develop into the fileystem Linux really needs to move forward and achieve technical parity with other platforms on filesystem level. This project is way too important to let personal feelings get in the way and I mean that from both sides, because if Overstreet is right, this last minute veto from one of the devs over 2 lines of header code looks eerily like a personal grudge than anything else, but I only know Overstreets view on things here not vice versa!
Re: (Score:2)
Well working CoWFS? Thin volume LVM with whatever? XFS with reflink, courtesy of BTRFS? More the merrier, but I don't see the dearth. I'd rather see dm-writeboost mainlined, but the dev is a bit of a character. Also some linux company needs to adopt wyng for proper incremental backups, with a nice GUI.
Re: (Score:2)
Linux is in dire needs of a well working COFS
Why? Call me uninformed, but: what is so wrong or deficient with the current options that this is a "dire" need? Serious question.
Re: (Score:2)
ZFS is out of the kernel due to licensing reaons
So what? That doesn't prevent me from using it.
Who cares if it's mainlined? That matters for some driver not in active development which would otherwise be abandoned, but it doesn't matter for a filesystem which is being continually updated.
Re: (Score:2)
While I also use ZFS I'm not going to sit here and pretend that it isn't a supported mechanism through many distros commercially, or that running it on some distros doesn't come with downsides (even now there's a lot of fuckaroundary involved with using a ZFS root partition, one that may break upgrade paths on unsupported systems).
Many people care if something is mainlined as it offloads support and compatibility onto the kernel team. You have it backwards, for the most part it doesn't matter for drivers no
Re: (Score:2)
Many people care if something is mainlined as it offloads support and compatibility onto the kernel team.
I don't need for the kernel team to have more work to do. I need for ZFS to work. It does.
You have it backwards, for the most part it doesn't matter for drivers not in active development. At least not drivers that would otherwise prevent the system from booting.
That is ass backwards. Drivers not in active development, if not mainlined, are least likely to be updated to work with new kernels. You need them to be mainlined so that if the kernel interface changes, the driver is updated timely. Otherwise you wind up with situations where you drivers don't work on modern kernels, and then you either get to run an old kernel (and leave performance improvements on the table, even wh
Re: (Score:2)
I care if it is mainlined. I just built a new RAID array, and tried to put ZFS on it. I was following an online howto on sharing a ZFS partition via SMB, and the first SMB-specific command panicked the kernel. That kind of thing would probably be flagged almost immediately by syzkaller or some other framework for the mainline kernel. I decided I didn't want to risk my system's stability to find out what other gaping bugs there are, so I stuck with an in-kernel filesystem instead.
Re: (Score:2)
Make sure not to give us any useful information like what distribution you're using
Re: (Score:2)
I am not trying to fix the problem, I am explaining why people do in fact care whether the filesystem is in the mainline kernel. How is the distribution relevant to that point?
Re: (Score:2)
So we can know if you're using some whack distribution you never should have trusted to begin with, so we in turn know if your complaint has any merit.
I am using Root on ZFS on Devuan. There are packages, which are maintained. I had to do the install manually on Devuan 4 using the Debian instructions, which I tweaked somewhat to account for not using systemd. Since I am using Devuan, packages which work without systemd were available. I have since upgraded to Devuan 5 and it was the most troublefree Linux d
Re: (Score:2)
What were you doing? I have a few file servers with the combination of zfs and smb, all work perfectly well. I am using Debian (and started using zfs+smb since Debian 7 or 8) and never had a problem. Does your distribution do something differently?
I like ZFS and not care that it is not mainlined, it works great for me (though there were some bugs I reported and they got fixed).
Re: (Score:2)
It was one of the zfs subcommands; I don't remember the details except that it said something like a char[1] array was accessed past the end. I was just trying to set up a new NAS-like function on my Debian (trixie / testing) system. I was more interested in performance than debugging, and when it panicked with what looked like an obvious string-handling violation, I decided not to risk stability with it.
Re: (Score:2)
I think the first comment under Kent's post sums it up pretty well:
> If all the other kernel devs think YOU are being a jerk, then you probably are.
Re: (Score:2)
No. That is an argumentum ad populum fallacy.
Groupthink is a very real thing and it highly depends on the environment to what extent people value their group membership and being agreeable over doing the right thing (which is often hard or painful in some way). I've seen many instances where someone was correctly pointing out something in a reasonable non-antagonistic manner that was inconvenient for the group as a whole and got dismissed and ultimately labeled the asshole for persisting and not acquiescing
Re: (Score:2)
Would have helped a bit if he wasn't blatantly wrong.
See why people don't use Linux after reading this (Score:2)
Re: (Score:2)
Re: (Score:2)
How many people do you know who chose their OS based on how polite the kernel developers were?
Yeah, I had to laugh. Maybe we can get a niceness rating for anyone who is concerned if a developer said something the potential OS user finds offensive? Post it on Distrowatch or something.
Some people should just stick to coding (Score:2)
And not try any kind of people management or co-ordination because they're simply mentally not up to it. Its 2 entirely different skills and just because you're a hot shot coder doesn't mean you'll be able to marshall a team or get people on side if you act like a total dick every time you disagree with someone.
There's a higher level of aspergers in programming compared to the general population but a reduction or lack of social skills is no excuse for being plain damn rude.
Re: (Score:2)
Re: (Score:2)
There's something called being diplomatic when dealing with other people even if you profoundly disagree with them. This guy doesn't have it. Christ, if even Linus was suggesting he should apoligise or be thought an arsehole then he's obviously gone WAY over the mark.
Re: (Score:2)
Isn't that what he's doing? Trying to code, but the "people managers" got butt-hurt when he was too frank. He doesn't seem to have the manager role here, just trying to get good code in to the kernel. I'm not sure what you're suggesting here, that he should hire an actual manager that can speak manager-speak to the kernel CoC-department?
There's a saying in sports "If you are the very best ever, you can get away with being an asshole. If you aren't the best ever, be a decent human being.
So unless he is the best programmer who has ever graced the planet, he needs to have some courtesy.
If he can't do that, there are others who aren't disruptive.
I loathe people who are disruptive, either profane assholes or code of conduct warriors.
Now all that said, development can have people getting a little spicy at times. You just have to impres
Re: (Score:2)
There's a problem, though. Sports teams have relatively simple goals: Win the games! Programming teams (should) never play a game that has ever been won.
So this is a particular file system that solves a problem no other file system handles properly. But you've got to keep the team together, and got to work WITH the other teams. Being an arsehole is a bad move even if you're the best ever. But the project is important. (Well, I assume it is. It's not something I've needed.) It's not clear what the a
Re: (Score:2)
And not try any kind of people management or co-ordination because they're simply mentally not up to it. Its 2 entirely different skills and just because you're a hot shot coder doesn't mean you'll be able to marshall a team or get people on side if you act like a total dick every time you disagree with someone.
There's a higher level of aspergers in programming compared to the general population but a reduction or lack of social skills is no excuse for being plain damn rude.
Definitely two different skills. I might go out on a limb here to note that if there is a worker that is being an asshole, they need to be gently suggested in the kindest manner:
"Stop. Now. Or go away".
That goes for either people being assholes insulting others, or crybullies who haven read a sentence they aren't offended by.
Re: (Score:2)
While they are two skills, if you're a raw coder who can't do any people management you're not going to be a good coder. The customer doesn't care how good your code is if you can't work with people to get it implemented.
Let's put out the fire (Score:2)
Before we have a 500+ message flamewar here, and to prevent highly derogatory comments about Kent (as seen on Reddit where nuance is almost always lost among rabid Linux fanboys) and how he invaded and destroyed the Linux kernel, acted irresponsibly, wasn't correct and conscious, broke the Linux kernel workflow (he did but he has since changed and started playing by the rules), please read his apology here. [kernel.org]
I will quote it just to save your time:
Re: (Score:2)
Before we have a 500+ message flamewar here, and to prevent highly derogatory comments about Kent (as seen on Reddit where nuance is almost always lost among rabid Linux fanboys) and how he invaded and destroyed the Linux kernel, acted irresponsibly, wasn't correct and conscious, broke the Linux kernel workflow (he did but he has since changed and started playing by the rules), please read his apology here. [kernel.org]
I will quote it just to save your time:
That wasn't an apolgie, he was merely defending his right to personally attack others. Double down FTW!
He didn't need to justify anything. A simple "I got out of hand, went into insult mode, and I'm very sorry and must apologize for that."
Rather than some version of "I am a passionate defender of the best code ever, and anyone I disagree with needs their head examined and to get the fuck out of here!" so I can build the perfect coding."
HR Department (Score:1)
The trouble is linux doesn't need an HR department.
This guy was an ass, then worked it out privately with the guy who was aggrieved.
That's enough for a healthy society.
What the HR Department (CoCC, whatever) is demanding is a public struggle session where he apologizes to the community.
That is explicitly Marxist. Literally how things work in North Korea.
And they won't demand it of Linus when he's an ass. As well they shouldn't, except perhaps for the case where he called for collective punishment for an e
Re: (Score:2)
Re: (Score:2)
As well they shouldn't, except perhaps for the case where he called for collective punishment for an ethnic group based on that region's government's behavior.
Get your head examined. And get the fuck out of here with this shit.
Re: (Score:2)
Based on what I hear, how things work in North Korea involves a lot more forced labor camps and bullets to the head.
Solution: developers nicer, maintainers smarter. (Score:1)
haha no (Score:2)
But mostly, because that kind of thing feels like it ought to be kept personal
The whole thing ought to have been kept personal, then. But when you flame someone publicly, the apology has to be public too, or it's not real.
Re: (Score:2)
> when you flame someone publicly, the apology has to be public too
Absolutely this. Otherwise the public message is "people can flame away and there is no consequence". Potential developers may well think "why should I get involved there technically when I'll be treated that way too".
Ideas and code can be criticized; that's normal. Attacking people is counterproductive in addition to being needlessly hurtful. There is never any excuse for it. Apologize publicly and become a better person.
Working for the wrong team... (Score:2)
I do take correctness issues very seriously, and I will get frosty or genuinely angry if they're being ignored or brushed aside.
Sounds like he would fit in perfectly with the OpenBSD crew. Whether or not they're interested in natively using/supporting another filesystem beyond FFS2, though, is a valid question.
Funny thing about a community (Score:2)
> [W]e're a community. We're not interchangeable cogs to be kicked out and replaced when someone is "causing a problem", we should be watching out for each other...
Communities vary widely. They behave differently from place to place. They don't have set rules or norms. They definitely are not logical.
This whole thing is an important lesson: Communities inherently involve politics. A social norm is just personal activity seen through a group lens; the group judges the activity and applies a ruling.
You sh