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
-- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
