>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
