> given that this also could qualify as an HWE upload as explained? On your "HWE exception" claims, let me be clear. If an SRU upload *contains* a hardware enablement as part of other changes, that does not automatically give the other changes a free pass. The other changes would require SRU justification on their own merits, or else they must not be included as part of the SRU. Further, the "HWE exception" merely states that hardware enablement is a valid reason for SRU. It is still subject to the usual requirement to minimise regression risk and therefore the requirement to minimise changes and specify (and have accepted) an appropriate QA plan.
On "accepting this microrelease", let me be clear again. This is *not* a microrelease from our perspective, since it contains feature changes. Or at least I think it does, given the release notes you linked. I would appreciate if you could stop throwing those terms around as if they grant you free passes through SRU policy without a further explanation of how they apply, given that it appears that they do not. Further, https://docs.nvidia.com/doca/archive/2-9-1/changes+and+new+features/index.html has a section on "Backward Compatibility Breaking Changes in this Release" that says "...and therefore require customers to upgrade all DOCA software components to the latest available version to avoid anomalous behavior". mofed-modules-24.10 is just one of those software components, right? What if a user is using other software components, and then updates this one. Will they face a regression? > It is both. According to the upstream changelog [1], it contains the following HWE features: > > Added support for OVS-DOCA live upgrade of virtual switch This sounds like a new feature, not a hardware enablement. > And the following bug fixes: > > Description: rte_eth_dev_start() performs unnecessary recreation of mlx5 control flow rules, resulting in increased delay of rte_eth_dev_start(). You can get regular bug fixes qualified for SRU in one of two ways: 1) a minimal cherry-pick with a test plan that validates the specific fix being made, normally tracked in its own bug; or 2) by taking the whole upstream (not-micro, it seems)-release, but demonstrating how quality will be maintained by showing how upstream meets our quality requirements documented at https://documentation.ubuntu.com/sru/en/latest/reference/requirements/#new- upstream-microreleases On testing: We've long required that the testing to be performed can be performed by anyone suitably competent, mainly because we get so many SRUs that get accepted but then the available testers disappear. It's OK, and fairly well accepted, that if specialist hardware requires testing then only limited people are going to have access to be able to do that, and we've accepted assurances that those people are ready to perform the SRU verification as enough in the past. It's also great if a third party reports a regression with a high quality bug report, regardless of their possible use of a private test suite that alerted them to it. We should encourage this if they have that ability but cannot contribute it, just as we should encourage contributions to improve public test suites. However, I think we're in different territory if the *only* QA that can be performed is done in private. This has implications such as: is what we're shipping really Free Software, if code essential to us releasing updates is missing? If not, then should this package be in restricted or multiverse instead? This seems like an important policy question for the project. A possible mitigation might be to consider that this is being one only for packages tied to specific hardware and the private test suite is owned and operated by the hardware manufacturer, and perhaps require that we have their agreement and cooperation. In that sense, it feels similar to the type of pragmatism with which we ship non-free hardware drivers. But in that case, perhaps restricted/multiverse *is* the appropriate place? However, this is not the only outstanding question here. I think you still need to qualify the feature and potentially breaking changes you propose to make, and demonstrate that they are suitable for SRU, as I've covered above. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2100003 Title: backport mofed-modules-24.10 24.10.1.1.4.0-0ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mofed-modules-24.10/+bug/2100003/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
