Hello, thank you for the review and sorry indeed for anything we have messed up.
I think the biggest issue is that we we were not aligned with the SRU process here, and we thought that the specific cases of SRU'ing backporting an entire version would be okay like that. So, as the docs mention: > Any deviance from the ideal SRU must be called out and justified We've tried to do that, but it was probably not clear enough. This package is used by CUDA maintainers (us) to work on CUDA. It required some adjustements for future versions to come. - cuda-crt-13-1 is blocked in proposed because of this (and it's rather a critical one in regards of CUDA) - all cuda 13-2 SRUs, currently in the unapproved queue will also benefit from this SRU - all cuda 13-3 SRUs, yet to be submitted after 13-3 is accepted in stonking, will also benefit from this SRU And Andreas said in the SRU template: > Cherry-picking does not make sense, because all of these additions will be required for the future CUDA 13-2 SRU That meant "We would like to backport the version from stonking entirely, instead of disassembling the update in patches". We require the same version than in stonking anyway, so backporting seems safer and easier for everyone. We don't have a SRU exception for this. We have a drafted one [0] but it was said at some point that the SRU team would prefer to see some actual SRUs before delivering an exception, so that there is more context. That make sense. That being said, it'd seem right to link the several bugs that this upload fix. We should have thought of that. However writing 4 SRU templates instead of one does not feel right. What do you think? Taking an SRU from autopkgtests as example [1], I did reference LP bugs in there but did not write more than one SRU template. I did not use `v$VERSION` which I just learnt about, thank you for the tip. What would be the implication of using that? Would it be the same as just reporting everything in one changelog entry, but in a cleaner automated way? If you still prefer that we open multiple SRU template we can do it, but I'm confused in understanding why we would need that. I would rather test all relevant bugs in this SRU template (which is not the case in the SRU template as I read it now). [0] https://github.com/ubuntu/ubuntu-project-docs/pull/517#discussion_r3008253236 [1] https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/2144629 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2164908 Title: SRU: Update to upstream 1.0.4 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-cuda-packaging-tools/+bug/2164908/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
