On Mon, Jun 19, 2023 at 11:33:44AM +0200, Lukasz Zemczak wrote: > 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. I'm afraid I have a contrary view here. In my experience, the common case where extra bugs end up referenced in debian/changelog is when doing a straight backport where the easiest thing for the developer to do is incorporate the entire changelog history for the devel series, along with the rest of the diff. If we're doing a full backport as part of an SRU, then that means it falls under some kind of exception. Those exceptions exist to streamline the SRU process in cases where we have been able to determine that the usual process is unnecessary overhead. So by including these bugs in the .changes file and generating the links from the SRU report, we are taking what is meant to be a streamlined process with a single process SRU bug, and gumming it up again. > Since my thinking is: if someone doesn't think the bugs should warrant > verification, they should not be included in the .changes file. Well, I think that much is correct. However, there's a difference between including them in the .changes file (which is what generates the SRU report references) and including them in the changelog. This is Robie's 1b). As a concrete example, I recently did this for ubuntu-dev-tools. The SRU exception is explicitly a "full backports from devel" exception, so the obvious choice is to retain the full debian/changelog, with bug references et al. But I didn't want to have to touch a dozen bugs to verify them! (even if it was a no-op addition of the tag, although at the time I hadn't considered that this might be an option.) So instead I manually edited the .changes files before signing and uploading, to drop the references to the other bugs. 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. > 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. I have been frustrated in the past by binary syncs in the SRU queue whose .changes / changelog were not what I expected. Even worse than toolchain uploads, are uploads of EFI binaries signed with our SecureBoot keys before they've arrived in the queue! (This fortunately hasn't happened in a while, so I think we have our processes sorted out there now.) I think we need to make sure in such cases that SRU review happens before those binaries get built (which is what happens in the normal process for packages built in -proposed in the archive). But I agree with you, if there are cases where we're stuck accepting binary syncs whose changelogs are full of extra bug refs we don't want, 3) is the pragmatic approach. > 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 -- 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
