Ubuntu Wiki

Concept

Historically once an LTS is completed we've not updated the X components beyond the versions included in the release. However, this means that the LTS will not pick up new hardware support over time, and so the value of the LTS for desktop usage quickly diminishes.

Upstream sometimes produces stable minor updates for X.org, but we don't pull those into the LTS. Also, these minor updates tend to be bug fixes, not hardware support so much. So even if we did pull in the stable updates, it wouldn't address the problem.

Meanwhile, we do tend to update the kernel on LTS releases to new major versions. This blueprint focuses on the idea of doing the same with the X.org components.

Another benefit of doing point releases on the LTS is that it allows us to be more conservative in the release itself with the versions we select.

Design

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.

We will be backporting the X stack from future non-LTS releases to the LTS release point releases.

The point releases occur at 6-month intervals starting 3-months after release. Since there won't be a stable non-LTS release at the 3-month mark, this means we will shoot for the following schedule:

This will be kicking in at the point 2 release.

• What is the best way to distribute the updated X stack?
  • - renamed packages so both can co-exist in same archive
  - Upgrade case is to keep people on the same series they installed with. Package names addresses that.
• Should we limit it to just the serverside portion of the X stack? (I.e. omit libX11, etc. to avoid breakage to client apps)
  • - Yes
• For certain graphics cards, there is a possibility that driver support could be dropped in future kernel and X combinations; the upgrader will need to be aware of this and not suggest the upgrade if it won't work, or perhaps make them aware of the risks or known-regressions they'll endure if they wish to proceed anyway.
• Should a way be provided to enable the user to back out the changes? If so, how should that be implemented?
• How tightly should the kernel / X package versions be kept? I.e. should we discourage or permit old-kernel/new-X and/or new-kernel/old-X setups. (If we permit these combinations it gives user flexibility but imposes a larger testing impact).

For security updates, permit upgrading to the Q, R, S, and T stack; T is the next LTS so that will leave them on a longer term supported stack. However, we don't auto-upgrade people from .2 to .3, so since the Q stack would only be supported 18 months (15 months after .2 release) this could conceivably leave them unsupported, if they choose not to upgrade to the .3.

• Once security support is gone for that point release, we upgrade you to the next one that is security supported (up to T). We make best effort for ensuring the hardware support on that latter release.

Installing from the point releases will install with the updated X stack.

Mesa already has the alternatives system so should be able to use that for the update

Implementation

Testing