Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

[intelfx]

If it was going through the existing stages, it would had been tested. 68k is covered, so no extra cross-toolchains are necessary

The "existing stages" do not work well with Kent's workflow. That's precisely why he was pushing for fs-next and centralized CI for that on the last Maintainers Summit.

[mdedetrich]

The "existing stages" do not work well with Kent's workflow. That's precisely why he was pushing for fs-next and centralized CI for that on the last Maintainers Summit.

Indeed because they are extremely infrequent. You have to submit patches at very specific times, and if you don't and miss the window you basically have to wait till the next time slot. Its insanely inefficient way to work when you are churning code as fast as bcachefs is as being actively developed since its a new experimental feature.

Thats why almost all open source projects have a nightly (or even on PR/submission of merge request) job that builds across all supported architectures for the current in progress code being worked on (which in this context is fs-next, for a lot of standard git projects its the current main and any other actively maintained branches).

The fact that Linux, arguably one of the largest open source projects in the world does not have this is really eye popping.

[PuckPoltergeist]

https://lore.kernel.org/lkml/CAHk-=w...Fm5n7UZ3eA@mai l.gmail.com/

Already read this. Seems my understanding doesn't match yours

People involved missed critical emails on the lkml,

MM-devs NAKed, VFS-devs NAKed, the guy who says, he's the only one who knows right, pushed through his own tree. I'm reading fsdevel...

Its not a nightly build that runs on fs-next, thats the core issue. Again this was stated on lkml quite clearly.

It's running for next and stable. But I forgot, bcachefs is so mature and stable and perfect, it doesn't need any stable-fixes.

As I said, we had this several times before. It's just another round with other player(s). Taking my popcorn and enjoy the show

[mdedetrich]

Already read this. Seems my understanding doesn't match yours

What, you can't read properly? Linus literally stated its not a rule, and that other subsystems can make their own guidelines. How can you get a different "understanding", I think really its just that you just can't admit that you are wrong.

MM-devs NAKed, VFS-devs NAKed, the guy who says, he's the only one who knows right, pushed through his own tree. I'm reading fsdevel...

As is clearly evident, you might be reading fsdevel but you have troubles with comprehending what you are reading.

It's running for next and stable. But I forgot, bcachefs is so mature and stable and perfect, it doesn't need any stable-fixes.

bcachefs is marked as experimental which means its expected to have high amount of changes until that flag gets removed. Maybe instead trolling you can get an undrestanding of how actual software development works.

As I said, we had this several times before. It's just another round with other player(s). Taking my popcorn and enjoy the show

Well its another case of people getting pitchforks in an attempt to demonize Kent, only to find out later that in reality the devil is in the details. People want to make a movie out of this because its entertaining, but in reality Linus/Kent came to a mutual understanding like actual adults once they both fully understood of what is going on.

People should just stop fuken putting Linus/Linux processes on a pedastal and/or demonizing Kent. They are both humans who can mistakes, extremely talented ones and these things get resolved by having mutual understanding which is what just happened.

In reality this entire thing is a diversion, what should really be discussed is why the flying fuck in 2024 (almost 2025), does Linux not have a nightly CI build against current in progress branch. This has been completely standard for open source projects for decades, and instead in their infinite wisdom Linux kernel dev's thought that offloading this to users wouldn't be problematic. My gosh.

[mdedetrich]

As far as I know, Bcachefs is clearly marked as "experimental", not "stable", and everyone seems to already know that.

So, I don't understand what is your complaint here?

He is trolling, not complaining

[Estranged1906]

ZFS: out of tree

Bchachefs: shrouded in drama

Btrfs: keeps winning

[mdedetrich]

Btrfs: keeps winning at losing your data

Fixed

[Estranged1906]

Fixed

Works on my machine (TM)

[mdedetrich]

Works on my machine (TM)

Today I learnt that the real world depoloyment size of btrfs installs is one

[fitzie]

Here is a question, one thing I don't understand.

The well-known big-endian architectures are: 68000, IBM System/360, z/Architecture and OpenRISC.

But, some other architectures are bi-endian, or some other strange mix of endianess, like: PowerPC (per-page choice), ARM AArch64 (instruction encoding, little endian by default otherwise).

Wikipedia says: "Some architectures (including ARM versions 3 and above, PowerPC, Alpha, SPARC V9, MIPS, Intel i860, PA-RISC, SuperH SH-4 and IA-64) feature a setting which allows for switchable endianness in data fetches and stores, instruction fetches, or both."

So, why is it not possible to buy an ARM CPU, and use it in the big-endian mode to do the big-endian tests? Or, a PowerPC?

Or, is it just that such a big-endian test system is not yet available for the Linux kernel? I guess that is the real issue here.

If the kernel doesn't have automated builds and tests in big-endianess mode, it's their own fault.

Why is there all this gaslighting? There are automated builds and tests in big-endianess, just need to submit the patches to linux next. Now clearly the tests that get run aren't full filesystem tests that kent controls, but it exists to minimally catch build failures/warnings/errors.

from https://lore.kernel.org/linux-bcachefs/CAMuHMdWcPpBgsK0r0U=k8NyjTjUTwBTLe6Bg_ORD2zmSNoRgJ [email protected]/ :

Which is (again) not found on any mailing list, and has never been in
linux-next before it hit upstream...

Specifically here is the automated built of s390x/m68k of linux next not showing the issue before rc1:

http://kisskb.ellerman.id.au/kisskb/branch/linux-next/head/40e0c9d414f57d450e3ad03c12765e797fc3fede/

and here is the rc1 build showing the issue:

http://kisskb.ellerman.id.au/kisskb/head/9852d85ec9d492ebef56dc5f229416c925758edc/

Kent is upset that something that would have gotten caught by automated builds if it was in linux-next wasn't caught by *his* automated systems. Thats it. He wants automated testing for him so he can continue to submit patches to linus that have not been in linux-next for a while, because of his move fast reasons.

Will the kent stans admit: 1) there is automated testing of be systems 2) it's reasonable for patches to be in linux-next for at least a week before rc1 window opens?

Because that's the reality that Linus understands, kent is only asking for CI improvements for him so it's easier for him to violate #2 without anyone noticing, which isn't a good sign.