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
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
