SRU requirement to fix post-LTS stable releases

[Robie Basak]

On Thu, Jan 20, 2022 at 07:10:53PM +0000, Robie Basak wrote:
> On Wed, Jun 16, 2021 at 02:11:36PM +0100, Robie Basak wrote:
> > Imagine you land a bugfix in an SRU to Focal today, but leave out
> > Impish even though it is also affected. A user who subsequently
> > installs Focal, benefits from the bugfix, and then upgrades to Impish
> > will be regressed. Is this acceptable?

[...]

> If a bug is being fixed in a particular stable release, we would like
> for all subsequent releases that are still supported to also be fixed at
> the same time. This is to prevent a user from facing a regression when
> they upgrade to a newer release.

Recently the SRU team has reviewed some uploads where the SRU is for the
purpose of hardware enablement, but the uploaders are enabling Jammy and
have not considered Lunar.

In the previous discussion I had been thinking generally about bugfixes
and not about hardware enablement.

For hardware enablement purposes, the situation would be worse. A user
might install the LTS on which their hardware works, then do a release
upgrade to a newer interim release and fail to boot. This is much more
severe compared to the reappearance of a typical SRU'd bugfix.

AIUI, HWE kernels don't have this issue because they are always
backported from newer releases and the timing means that an interim
release that doesn't have support for some hardware will have EOLed
before the LTS hardware enablement from a subsequent release happens.

Currently the documented policy doesn't discuss the hardware enablement
case because I don't think it occurred to anyone that this needs to be
considered separately.

Consensus amongst the SRU team is that for hardware enablement purposes,
fixing subsequent interim releases first (or at the same time) needs to
be mandatory to prevent a serious regression on release upgrade. This
seems to have always been the position, but it wasn't explicitly
documented. As always we can consider exceptional cases, but our
baseline policy should define this as a requirement.

I will document this now, but raise it here so that if Ubuntu developers
disagree then you have the opportunity to object.

Thanks,

Robie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20230929/38e3bfa1/attachment.sig>