You are not logged in.
Pages: 1
Hi guys.
I'm as annoyed as the mods about the threads asking "where's the latest kernel?" like this one. It's always the same. A new kernel is being released by Linus, the Arch guys wait for the .1 patch release, which takes weeks, and in the meantime a lot of other distros receive the new kernel before Arch.
Today Ubuntu 26.04 LTS has been released with kernel 7.0 before Arch receives kernel 7.0. An LTS release! Come on, this clearly feels wrong. Does anyone know why our kernel package is treated like a RHEL package whilst every other package is just released as soon as the maintainer finds time to release it? It would be great to hear the reasoning of the kernel package maintainers.
Offline
This is some kind of competition between distros - which one will be the first to push a new kernel into repo? What is the award for winner?
Offline
FOMO? ![]()
-----------
Online
This is some kind of competition between distros - which one will be the first to push a new kernel into repo?
A competition between CachyOS and ArchLinux, maybe. And Arch is always losing.
But it's not a competition with Ubuntu LTS. They pick a kernel they have to support for 5 years. No new (default) kernel for 5 years. So, they definetly need a safe, stable choice. Still they are quicker than Arch. Doesn't make sense.
Offline
A competition between CachyOS and ArchLinux, maybe. And Arch is always losing.
Losing from what? What is Arch supposed to be losing here?
Last edited by 5hridhyan (Yesterday 19:40:06)
-----------
Online
im sure the majority of arch users dont care, i dont, i didnt even know it was a thing till right now, its ready when its ready, have patience
Offline
its ready when its ready
That's a great slogan, I love it! And it applies to all packages in Arch - except for the kernel package. Kernel 7.0 is ready for Linus, for CachyOS, for Ubuntu LTS. Why is it not ready for Arch? Why do Arch kernel maintainers think otherwise?
Offline
mainline: 7.0 2026-04-12 [tarball] [pgp] [patch] [view diff] [browse]
stable: 7.0.1 2026-04-22 [tarball] [pgp] [patch] [view diff] [browse] [changelog]
stable: 6.19.14 [EOL] 2026-04-22 [tarball] [pgp] [patch] [inc. patch] [view diff] [browse] [changelog]6.19.14 being the EOL for 6.19 was released yesterday along 7.0.1 and is currently in core-testing
First step in any race: figure where the goal is.
Edit: forgot to link https://aur.archlinux.org/packages/linux-mainline
Last edited by seth (Yesterday 19:58:05)
Offline
First step in any race: figure where the goal is.
It's clear to me what Ubuntu's goal is for an LTS release.
But what is the goal for Arch?
Offline
Apparently to follow the latest stable kernel to its EOL?
Just a "feeling".
Offline
The latest stable kernel is 7.0.1 as you can see in your quote.
edit: And since it has been released only recently one might ask what has been the latest stable kernel before that? Well, it was 7.0.0 for the 10 days before that.
Last edited by thorstenhirsch (Yesterday 20:16:07)
Offline
Nothing to do with competition, it has to do with stability. On a regular basis, the latest Kernel is available in [core testing] if there were not so many bugs in the rc's cycle.
Here the kernel is 7.0 and it has a ton of new stuff, including AI.
You have to wait. Otherwise, enable the [miffe] repo for extra excitement if you want.
Offline
Stability? I don't think Arch's goal is to offer the most stable distro. If you search for the most stable distro don't look for a rolling release. Look for an LTS release. Oh, and did I mention that Ubuntu LTS ships the 7.0 kernel earlier than Arch?
Offline
The latest stable kernel is 7.0.1 as you can see in your quote.
to its EOL
6.19.14 being the EOL for 6.19 was released yesterday
Offline
So, all packages follow the rule "it's ready when it's ready" except for the kernel package, which seems to have the strategy "it's ready when it's a patch release, but we don't trust Linus with major versions, so we wait for the .1 patch, except when the patch comes out within days, because we wait at least 2 weeks, and then we finally ship the latest patch release". Sounds rather complicate to me for a rolling release distro.
Offline
That's probably one way to describe
follow the latest stable kernel to its EOL
Just as https://en.wikipedia.org/wiki/Deferent_and_epicycle is a way to describe celestial observations.
The kernel release overlapping stable versions, the arch packager made a call which ones to pick, you don't like that call for reasons.
That's it?
Or will this go on forever and absolutely nowhere?
Offline
Yes, I don't like that call, because it's inconsistent with the rest of Arch. That's it. I'd prefer the package maintainers would follow the "it's ready when it's ready" slogan.
Offline
So if we've settled the feelings about wrongness (you know, the subject of this thread…), you can file a bug to switch the strategy to use the latest stable kernel with the biggest number and vote for the mainline kernel package.
Offline
Oh, I found it rather interesting to learn about the expectations of all the other Arch users. Everybody had "wrong" expectations except you.
Offline
Errr… wut?
The thread is "kernel release strategy feels wrong" and I told you what pattern I can see in that strategy that might make it feel rational.
Then we figured that you don't like that strategy - but that is really nothing that can be dealt with in this context. You can blog about that or state your objection at the bugtracker (this is not a out-of-date situation, you're questioning the decision making process)
@dimich and @5hridhyan have tried (snarkily) to get at what kind of point you were trying to make, @jonno2002 has opined out that most users likely simply won't worry about this specific matter.
At best only @Archcan_98 has (mildly) alluded to "expectations" ("has to do with stability"), basically giving a reasoning for the present strategy.
So what have you learned "about the expectations of all the other Arch users"?
I assume the last sentence is supposed to point out the inherent subjective bias of expectations? Ie. that everybody thinks that everybody else is wrong and only oneself is correct?
Offline
But I'm not saying anything about being correct. I'm saying something about expectations are aligned with the kernel maintainer's release strategy.
Offline
Not a Kernel or Hardware issue. Moving to Arch Discussion.
Inofficial first vice president of the Rust Evangelism Strike Force
Offline
I'd prefer the package maintainers would follow the "it's ready when it's ready" slogan.
Maybe you have bad expectations.
This is not meant as "it's ready when it's ready upstream".
More correct explanation is "it's ready when it's ready by our maintainer, so please be patient, we do this job free of charge in our free time"
Offline
coming from Gentoo, I'm already grateful for what I get for free, since I choose Arch as my distro, I informally agree with maintainers choice, if I don't I'd have to hop to whatever fits my expectations, so I don't mind in waiting for weeks for a new kernel, also about slogan, "Arch is rolling, not reckless" would be better ![]()
maintainers are mostly volunteers, so they might have personal life and stuff, also bumping a kernel has some kind of responsibility to NOT to break userspace and experience.
Imagine a maintainer bumps a version in hurry despite they had personal life so no "proper" testing and just because they want to be first in a race no one asked for, and smtg might brutually break, Then? insert skull emoji
-----------
Online
comparing with cachy or other game-focused arch-based is quite nonesense - because many of them just take the latest kernel when it's released - slap thier flavor specific patches on it - and push it without much testing
yes, as reported by media: it''s 7.0 simply for the fact that Torvalds sees a .20 as "too big" and isn't really a proper "major update" in the regular sense - it's just an arbitrary decision when to rollover
so by this switch to it shouldn't require much testing - but: it's tested nonetheless
then why does it take so long: likely because there aren't many testers
so, one "solution" to your "problem" is: instead of complain maintainers take long to test new kernels - register yourself as one and help them tooo improve and speed up
this topic has XY-problem written all over it: you're unsatisfied and just complain instead of provide assistance to improve
Offline
Pages: 1