Bcachefs Looks Like It Won't Make It For Linux 6.6

[phoronix]

Phoronix: Bcachefs Looks Like It Won't Make It For Linux 6.6

While we've been looking forward to Bcachefs landing and carrying out a fresh round of performance testing of Bcachefs against other file-system options, it's looking clear now that Bcachefs won't be landing for the Linux 6.6 merge window...

https://www.phoronix.com/news/Bcachefs-Delayed-Linux-6.6

[sobkas]

I hope it wont end up similar to "that filesystem that shall not be named".

[mxan]

What even are the real (and I mean *real*) advantages of Bcachefs over Btrfs?

[ermo]

Well that escalated quickly.

From my PoV, Kent's perspective appears to be that he's tried his level best to pave the way for this for a while, yet all of a sudden, hidden requirements and other obstacles pop up in front of him.

In contrast, the kernel perspective appears to be that Kent hasn't followed accepted practices and when that is pointed out, Kent gets frustrated.

Here's hoping the involved parties manage to reset the somewhat frustrated atmosphere and end up working together constructively, including agreeing on clear and up-front acceptance criteria for landing this in linux-next at least.

May the best possible outcome manifest itself.

[GraysonPeddie]

kafkaesque

What a strange word... I had to look that up on StartPage:

characteristic or reminiscent of the oppressive or nightmarish qualities of Franz Kafka's fictional world

[Sonadow]

Too many egos, too little technical mindset and work using something a lot more reliable and responsible, e.g. github/gitlab where people can post merge requests officially and discuss them in a manner which facilitates a frictionless information exchange without the need to grep through thousands of emails trying to find a needle in a haystack.

Issues like this will rear its ugly head again and again in the future. A mailing list as a method of developing such a big project with so many participants is simply wrong and breaks way too often.

Too bad, LKML is preferred for the exact same reasons: no fucking responsibility for anything. There are literally tens of dozens of unreplied posts with serious issues in LKML every month. And don't tell me kernel developers are volunteers working in their spare time. Over 95% of commits to the kernel are made by paid developers developing the Linux kernel and nothing else.

Using a mailing list to handle patches for something as large as a kernel is seriously assbackwards.

And right on cue, as soon as he give the mailing list the metaphorical finger, replies start popping up in the list about how "we really want bcachefs mainlined". Well if you want it mainlined, perhaps it's time you learn how to accommodate others once in a while and meet them halfway instead of insisting on your way all the time.

Since Kent is going to take himself offline for some time, I say it's a very good opportunity for many of Linus's lieutenants to do the same. I can think of at least one such "lieutenant" who doesn't deserve that position.

[andyprough]

All of the BCA chefs are going to be severely disappointed.

[erniv2]

Tbh. that it was not in linux-next is a clown comment, since it was allready submitted for 6.5 and axed there aswell and nobody noticed that ?

I understand the frustation.

[Doomer]

well, he can hate the way linux is developed all he want but that won't give him a special pass to bypass the current set of rules, if you ever tried to push something upstream you would know about the entire pipeline to stable so I'm not sure why he though that skipping steps was ok...

nobody noticed that ?

linus said he was sorry for not realizing it sooner, I guess no one was/is really paying enough attention to it, I'm not sure if I can use it to gauge its popularity as to be honest I don't see why I would use it over the current filesystems that have more or less the same feature set

[WereCatf]

The thing I don't understand is why is fixing the compilation and submitting bcachefs for linux-next such a major obstacle? It'd only be a little bit more work, since the compilation issue could probably be fixed in minutes and the patch submitted for linux-next in another couple of minutes, after which the only thing you'd have left would be....to wait for it to hang around in linux-next a bit. A couple of months more waiting just doesn't seem like a massive hurdle to me.