RFC: SRU Exception for transitional hardware enablements (tHWE)

[Frank Heimes]

Hello everyone,
like discussed and decided in the last TB meeting on Sept 23rd, this is a
request for comments for an "SRU Exception for transitional hardware
enablements (tHWE)"

Problem Statement
Teams (such as Canonical Partner Engineering, PE) want to enable new
(optimized) partner platforms on existing stable releases, which partners
may not support on later versions yet (see for example 1) and 2) but more
exist). They may require specific kernel patches, or additional user space
components. This poses a problem with the SRU requirement that a problem
fixed in an SRU, must be fixed in all newer Ubuntu releases first.

Proposed approach
Proposal is to waive the SRU requirement that the platforms need to be
enabled in all newer versions first 3), provided that appropriate measures
are taken to prevent release upgrades on affected platforms - in
particular, a "quirk" for the ubuntu-release-upgrader. This ensures that
users are not able to upgrade to a newer version of Ubuntu where their
hardware is not supported (i.e. where the optimized kernel is not available
in the target release of an upgrade attempt).
(This exception is meant to be for optimized kernels and potentially
depending user space components of partner platforms only.)

An approach that can be considered is adding a new field to packages that
must be upgraded when upgrading to a newer version (be it interim or next
LTS), for example, the (optimized) kernel meta packages. If these packages
are not available in the target release, ubuntu-release-upgrader must fail,
with an appropriate message.

The expectations (i.e. the supported Ubuntu releases) are usually known to
partners and users and are well documented (like 4) ), so this does not
come as a surprise.

Alternatives considered
We considered enabling partner platforms via a separate archive. This would
allow isolating them from Ubuntu proper, and work around the entire Ubuntu
policy. However we believe that the transitional hardware enablements
benefit from the scrutiny and transparency of being in the main archive, it
does allow the Ubuntu teams to weigh in on these enablements and ensure
they otherwise live up to the usual Ubuntu standards and also encourages
partners to close potential gaps quicker.

In particular, shipping packages in a separate repository makes it somewhat
harder to introduce a quirk mechanism like is being proposed here, and
would result in users being able to upgrade when they shouldn’t, subverting
user expectations more by just breaking on them.

Please let us know if you have comments, suggestions or thoughts on this!

BR, Frank

PS1: The reasons why newer versions are not (yet) supported are manifold,
to name a few:
patches not forward ported, not all patches accepted upstream, limited
resources, tests not completed, binary drivers not yet provided for newer
release, ongoing/outstanding certification and more.

PS2:
The mid and long term goal is *still* to bring everything needed (optimized
kernel and potential user space components) into all newer releases (be it
interim or LTS).

1) https://launchpad.net/ubuntu/+source/linux-nvidia-tegra
2) https://launchpad.net/ubuntu/+source/linux-mtk
3)
https://documentation.ubuntu.com/sru/en/latest/reference/requirements/#reference-general-requirements
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20250925/d8c1337a/attachment.html>