Wednesday, 27 May 2020

Re: Staging changes for future SRU landings

On Fri, Aug 30, 2019 at 12:29:35PM +0100, Robie Basak wrote:
> Thank you everyone for the feedback.
> On Wed, Aug 28, 2019 at 07:41:10PM +0200, Matthias Klose 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).

Is this expectation, using -v<version in -updates>, something that
should be documented? I ask as when I was doing my SRU shift yesterday I
encountered an upload of a package which was following an upload in
-proposed with the block-proposed-<series> tag but -v was not used. I
went ahead and redid the upload and used -v but wonder if that should be
the policy.

> 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:
> 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.

As far as I can tell this wasn't implemented. Were there objections or
edge cases found where this would not be the correct course of action?

Brian Murray

ubuntu-devel mailing list
Modify settings or unsubscribe at: