←back to thread

144 points ksec | 1 comments | | HN request time: 0s | source
Show context
criticalfault ◴[] No.44466573[source]
I've been following this for a while now.

Kent is in the wrong. Having a lead position in development I would kick Kent of the team.

One thing is to challenge things. What Kent is doing is something completely different. It is obvious he introduced a feature, not only a Bugfix.

If the rules are set in a way that rc1+ gets only Bugfixes, then this is absolutely clear what happens with the feature. Tolerating this once or twice is ok, but Kent is doing this all the time, testing Linus.

Linus is absolutely in the right to kick this out and it's Kent's fault if he does so.

replies(8): >>44466668 #>>44467387 #>>44467968 #>>44468790 #>>44468966 #>>44469158 #>>44470642 #>>44470736 #
pmarreck ◴[] No.44467387[source]
This can happen with primadonna devs who haven't had to collaborate in a team environment for a long time.

It's a damn shame too because bcachefs has some unique features/potential

replies(1): >>44471352 #
rob_c ◴[] No.44471352[source]
And a honking great bus factor of Kent deciding enough is enough and having a tantrum. You couldn't and shouldn't trust critical data to such a scenario
replies(1): >>44472312 #
bombcar ◴[] No.44472312{3}[source]
There’s no harm doing it - if the thing actually works! Kent getting that lass metro pass wouldn’t cause your file system to immediately corrupt and delete itself.

What you want to avoid is becoming dependent on continued development of it - but unless you’re particularly using some specific feature of the file system that none other provide you’ll have time to migrate off it.

Even resierfs didn’t cease to operate.

replies(2): >>44472721 #>>44473464 #
tremon ◴[] No.44472721{4}[source]
The reiserfs code was stable and in maintenance mode. All new development effort was going into reiser4, which absolutely did die off. IIRC a few developers (that were already working on it) tried to continue the development, but it was abandoned due to lack of support and funds.

In terms of maturity, bcachefs is closer to production quality than reiser4 was, but it's still closer to reiser4 than reiserfs in its lifecycle.

replies(1): >>44472805 #
koverstreet ◴[] No.44472805{5}[source]
we're further along than btrfs in "will it keep my data"
replies(5): >>44472928 #>>44473415 #>>44473951 #>>44473972 #>>44477696 #
tremon ◴[] No.44472928{6}[source]
Fair enough, I have no practical experience with bcachefs myself.
replies(2): >>44472989 #>>44474229 #
1. koverstreet ◴[] No.44472989{7}[source]
Fair :) I've been trying to keep this thing (relatively) quiet and low profile until it's completely done, but it's gotten hyped.

Data integrity, core IO paths, all the failure modes, all the crazy repair corner cases - these are the hard parts if you really want to get a filesystem right. These are what we've been taking our time on.

I can't claim 100% success rate w.r.t. data loss, but it's been phenomenally good, with some crazy stories of filesystems we've gotten back that you'd never expect - and then it just becomes the norm.

I love the crazy bug reports that really push the boundaries of our capabilities.

That's an attitude that reiserfs and btrfs never had, and when I am confident that it is 100% rock solid and bulletproof I'll be lifting the experimental label.