On Wed, Jun 25, 2025 at 01:27:33PM +0200, Christian Ehrhardt wrote:
Hello everyone o/
Hi Christian,
I wanted to update all of you about an effort that tries to further minimize regressions due to the SRU process [1]. A few weeks ago, at the sprint in Frankfurt we realized - to no surprise - that there is a bigger chance of regressions when complex updates land. In a discussion about what broke teams over the recent years it became clear that all mentioned examples have been from the list of special cases [2].
Were there any discussions on whether this was due to these having special processes for their SRUs or due to the frequency these updates are rolled out? I understand that in some cases (such as Docker) we explicitly state that backwards compatibility may not be met for some updates, therefore, we should indeed do a better job communicating those updates/changes.
Many teams have worked on improving this over the years, some established regular CI, others have tests they can run semi-automatically. But it turned out what was mostly missing, was getting a heads up when new changes are about to land and thereby implying it is a good time to test. We have been discussing what could be a low overhead process to achieve that. After all not everybody is interested in everything - nor was anyone keen to hard commit to returning a verification result in a timely fashion. What we came up with, and now starting to experiment with and discuss, is essentially a simple subscription model. Yes, you could just subscribe to the source package, but many stated that they had a hard time filtering such traffic well, losing the signal in the noise. Based on the meeting we had I've collected the teams and what packages they are interested in. But that is only a starting seed for this - anyone else is welcome to join as well (the used launchpad groups are open). Out of that I have created open interest groups on launchpad: - https://launchpad.net/~sru-verification-interest-group-landscape - https://launchpad.net/~sru-verification-interest-group-snapd - https://launchpad.net/~sru-verification-interest-group-containerstacks - https://launchpad.net/~sru-verification-interest-group-openstack - https://launchpad.net/~sru-verification-interest-group-cloud-init - https://launchpad.net/~sru-verification-interest-group-postgresql - https://launchpad.net/~sru-verification-interest-group-grub - https://launchpad.net/~sru-verification-interest-group-ubuntu-pro-client Yes there are more special cases [2], but those represent what people have been interested in so far. Once we agree others can be defined and added following the same pattern. Those groups are gonna be subscribed to related SRU bugs and therefore would only get traffic when an SRU is about to happen. On the respective SRU exceptions documents I'm about to add a paragraph about it, which is up for review [3]. Thanks for reading! I'd be happy to get your input either as reply to this mail or as comment on the merge request [3].
+1. Thanks for putting this up!
[1]: https://documentation.ubuntu.com/sru/en/latest/ [2]: https://documentation.ubuntu.com/sru/en/latest/reference/package-specific/#reference-package-specific-notes [3]: https://code.launchpad.net/~paelzer/sru-docs/+git/sru-docs/+merge/487759 P.S. I have added the usual drivers of the packages that are affected to CC to make it more likely they are aware of this. -- Christian Ehrhardt Director of Engineering, Ubuntu Server Canonical Ltd
-- Athos Ribeiro -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
