Thank you for raising this here, Frank. FTR, this came up in a recent bug where I rejected an SRU for this reason.
Sorry I cannot make the next TB meeting, but here are some thoughts for discussion. On Thu, Sep 25, 2025 at 05:10:36PM +0200, Frank Heimes wrote: > 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.) I'm sure this can be achieved technically, but I think there's more to the matter than just ensuring that release upgrades don't fail. There are two ways of upgrading: 1) the user uses do-release-upgrade (or the GUI equivalent; 2) the user reinstalls and redeploys with the new release. The latter case is much more common in professional production environments. Gating the release upgrader covers the former case but misses the latter. More generally, users have expectations about hardware support and how they relate to Ubuntu releases. If Ubuntu announces that some new hardware is now supported in Ubuntu, users can reasonably expect that the latest release of Ubuntu, as well as the next release of Ubuntu, will also support that hardware. Is a hardware enablement really happening in Ubuntu at all if we do not ensure that this is the case? What is an Ubuntu release supposed to mean anyway, if has to come with the caveat that hardware previously supported by Ubuntu is nevertheless not going to be supported on release day but support might be added later? Is that even a release? Breaking this assumption therefore has consequences for user expectations, and also has implications to effectively _set_ expectations. How are users then expected to understand what features they can expect to available in the next Ubuntu release, and which features will be missing on release upgrade, to either appear later (when?) or possibly never? It seems to me that we need to be very clear to users about this, and the only reasonable way to do this is to *not* claim that hardware is enabled in Ubuntu until it is enabled in all releases following some target release (eg. the current LTS), as is the current rule. That doesn't preclude us from enabling the hardware for Ubuntu users but in a way that makes it clear that it's not a full enablement - such as some kind of preview image or special edition. As discussed, I accept that features do eventually get dropped, but this is quite different from a user perspective. Users understand the distinction between new things being added (in which case they expect the next Ubuntu release to also contain that support) and support for old hardware or technologies being sunset (in which case they expect the next Ubuntu to possibly drop that support). There is no confusion there. My current opinion then is that the current and longstanding policy is exactly correct, relaxing the rule is inappropriate due to the above, and merely blocking release upgrades does not mitigate the above. Robie -- technical-board mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/technical-board
