On Fri, Feb 15, 2019 at 10:49 AM Jeremy Stanley <fungi@yuggoth.org> wrote:
>
> On 2019-02-15 08:23:31 +0000 (+0000), Sorin Sbarnea wrote:
> > Is there something we can do to prevent this in the future?
> >
> > Unrelated to openvswitch itself, it happened with other packages
> > too and will happen again.
> [...]
>
> As in how to prevent distros from updating their packages in ways
> which require some adjustments in our software? That's a big part of
> why our CI system works the way it does: so we know as soon as
> possible when we need to make modifications to keep our software
> compatible with distributions we care about. Hiding or deferring
> such failures just means that we get to spend more time ignoring our
> users who are getting regular updates from their operating system
> and are suddenly unable to use our software on it.

So it's not necessarily hiding it if you can be notified a head of
time and it doesn't disrupt the world.  Yes we need to fix it, no we
shouldn't completely break the world on updates if possible.  Being
able to track these changes earlier in testing is one way that we can
get ahead of the upcoming changes and get fixes in sooner.  I know in
tripleo we use the centos continous release repo + periodic to try and
find these things before it breaks the world. I'm not sure of the
specifics of this change and as to why the continuous release
repository didn't help in this instance.  As a practice I believe we
generally don't like pinning things on master specifically for this
reason however we do need to be aware of the risks to the system as a
whole and how can we mitigate the potential breakages to allow
development to continue while still allowing updates to function as
intended.

Thanks,
-Alex

> --
> Jeremy Stanley