>> blocking updates across all series. Not really desired.
> Following the thread you started, it seems that we can all agree to use
> block-proposed-<series> instead. Does this resolve your concern?
>
> On Wed, Aug 28, 2019 at 09:24:10PM +0200, Julian Andres Klode wrote:
>> Does this work sensibly, though? AFAIUI, the tools will set the bug
>> back to verification once you upload a follow up (at least if you
>> pass -v<version in -updates> to dpkg-buildpackage, which IIRC is
>> kind of expected, as otherwise bug closure emails end up weird).
> This is a good point. If we adjusted the tooling to avoid reopening the
> bug for verification in this case, would this resolve your concern?
>
> It looks like the logic is here:
> https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru_workflow.py#L76
>
> The new logic might be: if the bug (has blocked-proposed-<series>) and
> (verification-done or verification-done-<series> for the series being
> accepted) and (doesn't have verification-failed or
> verification-failed-<series> for the series being accepted), then do not
> reset the tag for that series at accept time. Are there any edge cases I
> haven't considered? Alternative suggestions appreciated.
>
Robie, using a real example now:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1849342
Its a FTBS for Disco on Libvirt. I'm assigning this to Christian, who
will likely add to this notes as he is the maintainer. But lets suppose
there was no particular maintainer. I would tag this bug as
"block-proposed-disco".
Would the uploader have to manually check for bugs with that tag before
finishing the next SRU ? Would he discover only when migration failed
after SRU was already uploaded and accepted, lets say ?
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
