On Sat, 17 Jun 2023 at 00:30, Robie Basak <robie.ba...@ubuntu.com> 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. > Launchpad has code at least to parse the changelog for bug references as well as looking at the changes file -- although I can't quickly understand which gets used when -- so there is a chance having those be inconsistent may be confusing. > 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. > I agree. Cheers, mwh
-- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
