<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">Dolph Mathews wrote:<br>
> On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins<br>
</div><div class="im">> <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a> <mailto:<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>>> wrote:<br>
><br>
>     So my proposal is that we make it part of the base hygiene for a<br>
>     project that any recheck bugs being seen (either by elastic-recheck or<br>
>     manual inspection) be considered critical and prioritised above<br>
>     feature work.<br>
><br>
> I agree with the notion here (that fixing transient failures is<br>
> critically high priority work for the community) -- but marking the bug<br>
> as "critical" priority is just a subjective abuse of the priority field.<br>
> A non-critical bug is not necessarily non-critical work. The "critical"<br>
> status should be reserved for issues that are actually non-shippable,<br>
> catastrophically breaking issues.<br>
<br>
</div>It's a classic bugtracking dilemma where the "Importance" field is both<br>
used to describe bug impact and priority... while they don't always match.<br></blockquote><div><br></div><div>++</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<br>
That said, the "impact" of those bugs, considering potential development<br>
activity breakage, *is* quite critical (they all are timebombs which<br>
will create future gate fails if not handled at top priority).<br></blockquote><div><br></div><div>I generally agree, but I don't think it's fair to say that the impact of a transient is universally a single priority, either. Some transient issues occur more frequently and therefore have higher impact.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
So I think marking them Critical + tagging them is not that much of an<br>
abuse, if we start including the gate impact in our bug Impact<br>
assessments. That said, I'm also fine with High+Tag, as long as it<br>
triggers the appropriate fast response everywhere.<br></blockquote><div><br></div><div>I'm fine with starting them at High, and elevating to Critical as appropriate.<br></div><div><br></div><div>Is the idea here to automatically apply a tag + priority as a result of "recheck/reverify bug X" ? (as long as existing priority isn't overwritten!)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div class=""><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>