Open Stack

On Tue, 2013-11-26 at 12:29 -0800, Joe Gordon wrote:
> On Nov 26, 2013 8:48 AM, "Dolph Mathews" <dolph.mathews at gmail.com> wrote:
> >
> >
> > On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez <thierry at openstack.org>
> wrote:
> >>
> >> 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.
> >
> >
> > ++
> >
> >>
> >> 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).
> >
> >
> > 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.
> >
> >>
> >> 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.
> >
> >
> > I'm fine with starting them at High, and elevating to Critical as
> appropriate.
> >
> > 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!)
> 
> 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.

[Just to circle back and clarify my €0.02c during the TC and project
meetings tonight]

Any recheck bug which appears regularly in the graphs here:

  http://status.openstack.org/elastic-recheck/

means that a human has looked at it, determined a fingerprint for it, we
have a bunch of details about it and we have data as to it's regularity.
Any such bug is fair game to be marked Critical.

If it is still there a month later, but no-one is making any progress on
it and it's happening pretty irregularly ... then I think we'll see a
desire to move it back from Critical to High again so that the Critical
list isn't cluttered with stuff people are no longer paying close
attention to.

So, yeah - the intent sounds good to me.

Thanks,
Mark.