Comment 18 for bug 1206387

On Mon, Dec 02, 2013 at 10:31:26PM -0000, Russ Allbery wrote:
> I will say that this is the serious problem with accepting new kernels
> into a stable release. If you accept a new kernel version but don't
> accept new upstream releases of all the separately-packaged kernel
> modules, you basically break all those packages for stable users. I had
> that concern when Debian was talking about doing the same thing in stable
> releases. You can require backporting of just the kernel compilation
> fixes, but often that's quite a lot of work and it ends up just not
> happening, so the packages just stay broken for users.

The kernel hardware enablement policy takes this into consideration, and
does not push new upstream versions of the kernel to users who installed
from older media. Only if you use the new point release media, or
explicitly opt in to the new enablement stack, do you get the newer kernels.

  https://wiki.ubuntu.com/Kernel/LTSEnablementStack

Even without considering third-party modules, we certainly don't have the
resources to guarantee that a new upstream kernel version will cause no
regressions for our users - every new kernel upstream release is likely to
regress support for *some* subset of older hardware. The compromise, in
order to enable newer hardware on older LTS releases, is to continue to
support users installing from older media.

If you have newer hardware that requires the newer enablement stack, it's
better to have it available than not, even if that means some out-of-tree
modules are not available. If you don't need the new enablement stack, then
it's recommended that you use the LTS kernel.

And if there's sufficient demand for openafs support on top of the hwe
kernels, then we're happy to facilitate that, but it needs to be done in a
way that is equally low risk for users of the LTS kernels.