> Thank you for raising this here, Frank. Thanks for taking the time and responding to this. > > FTR, this came up in a recent bug where I rejected an SRU for this > reason. I think there are meanwhile multiple SRUs that are stalled right now due to this. Means there are bugs that need fixing - which is the main reason for the suggested approach to find a solution for getting us out of this situation and moving forward. > > 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. The main aspects that were brought up in the above mentioned SRU case discussion(s) were about the (partial) inability to test on newer releases and esp. the fact that upgrade regressions might happen - hence this seemed to be the main aspect that needed to be addressed. > > 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.
Sure, installations (re-instalation) are another way of getting Ubuntu deployed, but I think that both cases (installation as well as upgrades) are rare for the audience and devices affected here (let's say compared to a workstation), and that they are often just installed only once in their life-time (except development systems). Certain devices are even supported based on a pre-installed images (img.xz) that need to be flashed on the devices, like: https://cdimage.ubuntu.com/ubuntu/releases/22.04/release/nvidia-tegra/ However, that should not mean that we shouldn't care about the situation at install time. I just think that we barely do that in any other case atm. If desired this could be introduced on top - as an addon to the installer (or maybe based on a similar technique that is used in ubuntu-drivers). But since I assume that this req. a roadmap item, it'll take time to get implemented, I am still convinced that an SRU expection would be needed mid term to unblock the affected SRUs. I would also expect that users follow common sense and have a look at the documentation of their device first before kicking of an installation (in case it's really an install and not a pre-installed image). The documentation for these partner devices will guide users appropriately. As an example on our side: https://canonical-ubuntu-for-jetson.readthedocs-hosted.com/how-to/flash/ also referenced on the partners side: https://canonical-ubuntu-for-jetson.readthedocs-hosted.com/classic/installation/ While I agree that users should be guided to do the right things (and prevented from ending up with a bricked system) if they follow standard procedures and steps, I doubt that we can prevent them from any possible issue. > > 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. Please note that this is about a very special set of use cases and about a relatively small subset of users, compared to the overall Ubuntu community. > > 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? The definition here is "certified" for Ubuntu xx.yy. Ubuntu xx.yy was enabled on/for a certain device and afterwards also "certified", like in this example Jetson AGX: https://ubuntu.com/download/nvidia-jetson#jetson-agx-orin And Ubuntu certifications are granted for individual Ubuntu releases. That means if an Ubuntu certification was done for a device A on Ubuntu 22.04, it does not mean that follow-on versions are automatically certified as well - only if the certifications were redone on the newer releases. > > 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? The assumptions for the special user segment that is going to be addresed here are based on the official documentation that clearly states what to expect, means which Ubuntu release was certified and with that the Ubuntu release that need to be used. So the assumptions for such user segments are different compared to the assumptions of a general Ubuntu user - not much will change for the general Ubuntu user set. > > 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. I personally think that we are pretty clear about this, based on the example URLs provided (which can even be clarified more if needed). Like written above, the base for the "support" is the fact that a device was officially certified (by Canonical). > > 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. Right, but we do not talk about full enablement, rather than about "certification" of a certain device for a certain Ubuntu release. The needed packages for this are in the Ubuntu archives, hence need to be maintained (SRUed) over time, which is the main reason for this tHWE request. > > 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. I agree with you that the policy is good and no general (back-) door (or so) should be created and opened. Please note that the ask here is for an exception that allows to go forward today, alowing to maintain packages that are already in the archive today. The goal is still (and hasn't changed) to have averything needed that is req. for a certain device in _all_ Ubuntu releases. But this is unfortunately not always possible (at day 1 of a release), since external parties are involved. > > Robie BR, Frank On Tue, Oct 7, 2025 at 7:00 AM Robie Basak <[email protected]> wrote: > 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
