We really need to be able to keep separate kernels for rolling and LTS.
When we had no LTS, this was not a problem at all. When we did, but didn't use so many out of kernel drivers, it was an acceptable headache since you only needed to import one package into the LTS branch.
Now we (and guess who I mean by "we"? ;) have to manually import a whole bunch of packages from rolling when we make LTS maintenance releases, including multiple Intel modules, wireguard, accel-ppp, and of course the kernel itself. That's a tedious and error-prone process and it backfired multiple times already.
Worse yet, since we have no per-release kernel branches, and always download the latest upstream drivers, when something turns out to be broken, post inclusion into LTS, we have no way back. And we have no way to store multiple package versions since reprepro cannot do it and tools that can are orders of magnitude harder to use and poorly documented.
That's not to mention that having the very latest kernel in an LTS release is not always desirable.
I suggest the following:
- Create per-release branches in the kernel repo
- Parameterize the kernel build pipeline with a branch like all other jobs
- Devise a procedure for automatically importing upstream modules into git repos and tagging them, so that we can go back to an older release if needed