Comment 6 for bug 1996229

Revision history for this message
Robie Basak (racb) wrote :

Thank you for helping me understand that detail, and for the additional conversation which for reference is at https://irclogs.ubuntu.com/2023/06/22/%23ubuntu-devel.html#t14:13

SRU Review

Looking at Andreas' questions and your answers, it sounds like the test plan is reasonable then. Please add the python3-mistral you proposed to the Test Plan in the bug description so it doesn't get missed.

The number of functional changes upstream is not that big. Having reviewed them I would have preferred that you cherry-picked them only. I think that would have resulted in a simpler and more straightforward review.

You did say that you had difficulty in finding the right cherry-picks, I've reviewed all the changes now anyway, and it's true that the version is currently "wrong" against the magnum also in our Focal archive, so on balance I think it's OK to accept this approach now that we're here.

I found three CLI UI breaking changes in all:

cluster show adds a column for project_id
https://github.com/openstack/python-magnumclient/commit/d91d4c72a10493e57a664e18e1f98268e43dd537

cluster list adds a column for health_status
https://github.com/openstack/python-magnumclient/commit/74c5f22c6ffb23154f2e0412ba43371f3c02f3b7

nodegroup list *removes* some columns?
https://github.com/openstack/python-magnumclient/commit/934cf548540086268991dab47b5bcb85f65b693f

I accept that users are likely to have used `--format json | jq` and the likelihood of a user being regressed by this is low. But the removal of some columns rather than just the addition of them could also regress interactive users. What do you want to do with these? If you think it's necessary to keep these changes, please could you add to "Where problems could occur" with an explanation and justification?

Orig tarball method:

Upstream tag 2.11.0 is identical to what is in Focal except for the debian/ directory as expected. But upstream tag 3.0.1 is noticeably different from your upload, and the differences in setup.cfg may be functional. To avoid inadvertent changes, please re-upload generating the orig tarball in the same way that it was done before, so that the upstream 2.11.0..3.0.1 changes and related packaging changes are the only changes that will apply in this upload.

Given the above issue, do you have a build somewhere for binary debdiff purposes, please, so we can double-check that the build result is the same apart from the intended code changes?

Because I believe this needs a re-upload for the orig tarball issue, I'm rejecting the current upload from the queue.