For reference, here are the definitions of options 2 and 3: > >> 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.
On Mon, Jun 19, 2023 at 11:33:44AM +0200, Lukasz Zemczak wrote: > 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. This would discourage uploaders from simply providing those bug references though, surely? As it's extra work if they do, and apparently also acceptable if they don't. > Since my thinking is: if someone doesn't think the bugs should warrant > verification, they should not be included in the .changes file. But then we'll end up with bug tasks not auto-closing when they should, and so our bug metadata will end up wrong. > 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. How about we agree that 3 shall be the default, and if the SRU reviewer thinks that 2 is warranted, that this be specified in the tracking bug by SRU accept time? Then people performing SRU verification can be clear on what's required, and when SRU reviewing for release, the SRU team member can expect 3 to be the case without further discussion, and those not hold up the SRU on asking for 2, unless 2 was requested in the tracking bug at the time of SRU accept. For reference, I have just done this, assuming 3, for ubuntu-advantage-tools, so I'm asking so as not to require them to individually verify every single bug they are tracking just because they are (IMHO) correctly closing them through the changelogs, as we consider their test suite and system for documenting and performing specific manual test steps as required to be sufficient. 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
