Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bcachefs Goes to "Externally Maintained"

lwn.net

Post reply on HN
Print view View original

171–180 of 400 posts

Re: Bcachefs Goes to "Externally Maintained"

#171

Post by nextaccountic »

arp242 wrote: post #120
koverstreet wrote: post #106

Earlier quoted context omitted.

You do realize that data integrity issues are not "live and let live" type things, right? And there's a real connection to the issue that sparked all this drama in the kernel and the Debian drama: critical system components (the kernel, the filesystem, and others) absolutely need to be able to get bugfixes in a timely manner. That's not optional. With Debian, we had a package maintainer who decided that unbundling Ru…

Look, I get where you're coming from. It's not unreasonable. I've said this before. But there are also reasons why things are the way they are, and that is also not unreasonable. And at the end of the day: Linus is the boss. It really does come down to that. He has dozens of other subsystem maintainers to deal with and this is the process that works for him. Similar stuff applies to Debian. Personally, I deeply disli…

> But there are also reasons why things are the way they are, and that is also not unreasonable.

It is unreasonable if it leads to users losing data. At this point, the only reasonable thing is to either completely remove support for bcachefs or give timely fixes for critical bugs, there's no middle position that won't willfully lead to users losing their data.

This used to be the default for distributions like Debian some time ago. You only supported foundational software if you were willing to also distribute critical fixes in a timely manner. If not, why bother?

For all other issues, I guess we can accept that things are the way they are.

Re: Bcachefs Goes to "Externally Maintained"

#172

Post by saubeidl »

charcircuit wrote: post #158
wavemode wrote: post #154

Earlier quoted context omitted.

You still seem to be arguing that, shipping the change was the "right" thing to do. But that's not what's in dispute. Rather it is that, if what you think is right and what the person who makes the rules thinks is right are in disagreement, the adult thing to do is not to simply disregard the rules (and certainly not repeatedly, after being warned not to). This is the difference between being smart and being wise. If…

>the adult thing to do is not to simply disregard the rules The adult thing is to do best by the users. Critical file system bugs are worth blocking the release of any serious operating system in the real world as there is serious user impact. >Is that good for the users? I think it's complicated. It could allow for a faster release schedule for bug fixes which can allow for addressing file system issues faster.

I don't think getting the FS kicked out of the kernel is best by the users.

Good engineering requires long term thinking.

Re: Bcachefs Goes to "Externally Maintained"

#173

Post by motorest »

koverstreet wrote: post #105
nirava wrote: post #104

Earlier quoted context omitted.

To list down the current state of things: 1. Regardless of whether correct or not, it's Linus that decides what's a feature and what's not in Linux. Like he has for the last however many decades. Repair code is a feature if Linus says it is a feature. 2. Being correct comes second to being agreeable in human-human interactions. For example, dunking on x file system does not work as a defense when the person opposite…

When rules and authority start to take precedence over making sure things work, things have gone off the rails and we're not doing engineering anymore.

> When rules and authority start to take precedence over making sure things work, (...)

Didn't Linus lambast you for "lack of testing and collaboration before submitting patches", to the point the patches you were trying to push weren't even building?

https://ostechnix.com/linus-torvalds-expresses-frustration-w...

Re: Bcachefs Goes to "Externally Maintained"

#174

Post by motorest »

ranger_danger wrote: post #124
koverstreet wrote: post #105

Earlier quoted context omitted.

When rules and authority start to take precedence over making sure things work, things have gone off the rails and we're not doing engineering anymore.

I think this attitude is exactly why this happened. I would have done the same thing. Do you argue with your school teachers that your book report shouldn't be due on Friday because it's not perfect yet? I read several of your response threads across different websites. The most interesting to me was LWN, about the debian tools, where an actual psychologist got involved. All the discussions seem to show the same issu…

> All the discussions seem to show the same issue: You disagree with policies held by people higher up than you, and you struggle with respecting their decisions and moving on.

I think it's less subtle than that. The straw that broke the camel's back was quite literally abuse towards other kernel developers.

https://lwn.net/Articles/999197/

Re: Bcachefs Goes to "Externally Maintained"

#175

Post by JdeBP »

o11c wrote: post #157
MadnessASAP wrote: post #87

Earlier quoted context omitted.

It may seem like that on the surface, but you should recognise that these sorts of situations seem to follow Kent around. So either Kent is on a righteous crusade against unreasonable processes within the Kernel, Debian, and every other large software project he interacts with. Or there's something about the way Kent interacts with these projects that causes friction. I like Bcachefs, I think Kent is a very talented…

OTOH, the only named projects I've seen are Linux and Debian, which are 2 of the most toxic projects I'm aware of (I'm pretty sure the C++ standards committee beats the two of them combined). But the problem with comparisons is that even if you're better than nuclear waste being dumped into the aquifer, you still might be enough to light a river on fire.

I've been involved in C++ standardization. In my country's national body, it is nothing like what goes on in Linux kernel development, even when there are strong disagreements amongst members.

Re: Bcachefs Goes to "Externally Maintained"

#176

Post by quotemstr »

nolist_policy wrote: post #170
quotemstr wrote: post #168

Earlier quoted context omitted.

> Being correct comes second to being agreeable in human-human interactions Prioritizing agreeableness above correctness is the reason the space shuttle Challenger blew up. The bcachefs fracas is interesting and important because it's like a stain making some damn germ's organelles visible: it highlights a psychological division in tech and humanity in general between people who prioritize 1) deferring to authority,…

Citation needed.

[flagged]

Re: Bcachefs Goes to "Externally Maintained"

#177

Post by charcircuit »

nirava wrote: post #165
charcircuit wrote: post #158

Earlier quoted context omitted.

>the adult thing to do is not to simply disregard the rules The adult thing is to do best by the users. Critical file system bugs are worth blocking the release of any serious operating system in the real world as there is serious user impact. >Is that good for the users? I think it's complicated. It could allow for a faster release schedule for bug fixes which can allow for addressing file system issues faster.

> The adult thing is to do best by the users Best by users in the long term is predictable processes. "RC = pure bug fixes" is a battle tested, dependable rule, absence of which causes chaos. > Critical file system bugs are worth blocking the release "Experimental" label EXACTLY to prevent this stuff from blocking release. Do you not know that bcachefs is experimental? This is an example of another rule which helps p…

This was a bug fix. My point is that there will always be bugs in the kernel so not all bugs are worth blocking a release, but losing data is worth blocking the release for.

>"Experimental" label EXACTLY to prevent this stuff from blocking release

In practice bcachefs is used in production with real users. If the experimental label prevents critical bug fixes from making it into the kernel then it would be better to just remove that label.

Re: Bcachefs Goes to "Externally Maintained"

#178

Post by motorest »

tarruda wrote: post #137
koverstreet wrote: post #101

Earlier quoted context omitted.

No, the problem wasn't following the rules. The patch that kicked off the current conflict was the 'journal_rewind' patch; we recently (6.15) had the worst bug in the entire history upstream - it was taking out entire subvolumes. The third report got me a metadata dump with everything I needed to debug the issue, thank god, and now we have a great deal of hardening to ensure a bug like this can never happen again. Su…

It is not good when politics get in the way of good engineering. Regardless of differing points of view on the situation, I think everyone can agree that bcachefs being actively updated on Linus tree is a good thing, right? If you were able to work at your own pace, and someone else took the responsibility of pulling your changes at a pace that satisfies Linus, wouldn't that solve the problem of Linux having a good m…

> Regardless of differing points of view on the situation, I think everyone can agree that bcachefs being actively updated on Linus tree is a good thing, right?

I think bcachefs is not the problem. The problem seems to be the sole maintainer who is notoriously abusive and apparently unable to work with other kernel developers.

I'm sure if another maintainer came along, one that wasn't barred for being abusive towards other maintainers, there would be no problem getting the project back in.

Re: Bcachefs Goes to "Externally Maintained"

#179

Post by masklinn »

shmerl wrote: post #135

Some collaboration failing there, no technical reasons for it. I hope they'll sort this nonsense out and it will go back to normal upstream maintenance.

It won’t. Kent is in this very post (as well as TFA) showing that he’s not learned anything

Re: Bcachefs Goes to "Externally Maintained"

#180

Post by Szpadel »

koverstreet wrote: post #101
tarruda wrote: post #46

Since the existing bcachefs driver will not be removed, and the problem is the bcachefs developer not following the rules, I wonder if someone else could take on the role of pulling bcachefs changes into the mainline, while also following the merge window rules.

No, the problem wasn't following the rules. The patch that kicked off the current conflict was the 'journal_rewind' patch; we recently (6.15) had the worst bug in the entire history upstream - it was taking out entire subvolumes. The third report got me a metadata dump with everything I needed to debug the issue, thank god, and now we have a great deal of hardening to ensure a bug like this can never happen again. Su…

you might end up with the best filesystem in the world that no-one will use. you sacrificed long term sustainability for short term win.

even if It would be shipped in similar way to zfs, noone will use it for anything more important than homelab

why? with this altitude you cannot be threated serious and this imply many risks what you might came up with in the future. another risk is they you are sole developer of this filesystem, that's also not acceptable to consider use if bcachefs seriously.

my advice would be: consider expanding team to have few developers that are able to contribute. learn to control your pride for the good of the while project. working with (and coordinating) other developers could make you understand better upstream kernel community. and given that chance you could delegate someone else with better diplomatic skills to deal with upstream in way that would be more beneficial for the whole project in long term.

Post reply on HN