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
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
