Proposed addition to the HWE stack

[Robie Basak]

Hi Shane,

FTR, there's a related discussion happening in
https://bugs.launchpad.net/ubuntu/+source/intel-gmmlib/+bug/2098413

For a more general documented special case, I think there are some other
things we need to specify.

First, you haven't said what kind of upstream version / release policy
exists, what that means for users, and which type of upstream releases
you want included. For example, will you expect to SRU a major version
bump from upstream? Does upstream release policy allow such a release to
change behaviour for existing users? What about upstream policies on
dropping (or not) support for existing hardware that they might consider
EOL? What assurances can Ubuntu users have that *their* hardware won't
regress in support as a result of an upstream decision that Ubuntu, as a
distribution, is supposed to insulate our users from?

For example, something I think we must avoid is to do a version bump in
an SRU and then get a user bug report telling us that their hardware is
regressed, only to find that upstream made a deliberate decision to drop
support for that hardware because they consider it to be EOL, and we
didn't notice. If we're going to take new upstream versions into our
stable releases without further review, we must have some assurance
that, through our process or documented upstream policies as
appropriate, that situation cannot arise.

How does this apply in the context of your statement "The smaller
projects listed are dependencies of the larger projects, so full version
bumps will be needed in order to meet minimum build requirements"?

Along similar lines, since these SRUs are for hardware enablement,
what's the hardware testing matrix you intend to use? Are you relying on
sampling, or do you intend to test against all hardware that you have
previously "enabled"? How will you ensure that support for older, more
obscure hardware will not be regressed?

> Major changes should be called out in the SRU template, especially
> where changed behavior is not backwards compatible.

How do you intend to detect these cases?

What is upstream's test coverage like, especially for the dependency
packages? Our normal requirements to take upstream microreleases are
documented at
https://documentation.ubuntu.com/sru/en/latest/reference/requirements/#new-upstream-microreleases.
Are those conditions met for all of the packages listed?

The resolution for my comments in LP: #2098413 also need incorporating
into this document once they are resolved; no need to duplicate that
discussion here. This includes ensuring that the test plan is public, we
do not SRU "partial" enablements by only testing parts and not the full
deliverables, etc.

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-release/attachments/20250220/ac608031/attachment.sig>