Open Stack

On Mon, 2013-12-09 at 10:49 -0800, James E. Blair wrote:
> Hi,
> 
> On Wednesday December 11, 2013 we will remove the ability to use
> "reverify no bug" to re-trigger gate runs for changes that have failed
> tests.
> 
> This was previously discussed[1] on this list.  There are a few key
> things to keep in mind:
> 
> * This only applies to "reverify", not "recheck".  That is, it only
>   affects the gate pipeline, not the check pipeline.  You can still use
>   "recheck no bug" to make sure that your patch still works.
> 
> * Core reviewers can still resubmit a change to the queue by leaving
>   another "Approved" vote.  Please don't abuse this to bypass the intent
>   of this change: to help identify and close gate-blocking bugs.
> 
> * You may still use "reverify bug #" to re-enqueue if there is a bug
>   report for a failure, and of course you are encouraged to file a bug
>   report if there is not.  Elastic-recheck is doing a great job of
>   indicating which bugs might have caused a failure.
> 
> As discussed in the previous thread, the goal is to prevent new
> transient bugs from landing in code by ensuring that if a change fails a
> gate test that it is because of a known bug, and not because it's
> actually introducing a bug, so please do your part to help in this
> effort.

I wonder could we make it standard practice for an infra bug to get
filed whenever there's a known issue causing gate jobs to fail so that
everyone can use that bug number when re-triggering?

(Apologies if that's already happening)

I guess we'd want to broadcast that bug number with statusbot?

Basically, the times I've used 'reverify no bug' is where I see some job
failures that look like an infra issue that was already resolved.

Thanks,
Mark.