Linux 6.12-rc2 Released With Initial Batch Of Fixes

[PuckPoltergeist]

Please stop posting FUD.

-v please

[PuckPoltergeist]

Stop spreading smears and fabrications, he only legitimately broke the code once and that was due to big-endian'ess. The other time it wasn't his fault, it was actually Christians (Linus was wrong here, but seeing as you have an issue with reading you didn't appear to get this part).

I'm speaking about the NOFAIL-changes, that would affect XFS in serious ways

[mdedetrich]

Actual TLDR - other people do this just fine. I used to do it myself in the past, and computers are much faster today. It's not like you sit and watch the code build. If this guy is as smart and godlike as everyone says, why doesn't he know how to set up Jenkins, QEMU, unit tests and cross compilation? It only took me a week or two.

Read the fuken mailing list. Hes not talking about setting up qemu, he is talking about how long it takes the filesystem tests to run in qemu which for something that needs to be purely emulated takes an insanely long amount of time.

Its so long that there is an ancient 1990's s390x mainframe (which is big-endian) sitting somewhere doing builds instead because its much faster, but this isn't being run nightly against fs-next which is the problem

Or maybe he could, you know, just work with the dumb process like the rest of us mortals have to?

Or maybe as a dumb mortal you can use your brain to read the lkml and realize that this process doesn't work well for experimental features that are being rapidly developed which is exactly where bcachefs stands, it is marked as experimental after all.

The current process is okay for code that is essentially in maintanence mode that gets very few changes, but thats not the case for bcachefs.

[pokeballs]

If bcachefs is evolving so fast that the kernel procedures can't keep up, then it should just keep evolving out-of-tree ?

The solution is really simple but someone is blinded by his inflated ego

[mdedetrich]

If bcachefs is evolving so fast that the kernel procedures can't keep up, then it should just keep evolving out-of-tree ?

Or maybe Linux should set up a nightly CI build for fs-next which literally every other major open source project has.

The solution is really simple but someone is blinded by his inflated ego

Nah your just spreading shit.

bcachefs was already developed out of kernel for a decade, Kent thought that it was a good opportunity to put it into the kernel under experimental flag, this is entirely standard process.

Since we are dealing with full featured CoW filsystems, which is one of the most complex and large systems you can think of in an OS there are understandably a big flux of changes. This is also normal. The last time such a massive filesystem got introduced was btrfs, and even though it followed the process that didn't go so well as it slowed down work on btrfs by a lot, and that meant it took much longer for users to get needed fixes/features (which is kind of critical since we are dealing with filesystems).

The only ones with an ego here is old time linux maintainers as the actual a really simple solution is to setup a CI for nightly build.

[OneTimeShot]

Or maybe as a dumb mortal you can use your brain to read the lkml and realize that this process doesn't work well for experimental features that are being rapidly developed which is exactly where bcachefs stands.

The current process is okay for code that is essentially in maintanence mode that gets very few changes, but thats not the case for bcachefs.

LOL yeah - I'm just a dumb F who knows how to cross compile for multiple platforms, and does so before pushing code. Despite my cluelessness, I also know how to automate it in an overnight. Now I'm gonna push my stupidity to see just how long it takes QEMU to boot a big endian Linux kernel to /bin/bash... Maybe my patience won't wear out after waiting 5 mins.

Maybe this guy is so good that gcc can't compile code as fast as he writes it? Or just maybe, Linus is right?

[mdedetrich]

LOL yeah - I'm just a dumb F who knows how to cross compile for multiple platforms, and does so before pushing code. Despite my cluelessness, I also know how to automate it in an overnight. Now I'm gonna push my stupidity to see just how long it takes QEMU to boot a big endian Linux kernel to /bin/bash... Maybe my patience won't wear out after waiting 5 mins.

Pro tip, its not just compiling but also running the fs tests, it was runtime behaviour that was broken.

Maybe this guy is so good that gcc can't compile code as fast as he writes it? Or just maybe, Linus is right?

Actually Linus wasn't right, but you missed that bit so you still clelarly didn't read the lkml. Linus thought that the developers in fs subsystem were actively testing for big-endian when in reality as Kent pointed out, there is a big gap there as no was really testing for that (which is not surprising, almost no one is fuken running big-endien machines).

XFS has some of their own CI systems for this, but it only tests XFS and nothing else so its not really public.

[OneTimeShot]

Pro tip, its not just compiling but also running the fs tests, it was runtime behaviour that was broken.


Actually Linus wasn't right, but you missed that bit so you still clelarly didn't read the lkml

Done. Took 4 mins on my laptop. I'm guessing the full fs tests would need to run overnight? I probably would have already caught any serious bug just by mounting a filesystem though (what with the problem being the kernel not compiling at all, and everything)... ...would you like me to automate the with a script? It'd probably take me 20mins.

Maybe I'm not as dumb as I thought?

[mdedetrich]

Maybe I'm not as dumb as I thought?

Well you have a problem reading, thats for sure. Try running the tests, then report back.

[OneTimeShot]

Well you have a problem reading, thats for sure. Try running the tests, then report back.

You know... I can't actually be bothered...

...but you know what would make me be bothered? If I was working on a file system that I was planning to upstream to Linus Torvalds and hundreds of other people...