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 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. _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev