Tuesday 22 October 2019

Re: Staging changes for future SRU landings

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/
slangasek@ubuntu.com vorlon@debian.org