Hmm, seems[1] people submitting #Linux#kernel pull request in #github for torvalds/linux[2] do not get a helpful "you are wrong here" message[3] from the KernelPRBot any more.
Does anyone know if the service/the bot was abandoned? Or is it just broken?
[Edit] should be working again, see replies! [/Edit]
Wait, what? Building #Linux now (e.g. since [1], which is in 6.10-rc1) requires #python[2]? At least when building the msm graphics driver? Uhh, interesting. 🧐
'"[…] I introduced that "no regressions" rule something like two decades ago, because people need to be able to update their kernel without fear of something they relied on suddenly stopping to work. […]"'
Follow the link for context and other statements that did not fit into a toot.
2/ Also note that Linus' message[1] indirectly explains why you might not be able to claim "no regressions" when you only find a problem after updating from one longterm aka LTS #Linux#kernel series to a later one:
By then others might have started relying on the new behaviour, hence fixing the regression might be impossible without causing a regression for those other people – and then you might lose out.
…if there is still enough time for PREEMPT_RT to make it into the next longterm #kernel: might be possible, but then everything has to be ready mid or late September for 6.12, as that will be the next LTS #Linux.
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]
@matttbe you mean between the mainline merge of a patch and before the release of a new mainline -rc or new stable/longterm releases containing it?
In that case: guess so.
But FWIW: for really problematic fixes (e.g. Meltdown style) Greg usually immediately releases new versions just minutes after the fix was mainlined, so for those that should not be a problem.
@kernellogger thank you for the reply. If security issues are quickly released, that looks fine. I just hope it will not put unnecessary pressure to the stable team to release any patches with this tag quicker that what is needed 🙂
"'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!'"
I got my ticket now \o/
After fiddling around for 1h, because payment wasn't successful.
Solution was, to take another credit card.
@linuxplumbersconf it would be cool if the registration data was saved, in the case you need to login and log out. It was a bit annoying to retype it multiple times.
"'[…] 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. […]'"
'" 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.
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?