Hi Corey, On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant <corey.bry...@canonical.com> wrote:
> Hi Robie, > > Thanks for taking a look. > > On Wed, Aug 30, 2023 at 9:34 AM Robie Basak <robie.ba...@ubuntu.com> > wrote: > >> Hi, >> >> As a list of 46 packages this is rather large and non-trivial to review. >> Presumably we'll want to group them by upstream (are all managed by the >> OpenStack umbrella upstream, or are there exceptions?) and then take a >> view on them as a whole. >> > > All of the packages in this list fall under the OpenStack umbrella > upstream. The source can be found at: https://opendev.org/explore/repos > All of these packages were specifically chosen because they are > dependencies of the existing packages in our SRU exception list. > Could you also check the reverse dependencies of these packages in the Ubuntu Archive, to see what, if anything, other than openstack, might be using them? If we start updating them to new upstream versions, albeit still within a stable release track, we might be affecting their rdeps. And given the example from Robie below on python-ovsdbapp, when he analyzed python-ovsdbapp, do you think you would be able to highlight usptream changes in behavior, if they exist, in the future SRUs? In general, MREs should not have those, of course. > On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey Bryant wrote: >> > python-ovsdbapp >> >> This one was in the queue and so I reviewed it independently as >> requested as a one-off microrelease update SRU. I ended up rejecting it >> as there was what looked like a behavioural change with no explanation >> as to why it is required, and most other upstream bugfixes did not come >> with tests. Details at: >> https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19 >> >> I'm noting this in this thread for the record in case this has any >> bearing on the larger view. >> > > For the behavioral change [1], I think there is minimal regression > potential as the change is limited to an exception path where sleeps and > reconnects were determined to be unnecessary. I'd have appreciated it if > they would have provided a bug reference for the commit to provide more > context, however with that said, it seems they are making a code > improvement here for performance reasons and they found it to be useful > enough to backport to stable branches. > [1] > https://opendev.org/openstack/ovsdbapp/commit/ab3e0cb0d0865417efbf103f44954573a5ba92ac > > It is certainly not ideal to have missing unit tests. It's important to > consider that we perform testing above and beyond the unit tests that are > run as part of our package builds. The regression testing that we have in > place for OpenStack is run for all stable releases. For that we deploy a > full OpenStack cloud and then run tempest integration tests that exercise > all of the packages and the cloud solution as a whole. > > I think we have a solid history of limiting regression potential for > OpenStack users in our stable releases and that remains very important to > us. One issue we have is that individual backports of bug fixes for all of > these packages doesn't scale well. Another issue is that we have clouds > that are running with outdated code that is missing available bug fixes. > With code that is running 5 or even up to 10 years in production, providing > these bug fixes to our users is important. > > Would it be useful to the SRU team if we were to pre-test our stable point > releases in a PPA and post the results to accompany new stable release > requests? > I don't think that would be very useful for SRU purposes, because the tests would have to be run again once the packages are in proposed. You can of course run them before, to get a feeling on how a particular update would behave.
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
