[openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

Clint Byrum clint at fewbar.com
Tue Nov 26 18:19:20 UTC 2013


Excerpts from Thierry Carrez's message of 2013-11-26 03:23:51 -0800:
> Dolph Mathews wrote:
> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
> > <robertc at robertcollins.net <mailto:robertc at robertcollins.net>> wrote:
> > 
> >     So my proposal is that we make it part of the base hygiene for a
> >     project that any recheck bugs being seen (either by elastic-recheck or
> >     manual inspection) be considered critical and prioritised above
> >     feature work.
> > 
> > I agree with the notion here (that fixing transient failures is
> > critically high priority work for the community) -- but marking the bug
> > as "critical" priority is just a subjective abuse of the priority field.
> > A non-critical bug is not necessarily non-critical work. The "critical"
> > status should be reserved for issues that are actually non-shippable,
> > catastrophically breaking issues.
> 
> It's a classic bugtracking dilemma where the "Importance" field is both
> used to describe bug impact and priority... while they don't always match.
> 

If I'm on the fence between 1 importance or the other, I look at the bug
list of the two importance lists:

For instance, there are all 122 High importance bugs in Nova, and 6
Critical bugs.

If we are comfortable with developers choosing to fix all 122 of the other
High bugs before this bug, then make it High. If not, make it Critical.
Likewise, if we are uncomfortable with this bug being chosen before any
of the 6 Critical bugs, then make it High.

I realize those two choices could make a person uncomfortable and wish for
something in-between like "Hitical" or "Criticigh", but micro-management
is no way to actually get things done and it does only take a few seconds
to reprioritize as we add insight and data over time.

> That said, the "impact" of those bugs, considering potential development
> activity breakage, *is* quite critical (they all are timebombs which
> will create future gate fails if not handled at top priority).
> 
> So I think marking them Critical + tagging them is not that much of an
> abuse, if we start including the gate impact in our bug Impact
> assessments. That said, I'm also fine with High+Tag, as long as it
> triggers the appropriate fast response everywhere.
> 

IMO the tags are a distraction to triage. Critical or High is enough of
a conundrum to resolve. The tags will certainly help guide trackers, and
they should add them, but the person doing triage should mostly focus on
"will the patient die?" type questions.



More information about the OpenStack-dev mailing list