On Tue, Oct 22, 2019 at 12:30:34PM -0300, Rafael David Tinoco wrote: > > > afaiu block-proposed tags on bugs are not specific to any series, so you > > > are > > > 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 ? It is the responsibility of the SRU uploader to base their upload on the current state of the archive at the time; so they should not be unaware that there is a previous version in -proposed which their upload needs to base on. And I think in principle the block-proposed tag should be removed by the SRU team member when accepting the newer, non-proposed-only upload. But if they overlook this, it's appropriate for whoever notices it (SRU team, or uploader) to remove the block-proposed-$series tag when it no longer applies. -- 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-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel