Documentation/process/stable-kernel-rules.rst[1] now mentions how to tag commits you do not want to see backported to stable/longterm series without an explicit request.[2]
Ohh, and it now mentions the difference between stable@kernel.org and stable@vger.kernel.org, too.[3]
"'We’re happy to announce that registration for @linuxplumbersconf 2024 is now open. […]
To try to prevent the instant sellout we had in previous years we are keeping our cancellation policy of no refunds, only transfers of registrations. You will find more details during the registration process. […]
As usual we expect to sell our rather quickly so don’t delay your registration for too long!'"
"'[…] This seems to be a regular-sized release, maybe even slightly on the smaller side. All the stats look fairly normal […]
We don't have any new filesystems, and the xfs online repair work means that the bcachefs fixes aren't even the biggest filesystem change any more. But all of that is dwarfed by all the usual driver updates […]
@kernellogger But if a feature is marked as deprecated, this mean that people should avoid using it. So what i don't understand is if they are undeprecating it, or just reintroduce it, because other projects ignored the deprecation (that shouldn't be how things work in an ideal world)
For the kernel it boils down to: the construct "deprecated" has not much meaning, apart from telling people to migrate away from something; what matters is Linus' "no regressions" rule[1].
Of course in reality things are more complicated and things sometimes needs to be handled on a case-by-case basis.
"'[…] #git was created as a tool to unblock future #Linux#kernel releases — not intended as a global reinvention of all source code management; Linus’s comments highlight that he explicitly saw source code management as the domain of other tools that would then interface with git. […]'"
'"[…] we are happy to launch the LWN Kernel Source Database as an experimental, subscriber-only feature. Much of the information found in these articles is available there, along with quite a bit more. We encourage readers to play with the system and to let us know what they think. To be clear: there is no plan to stop publishing these articles anytime soon […]"'
"'[…] Despite having attracted a fair amount of interest from the development community, sched_ext has run into considerable opposition and seems far from acceptance into the mainline. The posting by Tejun Heo of a new version of the sched_ext series at the beginning of May has restarted this long-running discussion[…]'" #kernel#LinuxKernel
'" The data shows that “frozen” vendor #Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream “stable” Linux #kernel created by Greg Kroah-Hartman. '"
@kernellogger That's to be expected, but it is also not the point of them.
I agree they shouldn't need to exist, but the realities of how many many an organization manages their IT necessitates their existence.
The industry doesn't want to go through the withdrawal phase of building a better world.
@kernellogger I'm afraid I can't support the counting methodology in the paper either. Besides the not applicable because of config issues RH people cite, there's also the fact that not everything that has a cc: stable tag is an exploitable bug. Plus every fix backported carries risk (just look at the number of regressions in stable due to backports) so that risk has to be set against the benefit of the backport. A general rule would be if it's not exploitable don't backport it.
2024-05-10 13:04 a fix is proposed, which a bit later is confirmed to be working[2]; a msg stating "I'll send out the formal patch next week" follows a few hours later
2024-05-16 14:11 six days later the "Formal patch is still under internal review"[3]
It among others brings support for explicit sync. If you wonder what this is and why it's important, check out https://zamundaaa.github.io/wayland/2024/04/05/explicit-sync.html . Long story short: it among others enables better wayland support in Nvidia's drivers.
Theo de Raadt and Linus Torvalds are debating mseal(), a #Linux variant of OpenBSD's mimmutable() syscall – which might or might not be merged for #kernel 6.10, as can be seen from other parts of the discussion:
/me wonders what he should have written instead to somehow indicate what's happening while staying subtle at the same time -- "throwing words at each other" maybe?