Hacker News Reader

Comment by ranger_danger | Hacker News Reader

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 issue: You disagree with policies held by people higher up than you, and you struggle with respecting their decisions and moving on.

Instead you keep arguing about things you can't change, and that leads people to getting frustrated and walking away from you.

It really doesn't matter how "right" you may be... not your circus, not your monkeys.

View on HN

> 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/

I think that abuse falls under "struggling" to respect their decisions, but yes I agree that was a big part of it.

You might want to read the full story on that one.

> You might want to read the full story on that one.

I read the full story. Everyone else can do the same. Somehow it seems you opt to skip it and prefer to be deeply invested in creating an alternative reality.

Your analogy fails to account that after "Friday" bug fixes are still allowed. A file system losing your files sounds like a bug to me.

Edit since you expanded your post:

>The most interesting to me was LWN, about the debian tools, where an actual psychologist got involved.

To me the comment was patronizing implying it was purely due to bad communication from Kent's end and shows how immature people are with running these operating system are. Putting priority on processes over the end user.

>respecting their decisions and moving on.

When this causes real pain for end users. It's validating that the decision was wrong.

> really doesn't matter how "right" you may be... not your circus

It does because it causes reputational damage for bcachefs. Even beyond reputational damage, delivering a good product to end users should be a priority. In my opinion projects as big as Debian causing harm to users should be called out instead of ignored. Else it can lead to practices like replacing dependencies out from underneath programs to become standard practice.

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 goal of all this grandstanding was that, it's so incredibly and vitally important for these patches to get into the kernel, well guess what, now due to all this drama this part of the kernel is going to go unmaintained entirely. Is that good for the users? Did that help our stated goal in any way? No.

>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 predictability.

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.

> This was a bug fix.

I'm not sure exactly what you are talking about, and I'm not sure you do either. The discussion that preceded bcachefs to be dropped from the Linux kernel mainline involved an attempt to sneak a new features in RC, sidestepping testing and QA work, which was followed up by yet more egregious behavior from the mantainer.

https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur...

>sneak a new features in RC

Too solve a bug with the filesystem that people in the wild were hitting. Like how Linus has said in the past with how there is a blurry line between security fixes and bug fixes. There is a blurry line between filesystem bugs and recovery features.

If you read the email it is clear that the full feature has more work needed and this is more of a basic implementation to address bugs that people hit in the wild.

> Too solve a bug with the filesystem that people in the wild were hitting.

So you acknowledge that this last episode involved trying to push new features into a RC.

As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions.

All these red flags were repeatedly raised in the mailing list by multiple kernel maintainers. Somehow you're ignoring all the feedback and warnings and complains raised by people from Linux kernel maintainers, and instead you've opted to try to gaslight the thread.

No, I'm sorry but you're simply wrong.

bcachefs has a ton of QA, both automated testing and a lot of testers that run my latest and I work with on a daily basis. The patch was well tested; it was for codepaths that we have good regression tests for, it was algorithmically simple, and it worked perfectly to recover a filesystem from the original bug report, and it performed flawlessly again not long after.

I've explained my testing and QA on the lists multiple times.

You, like the other kernel maintainers in that thread, are making wild assertions despite having no involvement with the project.

> No, I'm sorry but you're simply wrong.

It sounds like you have a hard time coping with reality.

https://www.phoronix.com/news/Linux-616-Bcachefs-Late-Featur...

I repeat: it sounds an awful lot like you are trying to gaslight this thread. Not cool.

When this fact was again explicitly pointed out to you by Linus himself, you even tried to bullshit Linus and try to move the goalpost with absurd claims about how somehow it was ok to force untested and unreviewed features into a RC because somehow you know better about what users want or need as if it was some kind of justification for you to skip testing and proper release processes.

You need to set aside some time for introspection because you sound like you are your own worst enemy. And those you interact with seem to be fed up and had enough of these stunts.

The changes weren't untested or unreviewed, and they've performed flawlessly on quite a few occasions since then.

Sorry, the only person gaslighting here is you.

Holy cow. You really deserved the kick. Fixes the RC in question aren't for bugfixes in general, but bugfixes for existing patches that in that RC.

It doesn't matter if you have bugs in the code still. At all. Having bugs in the code is not relevant. You are 100%, completely, inexcusably wrong if you were providing a bugfix that wasn't fixing something specifically changed in the RC.

Untested and unreviewed? Your own testing process and review process does not meet that. "Since then" is entirely irrelevant. Saying "I've proven it works" means you have no concept of stability in a release process.

I sincerely hope your code gets the boot from the kernel, because you clearly will never be able to maintain it there. You just don't listen. To anyone.

Your personal definitions of the above terms are irrelevant. How you think the kernel should be maintained, is meaningless. Whether you think your code is ready is an insane way to validate that you're "super special and get to have your way".

Personally, I'd never hire you from this alone.

As a rule, strong feelings about issues do not emerge from deep understanding.

> 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.

alternative perspective: those users have knowingly and willingly put experimental software into production. it was their choice, they were informed of the risk and so the consequences and responsibility are their’s.

it’s like signing up to take some experimental medicine, and then complaining no-one told me about the side-effect of persistent headaches.

that doesn’t stop anyone from being user-centric in their approach, e.g. call me if you notice any symptoms and i’ll come round your house to examine you.

… as long as everyone is clear about the fact it is experimental and the boundaries/limitations that apply, e.g. there will be certain persistent headache medicines that cannot be prescribed to you, or it might take longer for them to work because you’re on an experimental medicine.

Again: the elephant in the room is that a lot of bcachefs users are using it explicitly because they have lost a lot of data on btrfs, and they've found it to be more trustworthy.

This puts us all in a shitty situation. I want the experimental label to come off at the right time - when every critical bug is fixed and it's as trustworthy as I can reasonably make it, when I know according to the data I have that everyone is going to have a good experience - but I have real users who need this thing and need to be supported.

There is _no reason_ to interpret the experimental label in the way that you're saying, you're advocating that reliability for the end user be deprioritized versus every other filesystem.

But deprioritizing reliability is what got us into this mess.

>users are using it explicitly because they have lost a lot of data on btrfs

PLEASE, honestly, EDUCATE THESE USERS. This is still marked experimental for numerous reasons regardless of the 'planned work for 6.18'. Users who can't suffer any data loss and are repeating their mistake of using btrfs shouldn't be using a none default/standard/hardened filesystem period.

No, really. People aren't losing data on bcachefs. We still have minor hiccups that do affect usability, and I put a lot of effort into educating users about where we're at and what to expect.

In the past I've often told people who wanted to migrate off of btrfs "check back in six months", but I'm not now because 6.16 is looking amazingly solid; all the data I have says that your data really is safer on bcachefs than btrfs.

I'm not advocating for people to jump from ext4/xfs/zfs, that needs more time.

You're arguing in circles. Either bcachefs is experimental and hence needs a lot of changes and tools to make sure that users dont lose data and hence the fixes are not critical/users can use a custom branch. Or it is stable and the only thing users need is actual big fixes. Not new tools in an RC3.

Don't compare bcachefs with btrfs for stability. Compare it with ext4. (And dont care anecdotal data, compare the process).

So, are we agreeing that btrfs isn't fit for purpose, then?

I don't understand your question. Are you going somewhere with this?

Kent, whenever you're at a point where you could make a good decision and make progress on any non-technical axis, you choose to attack something or someone. This is why you're getting the reactions you are getting. bcachefs design looks good, literally everything else about the project is miserable, because of this.

Now, I fully expect you to react poorly to this message, too. That is the expectation the world has formed of you. Think about that.

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

Good engineering requires long term thinking.

There's more than bcachefs in the kernel. If dealing with bcachefs takes an inordinate amount of time and effort, dropping it is the right move.

I don't know the situation well enought to review where they drew the line, but there definitely should be a line somewhere.

That was my point exactly.

Reply on news.ycombinator.com