sru/multipath-tools: initial minor release exception

[TheJJ]

multipath-tools releases stable updates now, i was kindly informed by mail from their maintainer.
this is the minor release exception so we can backport the stable releases more easily.

[panlinux]

I have read the proposed changes, and will add comments to it, but at first glance it sounds like you could use the existing generic MRE allowance from https://documentation.ubuntu.com/project/SRU/reference/requirements/#new-upstream-microreleases

There is more in the linked document, but it states:

For upstreams who have

• a reliable and credible test suite for assuring the quality of every commit or release,
  the tests are covering both functionality and API/ABI stability,

• the tests run during package build to cover all architectures,

• the package has an autopkgtest to run the tests in an Ubuntu environment against the actual binary packages,

[panlinux]

This doesn't sound like a good release policy: "best effort basis". What else can be said about the policy to include fixes in these stable branches?

• what qualifies a fix for a stable branch?
• are the fixes in the stable branch always accompanied by a new or updated test?
• it's weird to mention the opensuse staging area. I see this text was copied from upstream, but what does it mean really? What's the opensuse policy for including fixes in their staging area?

[TheJJ]

They say "Small bug fixes with low regression risk from will be cherry-picked to these branches from the staging area.", which I would interpret as 'pure, well understandable bugfixes' and since the stable branches have CI tests, that those should all pass and would be updated.
I didn't see something more specific being stated somewhere explicitly but this sounds like the maintainers intend to collect all bugfix commits affecting a stable release, likely like linux stable branches work, just done by opensuse engineering when their time allows.

[panlinux]

From what I quickly checked, they use ubuntu 22.04 as a base, but the actual test runs in a container for the "rolling distros", which are debian-sid, alpine, opensuse-tumbleweed, and fedora-rawhide. That doesn't seem to match the Ubuntu LTS releases targeted by this proposal, could you check?

[TheJJ]

the only ubuntu test seems to be for trusty, but they have tests for trixie
multiarch test for stable distros / build-old (debian-trixie, 386) (push) -> https://github.com/opensvc/multipath-tools/blob/stable-0.12.y/.github/workflows/multiarch-stable.yaml and sid https://github.com/opensvc/multipath-tools/blob/stable-0.12.y/.github/workflows/multiarch.yaml

[panlinux]

That seems to be the only multipath test, actually, as kpartx-file-loopback only tests kpartx a bit. I'm a bit concerned that the autopkgtest is the only test we will run on the Ubuntu releases getting these updates. Depending on the changes we get with these upstream branches, we should perhaps add more testing to it, even if it's manual. Do you have an idea of what kind of testing that would be like, given past updates to the upstream stable release branches?

[TheJJ]

what testing do you imagine is needed in addition? that tests does the setup, path adding, path failure and data transfer verification.
the updates in 0.12.x change manpages, ci workflows, and add new devices. 0.11.x had the same, and conditional c-standard bumping, fixing shell quoting for uuids, fixing a logical ordering bug in kpartx, additional error handling, memory cleanup improvements, a new path discovery flag, fixing path group index invalidation, and a new systemd service that disables queuing on stop (multipathd-queueing.service).
i would hope these changes are covered by our existing testing if the path adding/removing and general storage functionality works.

[TheJJ]

Thanks! I've addressed your comments where possible :)