Hi Robie,
On Fri, Mar 28, 2025 at 12:45 AM Robie Basak <[email protected]> wrote:
> Hi Shane,
>
> On Thu, Mar 27, 2025 at 08:19:44PM +0400, Shane McKee wrote:
> > Thanks for the review. Responses to your questions inline below.
> >
> > > 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.
> >
> > Each project requested handles release versions slightly differently, but
> > we are not requesting any particular type of upstream release. Enablement
> > efforts would focus on bringing in the latest stable, tested version of
> > each package with support for the new hardware in question.
>
> What are we trying to achieve here? We can certainly help to match
> expectations by discussing this, but if you cannot limit your request to
> any particular type of upstream release, then I don't think the SRU team
> can grant any particular type of standing exception to our existing
> policies and procedures. If that's what you're looking for, then I think
> you need to narrow it down - otherwise every upload will have to be
> discussed case-by-case.
>
> As an extreme example to try to illustrate what I mean, if a request
> were "we'd like to upload anything we like without any kind of
> scrutiny", then the obvious answer would be "no".
Agreed, and that's certainly not the intent here. We understand that we're
asking for increased power to make changes, which comes with the increased
responsibility to prove that we have done our due diligence. If we have not
done so, our expectation is that our request will be rejected until we can
add further assurances that we will not disrupt the stability of an LTS
release.
> On the other hand, if
> you said you'd like to routinely update bugfix-only releases from
> upstream, then we might examine upstream's published policies and
> reputation, agree that they match our users' expectations, agree and
> document what of those upstream policies we're relying upon and what
> will need to be reviewed for in every upload, and then such SRUs would
> go more smoothly.
>
> So I think we need to narrow this down please before we can really
> proceed further.
>
We already have a quarterly release schedule for Mesa (part of the graphics
stack but not covered in this HWE since it has its own HWE arrangement),
and we adopt Q1 and Q3 releases in Ubuntu to meet feature freeze deadlines.
The Intel media driver also has a quarterly release cadence, so we plan to
do the same if we need to perform a HWE for a new platform which cannot be
enabled via the usual SRU backporting process (which we will use whenever a
backport is safe and practical as seen in LP: #2104011).
To align on a schedule for HWE cycles, Intel agreed to provide versions of
compute runtime and level zero which would align with the quarterly
releases for Mesa and the media stack. This means that the following
packages will enable new hardware by following Mesa’s current update
schedule:
* Intel Media Driver
* Which uses specific versions of libva and intel-gmmlib
* VPL GPU Runtime (onevpl-intel-gpu)
* Which uses specific versions of libvpl, libvpl-tools,
intel-media-driver, intel-gmmlib, libva, and libva-utils
* Level Zero
* Compute Runtime
* Which uses specific versions of intel-graphics-compiler, level-zero,
intel-gmmlib, and level-zero-gpu-raytracing
* intel-graphics-compiler requires a minimum version of
intel-vc-intrinsics
* level-zero-gpu-raytracing requires a minimum version of onetbb
I’ve hinted above at another point that I’d like to address: We don’t want
this to be the only way we update graphics packages. We understand why the
process is centered around smaller changes to LTS releases, but we also
urge that HWE backports can be less stable and less efficient at the same
time if they deviate too far from the original versions. To ensure that
packages are updated in an agreeable manner, we propose the following
update methodology:
Does the proposed version bump enable hardware or fix a high-value,
time-critical bug?
* No - Result: The proposed version bump should be kept in the Intel
Graphics Preview PPAs
* Yes
* Is it feasible to backport the changes to the current version without
sacrificing stability? For instance, adding PCI IDs would be a “yes”
* Yes - Result: Backport patches and submit a regular SRU
* No - Result: Proceed with HWE update process
Thanks,
Shane
--
Ubuntu-release mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
