On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack <andr...@canonical.com> wrote:
> 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. > > Hi Andreas, Thanks for taking a look. I've put a full list of rdepends here: https://github.com/coreycb/reverse-depends/blob/main/reverse-depends It is mostly OpenStack packages, but I did find a few non-openstack packages: fence-agents-compute (Depends: python3-novaclient) fence-agents-openstack (Depends: python3-novaclient) fence-agents-ironic (Depends: python3-openstackclient) jeepyb (Depends: python3-swiftclient) prometheus-openstack-exporter (Depends: python3-cinderclient, python3-keystoneclient, python3-neutronclient, python3-novaclient, python3-swift) python3-novnc (Depends: python3-oslo.config, Reverse Depends: nova-novncproxy, qemu-web-desktop) It is worth noting that OpenStack stable releases cannot include incompatible API changes. 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. > > I'm hesitant to do this because I think it would get noisy. In my experience, bug fixes often change behavior, but not in an incompatible way. Would it be useful to provide a summary of commits included in a stable release? We might be able to include that in the debian/changelog even. In some cases, such as neutron, I probably would not want to do that because the number of commits (sometimes 50+) could pollute the changelog, but I think in general it could be useful to end users. Thanks, Corey > > >> 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 >
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
