The SRU team did reach a consensus on this question last July based on out-of-band discussion (agreeing on option 3 below), but the conclusion had not been posted to the list and the documentation had not been updated until now.
Since I am now working on processing an SRU which falls into this category of being an exception with additional bug references, I have found it useful to go ahead and document this at: https://wiki.ubuntu.com/StableReleaseUpdates#Bug_references_in_changelogs Other members of the SRU team are welcome to further amend this as necessary. Note that I've tweaked slightly from the originally proposed option 3 in that I am saying the explanation that the bugs will not be verified should be put in the bug description; this way it is clear to the SRU team when reviewing the upload in the queue that particular bugs will not be verified and that an SRU template is not required for the bug description. This should also help to streamline the review+acceptance process. On Fri, Jun 16, 2023 at 01:30:15PM +0100, Robie Basak wrote: > In the case of an SRU using some kind of exception to bump to a newer > upstream version (whether that's a microrelease, a feature changing > major release or a backport of something) we can end up with: > > 1. Some kind of tracking bug that explains the exception, for which the > SRU team agrees a QA process that doesn't require SRU verification of > individually fixed bugs. > > 2. Some bugs that we're tracking in Launchpad that nevertheless will be > fixed by the upload, but don't actually need individual verification > because of the previous point. > > I've seen some inconsistency in how these are handled by SRU team > members. I think we could save effort all round by clarifying this. > > Some options are: > > 1) Require that the second class of bugs are not referenced in a way > that results them ending up in Launchpad-Bugs-Fixed. This way the > pending-sru report won't mention them, and the SRU team won't expect > them to be verified. > > 1b) Reference them but hack Launchpad-Bugs-Fixed to remove them again > before signing and uploading. > > 2) Reference them normally but then require or expect that the bugs are > verified anyway, even though that's not strictly necessary because of > the agreed QA process as part of the exception. > > 3) Reference them normally but then just mark them > verification-done-<series> with an explanation that individual > verification wasn't necessary as part of the exception. > > The downside of 1 is that they we don't get the auto-close function and > we're effectively providing wrong metadata for the sake of an > unnecessarily rigid SRU process. Except in the case of 1b, developers > and users investigating the changelog won't get the benefit of the > missing references. For 1b it's only automation that is likely to > suffer from that latter issue. > > The downside of 2 is that this creates unnecessary extra work for > uploaders. > > The downside of 3 is that this could be confusing initially, except that > hopefully the explanation will help? It's certainly obtuse regardless. > > IMHO, 3 is the least-worst option. > > Thoughts? > > Robie > -- > Ubuntu-release mailing list > Ubuntu-release@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-release -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
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
