Flamewar Leads to Declining of Bcachefs Pull Requests During Linux 6.13 Kernel Development Cycle (phoronix.com) 15
"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: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)
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.
This does not matter (Score:2)
Re: (Score:2)
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: (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: (Score:3)
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
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.
I'm all triggered here :o (Score:1)
Can't see where's the problem is. All I see is a full and frank exchange of views. Seriously, these code of conducts are being weaponised by the woke to shut-down legitimate discourse. In this case the committee blowing a private spat out of all proportion. Having been on the recieving end of worse. I choose to just ignore it.