X stack + plumbing LTS point updates
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-
* Review tasks left over from https:/
Blueprint information
- Status:
- Complete
- Approver:
- Bryce Harrington
- Priority:
- High
- Drafter:
- Maarten Lankhorst
- Direction:
- Approved
- Assignee:
- Maarten Lankhorst
- Definition:
- Approved
- Series goal:
- Proposed for raring
- Implementation:
- Implemented
- Milestone target:
- None
- Started by
- Maarten Lankhorst
- Completed by
- Maarten Lankhorst
Whiteboard
Kernel:
* 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-
[canonical-
[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