Kernel Backports security upgrade path

Background: for hardware enablement, we provide updated kernels from newer releases on the LTS
- usually opt-in
- conceivable OEM installs may install the enablement kernel/stack on the LTS

Problem: LTS is 5 years, but non-LTS is 18 months, so if someone chooses an enablement kernel, it will fall out of support before the next LTS

jjohansen:
how to transition people from EOL backport kernels to a supported kernel
- lucid and linux-lts-backport-maverick (server-only)
- precise (desktop and server)
mdeslaur:
This issue likely affects and has impact on other backports, such as X

HWE is not opting in

Options
- just upgrade to the next backport kernel in series
 - problem is that this might break things
- create a super meta-package that does the above and strongly message that people should be using this. This should be messaged in documentation telling how to use the enablement kernel and OEMs told to use this as well.

Lucid - only servers

Precise
- message using rolling

X stack has same problem and will be using a similar enablement stack mechanism

A meta package for Desktop (kernel, X, ...)
A meta package for server (kernel, ?)
An 'enablement' meta package would depend on all the enablement meta-pacakges and should live in the same place as the most complicated stack (eg, X ppa)

where should this live?
- PPAs not mirrored
- new pocket

Work items:
[timg-tpi] make a meta package for the kernel: POSTPONED
[timg-tpi] update-motd notification: POSTPONED
[jjohansen] kernel backports USN notification (essential) (0.5): POSTPONED
[timg-tpi] write messaging surrounding using the new enablement meta package, how to temporarily stay on the new kernel, etc. https://wiki.ubuntu.com/Kernel/Release/Rolling: DONE
[timg-tpi] ensure QA is doing testing of enablement on point releases, https://wiki.ubuntu.com/QATeam/AutomatedTesting/UpToDateKernel : DONE