<p dir="ltr"><br>
On Nov 26, 2013 8:48 AM, "Dolph Mathews" <<a href="mailto:dolph.mathews@gmail.com">dolph.mathews@gmail.com</a>> wrote:<br>
><br>
><br>
> On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br>
>><br>
>> Dolph Mathews wrote:<br>
>> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins<br>
>> > <<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>
>> 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>
><br>
><br>
> ++<br>
><br>
>><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>
><br>
><br>
> 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.<br>

><br>
>><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>
><br>
><br>
> I'm fine with starting them at High, and elevating to Critical as appropriate.<br>
><br>
> 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!)<br></p>
<p dir="ltr">I certainly hope we don't automatically set priority based on raw recheck data. We have a second list of bugs that we feed to elastic-recheck this list is reviewed for duplicates and include fingerprints see we can better assess the bug frequency.  I think the idea is to mark bugs from that list as critical.  I also think it should be a manual process. As a bug should be reviewed (does it have enough detail etc) before setting it to critical.</p>

<p dir="ltr">>  <br>
>><br>
>><br>
>> --<br>
>> Thierry Carrez (ttx)<br>
>><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
><br>
> -- <br>
><br>
> -Dolph<br>
><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">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>