Announcement
Collapse
No announcement yet.
Linux 6.12-rc2 Released With Initial Batch Of Fixes
Collapse
X
-
Originally posted by mdedetrich View Post
It shows, if your not bothered you probably shouldn't have even tried
And you know who is bothered? Kent, which is why kent is helping set up a nightly CI build for fs-next so that these issues don't happen again.
- Likes 2
Comment
-
Originally posted by OneTimeShot View Post
Wow - HE came up with the idea of running the regression tests before pushing the code and screwing people over? I totally see why Linus was wrong to doubt him now.
- Likes 2
Comment
-
Originally posted by mdedetrich View Post
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.
- Likes 3
Comment
-
Originally posted by NateHubbard View PostMaybe we should all just let the kernel developers argue about this, instead of us all arguing about the kernel developers arguing about this?Last edited by mdedetrich; 07 October 2024, 10:09 AM.
- Likes 1
Comment
-
Originally posted by mdedetrich View Post
It is genuinely the case that Kent is insanely smart, he is one of the smartest long time kernel contributors.
But in all seriousness, maybe Kent is insanely smart, or he is a egocentric one man show that somehow convinced the zfsdiots that he is the true savior and everything else is gonna eat your data. The more I see of Kent, the more I see a smart developer in the mind of a 10 year old with poor socialization.
So where does this get us. In my opinion, bcachefs should not be in mainline now or any time soon. Kent has shown that he does not care about anything but his filesystem running on his hardware, like the true one man show he is. And something like that does have no place in a kernel.
- Likes 2
Comment
-
Originally posted by Radtraveller View PostCan someone explain the bcachefs thing? The only I've been able to take away from this : There is a process for code submission so the code is tested against standards to make sure it doesn't break things which may take a while, but one guy bypasses that established process?
I've no way to determine if the guy submitting the code is so experienced and good at what he does that it shouldn't be an issue. But then again, anyone can make a mistake or typo once in a while.
Shrug, can't some folks that are tired of having to deal with old hardware simply fork and do a version that, while mainly staying in sync with Linux, drops the whole backward compatibility for anything older than 'x' generations of hardware? Then they can manage code submission any way they want?
long explanation:
The release cycle for a new linux kernel is roughly 9 weeks these days. subsystems are expected during the 9 weeks to submit an initial submission during the release window opening that has been previous submitted to linux-next, and for the rest of the 9 weeks, they are suppose to only send in fixes to that version. The release cycle for the next release overlaps the current one, and officially kicks of early in the current release cycle. It looks like this:
- release window opens for release N
- submissions merged into linus tree (mostly via git tags sent to linus with an email explaining what's being sent in)
- rc1 release
- linux-next now open for release N+1
- developers submit bugfix updates to linus for release N
- developers send new code meant for N+1 to linux-next
- linus releases rc2, rc3 on a weekly basis
- linus release final release N kernel at around rc9
- release window opens for release N+1
This means that developers have to split up their work into what's for the release N vs release N+1 basically all the time. And usually beyond that if they are working on something that isn't clear when or if it will become stable. What's important is that until rc1 is released, linux-next points to release N, and is an important integration checkpoint that has a dedicated developer doing the merges of hundreds of git branches, and daily automated build tests on tons of platforms including m68k boxes and s390x computers.
What happened here was bcachefs author submitted something to linus that wasn't in linux-next. this is the linux-next on september 27th (6mb compressed patch file), that doesn't have the bad patch
and this is the same day September 27th when the patch made it's way into linus's tree for rc1.
What was the bad patch?:
"give bversions a more distinct name, to aid in grepping"
So this patch that wasn't a last minute fix or anything like that, was sent to linus right before rc1 was release bypassing linux-next. Now technically bcachefs author could have made it available for linux-next at the same time, but it but it certainly wasn't submitted for linux-next even a day before.
As soon as linus tags rc1 (20240929), this patch breaking big endian systems is detected.
Sun, 29 Sep 2024 15:51:43 -0700 linus announcement email
Mon, 30 Sep 2024 16:53:22 +0200 announcement of build errors/warning
that is a four hour difference.
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.
Even if the bcachefs author had access to the CI that tests in every way known, there is still two problems. 1) this patch wasn't made available to others to see before submission, 2) this patch wasn't tested by the developer for more then a few hours before submitting to linus. Having a better CI wouldn't have fixed those problems. Linus certainly is flexible if there was some sort of last minute robustness feature that really needed to get in, but when he investigated the details he's seeing there's just this attitude of cramming things into the submission at the last minute. There's always going to be some issues that even the best CI will not detect, and submitting changes made at the last minute for no good reason will end up causing conflict if and when an issue is found with a patch and the history is revealed that shows this patch wasn't made available for anyone to check before it got to Linus.
Quite frankly, going through this, it's actually quite hard to recreate exactly what happens when, because there's no real standards of immutability, so the details of when bcachefs author made his submission to linux-next (which is technically done by the bcachefs author just updating a git branch available to pull by the linux-next team) is lost forever, because that branch has been reset to track 6.13 work now. Linus's tree is a good record of time, the emails are too. the bcachefs author doesn't like to have email records of these patches for some reason.
The bcachefs author makes a claim that he needs to get things to his users as quickly as possible, but there's just no way to do that with linus/stable trees. If there's something that's not a critical bugfix it's just not going to get back into stable no matter what, so if it's an improvment, or diagnostic it doesn't apply to ever make it to stable trees. This is why distro kernels have a lot of stuff just not in the LTS trees even though they might be using an LTS kernel. And if it's really urgent, it can take several days to get into linus tree and then another week after that to make its way back to stable. for those users that need patches ontop of stable kernel the bcachefs author talks about the pain of having to tell people about a different location to get those patches, instead of just permanently announce on the bcachefs website his tree as the proper place to check for any last minute urgent fixes (e.g. check this git for release-N-fixes branch, if it exists use that, otherwise use stable tree). There is always going to be some delay for the stable branch, and oddly enough it's even further made difficult because the bcachefs chooses to submits patches to stable in a fashion that isn't preferred by the stable tree maintainers, which causes them additional overhead and puts bcachefs stable patches to be done manually by the stable maintainer after others. This is because the bcachefs author doesn't like the preferred way.
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.
Last edited by fitzie; 08 October 2024, 08:10 AM.
- Likes 2
Comment
Comment