Yeah the 3rd party "we have an old tree and want to maintain it so you need to do extra work to support us, and only us, despite us being the ones getting paid"

Yeah the 3rd party "we have an old tree and want to maintain it so you need to do extra work to support us, and only us, despite us being the ones getting paid" is obnoxious (the reason for maintaining old kernels seems to be invariably a product developer selling products for money, or a value "adder" providing long term "support" for old kernels in exchange for money - and we see here wanting to outsource the actual work for that to the unpaid upstream devs). That said this seems entirely predictable to me, and I'm surprised the author did not simply assume that this would be the outcome given how this nonsense plays out: * If kernel devs adopt "only security bugs get CVEs" the devs get dragged over coals if they ever don't classify a bug fix that turns out to have security implications * What do kernel devs do when they land an architectural change that happens to fix security bugs? * How do you expect them to handle people just watching every fix, who then decide one is a security fix, and give it a webpage and press release when there was no CVE? There's also the fun edge case: the people demanding extra free work from others are wanting to support old kernels as cheaply as possible, but a bug fix in a current kernel may just be a bug fix, while in old kernels the lack of subsequent work in the kernel could mean they're security vulnerabilities. If only "security" bug fixes are meant to get CVEs then either developers have to in essence back port the change and see if the old behavior in the old kernel led to a security vulnerability, or assume all fixes could have security implications in out of date kernels.