Mastodawn

Thorsten Leemhuis (acct. 1/4)Sep 2, 2024

Can you come up with convincing *stats* on why backporting a huge pile of patches (say 800+, like in the case of #Linux 6.10.3) to stable #kernel series just days after being mainlined *during the merge window* and thus included in a mainline -rc1 is *worse* than quickly backporting changes mainlined *during the rest of the development cycle*?

Then tell me about it, because then I'll bring this up on the maintainers summit while talking about #regressions.

1/ FWIW, this is what I tried: I…

Show thread

Thorsten Leemhuis (acct. 1/4)Sep 2, 2024

2/ …looked at the mainline changes backported to the 6.9.y series and then checked if they were referred to in a Fixes: tag found in another mainline change committed within 9 weeks (e.g. one cycle).

There the -rc1 commits did not stand out.

The only problem thus was the number of changes, which of course makes it more likely for users to be affected by regression.

Screenshot in the first toot of the thread if from https://lwn.net/Articles/863505/

The core of the -stable debate [LWN.net]

Show thread

Vegard Sep 2, 2024

@kernellogger A priori, I would expect the rate of _fixes applicable to older kernels_ to be independent of where in the mainline cycle you are. Doing a quick grep on 5.15.y tells me that the number of commits from newer mainline -rc1s is about 8x the numbers compared to other -rcs. It would be interesting to know WHY. Are maintainers delaying fixes until the merge window? That seems wrong.

Show thread

Steven Rostedt

@vegard @kernellogger my own experience is that after I add a new feature during the merge window, I'll get a bug report that was actually from an older change before the merge window. Why did this happen? Because the new feature started stressing code paths that were not stressed before and uncovered bugs that existed for a long time. Hence you may see more bug fixes for old bugs early in the rc releases.