<div dir="ltr"><div>On Thu, Nov 16, 2023 at 4:31 PM Andreas Hasenack <<a href="mailto:andreas@canonical.com">andreas@canonical.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-size:small">Hi Corey,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 1, 2023 at 11:52 AM Corey Bryant <<a href="mailto:corey.bryant@canonical.com" target="_blank">corey.bryant@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Robie,</div><div><br></div><div>Thanks for taking a look.</div><div><br></div><div>On Wed, Aug 30, 2023 at 9:34 AM Robie Basak <<a href="mailto:robie.basak@ubuntu.com" target="_blank">robie.basak@ubuntu.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
As a list of 46 packages this is rather large and non-trivial to review.<br>
Presumably we'll want to group them by upstream (are all managed by the<br>
OpenStack umbrella upstream, or are there exceptions?) and then take a<br>
view on them as a whole.<br></blockquote><div><br></div><div>All of the packages in this list fall under the OpenStack umbrella upstream. The source can be found at: <a href="https://opendev.org/explore/repos" target="_blank">https://opendev.org/explore/repos</a></div><div>All of these packages were specifically chosen because they are dependencies of the existing packages in our SRU exception list.</div></div></div></blockquote><div><br></div><div><div style="font-size:small">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.</div><div style="font-size:small"><br></div></div></div></div></blockquote><div><div><br></div><div>Hi Andreas,</div><div><br></div><div>Thanks for taking a look.</div></div><div class="gmail_quote"><br></div>I've put a full list of rdepends here: <a href="https://github.com/coreycb/reverse-depends/blob/main/reverse-depends">https://github.com/coreycb/reverse-depends/blob/main/reverse-depends</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">It is mostly OpenStack packages, but I did find a few non-openstack packages:</div><div class="gmail_quote"><br></div><div class="gmail_quote">fence-agents-compute (Depends: python3-novaclient)<br>fence-agents-openstack (Depends: python3-novaclient)<br>fence-agents-ironic (Depends: python3-openstackclient)<br>jeepyb (Depends: python3-swiftclient)<br>prometheus-openstack-exporter (Depends: python3-cinderclient, python3-keystoneclient, python3-neutronclient, python3-novaclient, python3-swift)</div><div class="gmail_quote">python3-novnc (Depends: python3-oslo.config, Reverse Depends: nova-novncproxy, qemu-web-desktop)</div><div class="gmail_quote"><div><br></div><div>It is worth noting that OpenStack stable releases cannot include incompatible API changes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div style="font-size:small"></div><div style="font-size:small">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.</div></div><div><br></div></div></div></blockquote><div><br></div><div><font face="arial, sans-serif">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.</font></div><div><br></div><div>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.</div><div><br></div><div><font face="arial, sans-serif">Thanks,</font></div><div><font face="arial, sans-serif">Corey</font></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Fri, Jul 14, 2023 at 11:44:04AM -0400, Corey Bryant wrote:<br>
> python-ovsdbapp<br>
<br>
This one was in the queue and so I reviewed it independently as<br>
requested as a one-off microrelease update SRU. I ended up rejecting it<br>
as there was what looked like a behavioural change with no explanation<br>
as to why it is required, and most other upstream bugfixes did not come<br>
with tests. Details at:<br>
<a href="https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19" rel="noreferrer" target="_blank">https://bugs.launchpad.net/charm-neutron-api/+bug/2007919/comments/19</a><br>
<br>
I'm noting this in this thread for the record in case this has any<br>
bearing on the larger view.<br></blockquote><div><br></div><div>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.<br></div><div>[1] <a href="https://opendev.org/openstack/ovsdbapp/commit/ab3e0cb0d0865417efbf103f44954573a5ba92ac" target="_blank">https://opendev.org/openstack/ovsdbapp/commit/ab3e0cb0d0865417efbf103f44954573a5ba92ac</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div></div></div></blockquote><div><br></div><div><div style="font-size:small">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.</div><br></div><div><br></div></div></div>
-- <br>
Ubuntu-release mailing list<br>
<a href="mailto:Ubuntu-release@lists.ubuntu.com" target="_blank">Ubuntu-release@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-release" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-release</a><br>
</blockquote></div></div>