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].
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]: 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
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
