I must say that I was certainly inconsistent in my approach here, requesting one of 2) or 3) depending on the particular package in mention.
I'd say that my personal preference would be 2), and this is what I in general tried to push for in some cases. If someone decides to backport a new upstream version from a later series and decides to just do a 1:1 package backport, I think it's fair to also expect double-checking if the bugs attached to the upload are verified. More testing is something that's never a bad thing per-se. And if the exception for the new upstream release/backport has an extensive test-case that would potentially also already test the given scenario, those additional SRU bug reports can be then marked as verified quite easily. Since my thinking is: if someone doesn't think the bugs should warrant verification, they should not be included in the .changes file. However, there were times where I was doing 3), especially for big beefy backports like toolchain updates, as those have a big turnaround in preparation of the SRU packages (some are bin-copies). In those cases some of the 'additional' SRUs were hard to formulate into SRU bugs - and the verification for the toolchain itself would be good enough there. So I have no strong preferences, and to some degree I think 2) and 3) are quite alike, so any of those two would be my option. Cheers, On Sun, 18 Jun 2023 at 23:19, Michael Hudson-Doyle <michael.hud...@canonical.com> wrote: > > > > 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 -- Łukasz 'sil2100' Zemczak Foundations Team Tools Squad Interim Engineering Manager lukasz.zemc...@canonical.com www.canonical.com -- Ubuntu-release mailing list Ubuntu-release@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-release
