Linux 6.12-rc2 Released With Initial Batch Of Fixes

[mdedetrich]

But the bcachefs author blames the fact that there's not a CI that found this, when there very much was a CI that found it. The bcachefs author seems to want some sort of thorough CI that can prevent him from submitting anything bad into linux-next/linus, and obviously breaking builds like this is an easy thing to detect and prevent. The issue the bcachefs author has is that all the existing CI's are there only after the submission to linux-next or torvalds is made. But as Linus explains that's kinda the way it works, no one is expected the kernel to work for every possible use case they don't care about, only that what you submit is available for testing by others before it makes it's way to Linus.

I am going to ignore the rest of your dribble, but you just very eliquently shot yourself in the foot and explain the core issue. You can't just submit currently in development code into linux-next all of the time because you have a high chance of breaking the build for everyone else, which is why fs-next exists in the first place. The whole point of fs-next is it acts as a current in development work branch (typically this is a `main` branch for standard git projects) and you don't want to push that into linux-next which by your own admission would be the only way to get the current Linux CI Ito build your project to figure out it doesn't break for everyone else.

The problem is that there is no CI in fs-next, so you don't get proper feedback when working on a feature if it actually builds/runs on all platforms until that last moment when code is submitted to linux-next for a release candidate.

The bcachefs author defenders here have gaslighted this history to the nth degree, are resorting to cheap attacks and logical fallacies to "win" their argument. They can easily point to the fact that most developers work through a github style pull request system, so the linux system is different and therefore inferior. They can poke fun of email as a record of patch introduction, or whatever they want. Linus wrote git, so i find the accusation that he is holding on to doing things the ancient way kinda laughable.

By definition, having a CI that runs frequently (typically nightly) on current in progress code (i.e. fs-next here) is better than not having it exist at all. Just because something is done some way in Linux doesn't automatically mean its good. In fact considering that Linux is like 35 years old and the majority of people that have power/sway are greybeards, its actually highly likely that when it comes to modern process for software development Linux are really that antiquited. This really should not be that surprising and its also the same reason why Linus is open to suggestions, he is aware of this (and unlike you he is not dogmatic about it).

Ontop of this because we are dealing with greyboards who typically have big ego's, they have no incentive to change things because its what they are used to, so anyone that comes along and puts a light on this and also tries to fix it is always going to ruffle a lot of features.

I mean they are obviously extremely talented when it comes to low level kernel engineering, that doesn't mean they are excellent in every area.

[fitzie]

I am going to ignore the rest of your dribble, but you just very eliquently shot yourself in the foot and explain the core issue. You can't just submit currently in development code into linux-next all of the time because you have a high chance of breaking the build for everyone else, which is why fs-next exists in the first place. The whole point of fs-next is it acts as a current in development work branch (typically this is a `main` branch for standard git projects) and you don't want to push that into linux-next which by your own admission would be the only way to get the current Linux CI Ito build your project to figure out it doesn't break for everyone else.

The problem is that there is no CI in fs-next, so you don't get proper feedback when working on a feature if it actually builds/runs on all platforms until that last moment when code is submitted to linux-next for a release candidate.



By definition, having a CI that runs frequently (typically nightly) on current in progress code (i.e. fs-next here) is better than not having it exist at all. Just because something is done some way in Linux doesn't automatically mean its good. In fact considering that Linux is like 35 years old and the majority of people that have power/sway are greybeards, its actually highly likely that when it comes to modern process for software development Linux are really that antiquited. This really should not be that surprising and its also the same reason why Linus is open to suggestions, he is aware of this (and unlike you he is not dogmatic about it).

Ontop of this because we are dealing with greyboards who typically have big ego's, they have no incentive to change things because its what they are used to, so anyone that comes along and puts a light on this and also tries to fix it is always going to ruffle a lot of features.

I mean they are obviously extremely talented when it comes to low level kernel engineering, that doesn't mean they are excellent in every area.

you keep lying. 1) linux-next is the place for builds to fail. that's kinda the entire point to flesh those issues there, no one has ever been yelled at for causing an issue in linux-next, unless it's determined they didn't test the code themselves. it's expected to find issues there that your local testing might not have caught 2) there is a CI for linux-next. there is I've sent out several links to the dashboard you can see all the posts from the CI on the linux-next mailing lists. linux-next is release daily and CI tested by many builders throughout the release cycle. and fs-next was created to avoid the broken builds that exist in linux-next not the other way around, because the fs/vfs/mm developers want to do integration testing without worrying about other subsystems. When it was formally requested, Wilcox wrote:

We'd like to avoid that testing be blocked by a bad patch in, say, a graphics driver.

I'd post links to the emails from the CI's but you've committed to your story so I wont bother. if anyone is believing your stories they should just look at the linux-next mailing list and you'll see that mdedetrich is just existing in his own reality.