The constant churn in some of the driver stacks like graphics leaves us with long stretches of serious regressions. So while 4.14 can be perfectly stable in all

The constant churn in some of the driver stacks like graphics leaves us with long stretches of serious regressions. So while 4.14 can be perfectly stable in all regards and you might appreciate the new features in general code, it's not unusual that something in your graphics drivers gets broken and stays that way for a year or longer. For example Intel's DRM stack wasn't flawless but didn't have as many regressions before they introduced atomic modesetting in 4.2. From there on it's been hit and miss. 4.9 is fine, 4.12 is fine and 4.13 is pretty bad. I have one machine where I'm forced to stay at 4.1-lts. It's atomic modesetting, fences, etc. that caused many gpu regressions. What I'm getting at is that there's no stable driver API or ABI and we're forced to suffer through regressions caused by development to support new graphics stack features or new GPUs, while one's "old" GPU was fully supported and stable in earlier kernels. With more and of the desktop and applications using the GPU for compositing, it's very easy to hang your Wayland or Xorg session for seconds until the driver recovers. This is on top of the many DMAR issues. I don't like using an LTS kernel but I do need stable drivers because without those I cannot use the computer and neither can industrial embedded machines. I admit that it's highly likely that the high churn in the graphics drivers is the cause and it can be singled out, because I don't remember any regression in other drivers. I say it's time to rethink the development model of Linux kernel drm drivers.