On Fri, Jun 23, 2023 at 10:26:12AM -0700, Steve Langasek wrote: > Auto-closure of bug tasks was irrelevant to me. We almost never have bug > tasks open in Launchpad against stable series of packages, *except* when > they have been opened as part of the SRU process. I didn't even bother to > look at these bugs to see if there were manually-opened tasks against the > stable series. If any such tasks exist, then they can be lazily closed by > someone who cares enough to do the clean-up.
I'm not so sure about "almost never". My feeling is that it's common for there to be bugs that have tasks open against stable releases and are being fixed by an SRU in a microrelease update or backport. For example, if a user reports a bug against a package in Jammy but fixed in a newer release through a new upstream version, then we'll triage it by marking it Fix Released and opening a Jammy bug task, since that's the only reasonable way of noting that status after spending the time to figure that out. If we then SRU an upstream microrelease, the diligent uploader will note that the bug is fixed as part of that upload. Not closing that bug, eg. but not necessarily via the changelog and Launchpad-Bugs-Fixed, would do the reporting user a disservice. It will also look like our LTS is far more buggy than it actually is! Not using Launchpad-Bugs-Fixed would require the uploader to make some arrangement to notice and act when someone else SRU-releases it weeks later. I thought of the GNOME microrelease exception as an example. From memory, mutter was updated recently. I looked for this in Jammy and found bug 1985089 that demonstrates exactly this. I guess Jeremy didn't strictly _have_ to create a Jammy task there, but I would consider it wrong to find it Fix Released for the development release and _not_ have a Jammy task open.
signature.asc
Description: PGP signature
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
