Okay, Seyeong and I had a look during our Sponsorship Office Hours: In your [Impact] section, you mention "disastrous outcomes" but you don't tell us what they outcomes are, or how they happen.
The [Testcase] section needs some additional details. Imagine you are writing a test case to be followed by someone who has some understanding of OpenStack. Could they follow your testcase to verify a package in -proposed themselves? What extra details do they need to know? What does a "bad" case look like, and what does a "good" case look like? For your PPAs, you just need one, internally you can have multiple packages of the same name, just that they need to target different series. So as long as you keep the questing package for questing, and the noble package for noble, they can all live in the same ppa. Usually, as part of maintaining OpenStack packages, we aim to land the patch in the upstream backport branches, so please target backports to all supported OpenStack releases: > If any affected OpenStack release is still supported upstream, it is required > that the patch be merged in the stable branch for that release before an SRU > can proceed. For the patches: In Debian/changelog: Usually we would have a format like this: +masakari (17.0.0-0ubuntu1.24.04.1) noble; urgency=medium + + * If coordination is NOT configured, synchronized becomes effectively + a no-op across multiple API workers, which can lead to duplicate + notifications due to race conditions. Introduce a small randomized + pause to reduce probability of concurrent inserts. (LP: #2028450) + - d/p/lp2146964-masakari-ha-no-duplicated-notifications.patch + + -- Alan Baghumian <[email protected]> Mon, 06 Apr 2026 11:31:00 -0700 Or this is okay too: +masakari (17.0.0-0ubuntu1.24.04.1) noble; urgency=medium + + * d/p/lp2146964-masakari-ha-no-duplicated-notifications.patch: + If coordination is NOT configured, synchronized becomes effectively + a no-op across multiple API workers, which can lead to duplicate + notifications due to race conditions. Introduce a small randomized + pause to reduce probability of concurrent inserts. (LP: #2028450) + + -- Alan Baghumian <[email protected]> Mon, 06 Apr 2026 11:31:00 -0700 but I usually prefer the former. Your versions are incorrect, please check: https://ubuntu.com/project/docs/how-ubuntu-is-made/concepts/version- strings/#version-adding-a-change-in-ubuntu-as-a-stable-release-update But for reference, they would be: stonking: 21.0.0-0ubuntu2 resolute: 21.0.0-0ubuntu1.1 questing: 20.0.0-0ubuntu1.1 (but lets be real, questing will EOL before this is ready so target flamingo UCA with 20.0.0-0ubuntu1~cloud1) epoxy: 19.0.0-0ubuntu1~cloud1 noble: 17.0.0-0ubuntu1.1 jammy: 13.0.0-0ubuntu1.1 As Vladimir mentioned, please add some Dep3 tags, mostly, the: Origin: upstream/backport, https://opendev.org/openstack/masakari/commit/1850c050ef716f80706dc29988bee901950f5d2c Bug: https://bugs.launchpad.net/masakari/+bug/2028450 Bug-Ubuntu: https://bugs.launchpad.net/masakari/+bug/2146964 Make sure to swap between "upstream" for cherry picks and "backport" if the patch needed any changes. If you could follow: https://documentation.ubuntu.com/se-docs/en/latest/se- sponsorship/ubuntu-cloud-archive-sru/ and open merge requests against the correct git branches for: https://git.launchpad.net/~ubuntu-openstack-dev/ubuntu/+source/masakari mapped like this: stonking -> master resolute -> stable/2026.1 questing / flamingo -> stable/2025.2 epoxy -> stable/2025.1 noble: stable/2024.1 jammy: stable/yoga it would help a lot. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2146964 Title: [SRU] Prevent masakari HA from creating duplicated notifications To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/2146964/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
