Getting closer and closer to the point where I'll start a git tree[1] with fixes and reverts for #Linux #kernel regressions in the latest stable series, as from here it seems quite a few of the known problems could quickly be solved by a revert or applying fixes already queued[2]/still under review[3].

[1] ideally in collaboration with the #LinuxKernel package maintainers from distros like @archlinux, @fedora, and @opensuse

[2] https://lore.kernel.org/all/a810561a-14f3-412e-9903-acaba7a36160@leemhuis.info/

[3] https://lore.kernel.org/all/ded3e7ae-6a7d-48b2-8acc-c125874ee09f@leemhuis.info/

@kernellogger @archlinux @fedora @opensuse Could you put me on Cc list if that happens? We might be able to help...

@pavel @archlinux @fedora @opensuse

np, will do so, but right now I really don't want this "to happen"…

2/ In case anyone wonders "why not simply fix the problems in upstream #Linux":

That would definitely be preferred! But in practise this often is anything but quick due to various reasons. Two of them:

* Mainline developers are free to ignore stable #kernels and thus sometimes see no need to fix something quickly when the next mainline release is still weeks away.

* The stable team only applies fixes that were mainlined and thus usually can not fix anything that occurs in mainline as well.

@kernellogger hot take, but I feel like the kernel community needs to be reminded of this more often :) Are you sure what you’re proposing isn’t a workaround for a tooling problem?

One of largest issues with the mailing list workflow is that it’s really hard to keep track of patches, they can’t be labeled and quickly get lost in the constant stream of new emails.

@verdre

Yes, I'm sure that is not primarily a tooling problem, as the way bigger problem clearly is the workflow/motivation problem I mentioned ("Mainline developers […] *see no need* to fix something quickly"): different tooling alone would not make that go away (but of course with different tooling workflows also often get changed).

@kernellogger @archlinux @fedora @opensuse Hmmm... what. Even for a Github issue one week is not a slow turnover time. Maybe I don't understand the context. People have other priorities, are sometimes sick, have holidays and unfortunately shit happens all the time :-)

@jarkko @archlinux @fedora @opensuse

Sure, that will always happen; that's why it might made sense to have a fast track.

But I was talking more about thngs like https://lore.kernel.org/all/87698732-5439-42bd-b2b2-864bb4f3b3ec@leemhuis.info/, where a fix is just sitting in a maintainer tree for three weeks instead of getting mainlined -- in a subsystem with two maintainers, which reduces the chance of "sick, have holidays and unfortunate shit happening" a lot.

[edit: better use this link https://lore.kernel.org/all/a810561a-14f3-412e-9903-acaba7a36160@leemhuis.info/ ]

@kernellogger @archlinux @fedora @opensuse thanks for the link!

I get the issue but sometimes you have to wait that few weeks because between rc's pull requests are more eagerly postponed to the next release. This is not a comment to disregard the issue as a whole :-)

@jarkko @archlinux @fedora @opensuse

"pull requests are more eagerly postponed" -- well, Linus kind of called that "annoying", which IMHO alone is reason enough to work against that practise.

@kernellogger @archlinux @fedora @opensuse

True, I want to be in the loop with this for sure!

@kernellogger @archlinux @fedora @opensuse I.e. I'm just peeking and poking and not fully understanding what is going on. Apologies for my ignorance :-) But if there are open proposals whatnot on this I'd for sure want to be in the loop.

@kernellogger @archlinux @fedora @opensuse

This sounds a bit like a (second?) stable / fixes tree..? Is this not something that could be solved with the stable team?

@gromit @archlinux @fedora @opensuse

Not really, as mentioned in my reply-to-self: https://fosstodon.org/@kernellogger/112337080822568186

@kernellogger @archlinux @fedora @opensuse

Ah I see ... I think the overview at https://linux-regtracking.leemhuis.info/regzbot/mainline/ already give some hint to kernel maintainers or bug wranglers in the distros 🤔

I'll forward the request

@gromit

Thx.

And reg. that page: yup, but I guess there are always a few regressions I'm missing that @archlinux @fedora @opensuse kernel package maintainers are aware of; furthermore they are all in round about the same situation, so collaborating likely would make a lot of sense there.

@gromit @archlinux @fedora @opensuse @kernellogger count me in, always glad to help

@kernellogger @archlinux @fedora @opensuse

Maybe to also expand on my other answer: We (Arch Linux) always encourage people to report upstream bugs to the relevant upstreams or help them debugging the relevant issues by providing them instructions or even prebuilt kernels for the bisection. If there is anything from your side that we could do better feel free to let us know!

@gromit @archlinux [dropping two others]

One of the things I (and I guess some kernel developers as well) always wondered:

How many patches does Arch Linux apply to their default kernel (aka how close to vanilla is it)?

Fedora for example has a list of patches here: https://src.fedoraproject.org/rpms/kernel/blob/f40/f/Patchlist.changelog

Does arch linux have something similar (that ideally does not require one to clone some git tree to get the answer)?

@kernellogger @gromit @archlinux https://github.com/archlinux/linux/releases

@kernellogger @archlinux See the link by @oleksandr, generally its a rather small patchset of like 3 to 6 patches on top of the stable releases.

@archlinux

thx, @gromit and @oleksandr !