It makes me sad when I see people running into #Linux #kernel mainline regressions and spending time on bisecting them when a simple fix is already available and even spend more than a day in linux-next – like in this case (but it's just one example from today): https://lore.kernel.org/all/61579b26-88b5-428a-b818-5021e528471d@gmx.de/
I wish we would mainline such simple fixes a lot faster, as not doing so just annoys other people and makes them waste their time without much gain. #LinuxKernel
@kernellogger Also arm32 (with arm-none-eabi-gcc compiler e.g. from Arch Linux) compilation has been broken since v6.7-rc1 and is still broken as of today in mainline.
There's also a fix in -next: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=35732699f5d2922ff674e711e566cf44a4bd86d2
@kernellogger Or, like even very small IT companies do, actually use a bugtracker to have a central place to look for bug reports and proposed patches. Ok, ok, I'll see myself out. 😉
"start with linux-next": maybe, but even some kernel devs fear merge window or -rc1 kernels – next is even scarier, so some people are unlikely to go there.
I think we definitely should be sending fixes *for issues like this* to Linus faster, as I can see no real downside once it's been in next. But yes, for some fixes more time can be wise.
sigh; can fully understand this and yes, that is sad, too 🥴
@kernellogger that would make a really huge difference