X stack + plumbing LTS point updates

Registered by Maarten Lankhorst on 2012-10-09

Canonical has announced a new 5-year LTS support policy for the Ubuntu Desktop which will provide updates to X, drivers, and necessary plumbing layer components to provide support for newer hardware in the LTS.

There are still some open questions on implementation though, so additonal discussion on the implementation is warranted.

* What packages will be backported unrenamed?
- Discuss xserver-common, libxrandr, xrandr, x11proto-* as needed, wayland, llvm-3.1, libdrm (with intel patch re-instated for arm?)

* Review and sru changes to build current xxv packages against newer libdrm
- mesa, xserver-xorg-video-nouveau are affected, maybe plymouth as well

* Review tasks left over from https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates

Blueprint information

Bryce Harrington
Maarten Lankhorst
Maarten Lankhorst
Series goal:
Proposed for raring
Milestone target:
Started by
Maarten Lankhorst on 2012-11-06
Completed by
Maarten Lankhorst on 2013-01-23

Related branches



* For the 12.04.2 DVD's, we will default to the new Quantal enablement stack.
[TBD] For the 12.04.2 DVD's, if investigation can confirm we can support providing an option to allow users to remain on the original Precise stack, we will provide this as an option. Otherwise DVD's will only provide the newer enablement stack.
Decision: won't have both stacks on the DVDs. Just the newer stacks. People who need the old stack will need to use 12.04.1 instead
* Only support 12.10 X w/ 12.10 kernel
* People upgrading to precise won't be pulled into the new enablement stack
* Still supporting original precise stack for 5 years
* Won't be rolling forward from Q stack to R stack to S stack. Instead maintaining separate offerings.
* There is a 3 month gap of support from 12.10's release and 12.04.2's release. Meaning the 12.10 enablement stack will only be supported for 15 months more.
Decision was to support for the extra 3 months as necessary (eg Q stack all the way to 14.04 release).
At shortly after 14.04 release they will be rolled to the 14.04 enablement stack, but not moved to the full 14.04 release. Not the release kernel, but rather the first SRU kernel from 14.04.
* [TBD] Anyone running an R or S enablement stack in Precise might have an unexpected result if they upgrade their entire system to Quantal. The packages offered in the R/S enablement stack would supersede the Quantal packages. This still needs further discussion for an appropriate upgrade policy/expectation for anyone in this scenario.
Decision: Will probably creatively break but would need testing. P has it set for LTS to LTS upgrades, so they'll have to really want to go to Q / R /S if they try to upgrade.
* If someone is on the S stack, should they be moved to the T stack when 14.04 comes out?
No you shouldn't be moved to the T stack until S stack is unsupported.
They would still be prompted for 14.04.1 though still.
X Specific Questions
* xserver-common. Complicated situation where don't want to rename this package. Will require some more thought. Maybe diverts to handle instead.
* libxrandr xrandr. Library should be renamed. Shouldn't SRU in new versions of the utils. Need an alternative solution, alternatives, renamed binaries etc.
* libdrm can't be SRU'ed as it stands. Need to go through tech board if it's required. Instead the updated one should be coinstalled. This will cause intel-gpu-tools to not use new features, but this should be OK.


Work Items

Work items:
[canonical-kernel-team] Test installing S from CD over the top of an R enablement stack: TODO
[canonical-kernel-team] Have update manager try to keep people from upgrading in scenarios from P w/ enablement stacks to Q. Guide them to a wiki instead that explains more intelligently what they should do: TODO
[leannogasawara] coordinate with PES to Make sure the Q enablement stack is messaged correctly that the user WILL be upgraded to 14.04 enablement stack at the Q enablement stack's EOL (shortly after April 2014). And ditto for subsequent stacks: TODO
[leannogasawara] message Q's enablement stack support window (ie auto upgrade to T after T's first SRU cycle): TODO
[leannogasawara] ask foundations how will phased updates come into play when upgrading enablement stack: TODO
[brad-figg] help QA integrate xorg enablement stack into testing: TODO
[mlankhorst] Examine use of diverts for xorg-common: DONE
[mlankhorst] Decide on xrandr / libxrandr renaming (or alternatives?): DONE