Comment 19 for bug 2002429

On Fri, 19 May 2023 at 00:30, Chris Halse Rogers
<email address hidden> wrote:
>
> Hm, maybe I've been unclear.

You are trying to apply mechanical reasoning without looking at the
fix in question.

The combination of users you are alluding to who may experience a
regression is zero, in this instance:
- userspace code is unaffected
- kinetic+ requires 5.19+ kernels,
- 5.19+ kinetic kernels can only be built with gcc-12 due to security
features that require newer toolchain
- the only affected combination of users is jammy building v5.15 kernel

Separately, we ensure no regressions of default versions of toolchains
between release upgrades, and we frequently do not ship neither
security or fixes to non-default toolchains.

>
> What I mean is: while the launchpad buildds don't use gcc-11 for
> anything in kinetic onwards, launchpad buildds aren't the only users of
> a compiler and the Ubuntu kernel is not the only thing that users of a
> compiler might compile.
>
> gcc-11 is a package available in the archive, and users can use it¹,
> regardless of the particular rationale that *we* have for including it
> in the archive. If a jammy user is deliberately using gcc-11 I would
> expect that upgrading to kinetic would not regress any fixes we've made
> to the jammy package.
>
> I don't *think* we have a policy that non-default compilers are not
> subject to the usual SRU policy? If we do, maybe that should be better
> communicated :)

Nature of the bug, and the fix, guaratee no regression to any users
upon dist-upgrade, even if they choose to use gcc-11 by force.

>
> Again, I'm OK with deciding to tell users of gcc-11 that to get this fix
> they need to either stay on Jammy or upgrade all the way to Lunar. I
> just want to make sure that we've actively decided to tell users this is
> unsupported, rather than just verifying that it doesn't affect *us*.
>
> ¹: Maybe they're working around a gcc-12 miscompilation, or don't want
> to revalidate gcc-12 just now, or just like the number 11.
>

SRU fixes can be released in LTS release without being prepared or
released yet in the interim releases, especially since they are fixed
in the devel release already or even non-applicable. We do this all
the time.

For example python3.8 is default in main in some releases, but not
others. The one that is in main gets security fixes in the Ubuntu
Archive, the one not in universe doesn't receive neither SRUs nor
security fixes, and only receives Pro updates.

Similar for all compilers we ever shipped.

Note, your reasoning is flawed, and doesn't stand the test of time.
Demanding a fix for kinetic is pointless, given it is old release
which is about to go eol, and the package in question is unused is not
affected, and the regression is not present in the default compiler.