[openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board
markmc at redhat.com
Tue Nov 26 22:39:17 UTC 2013
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>
> >> 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
> >> > 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
> > ++
> >> 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
> > 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
Any recheck bug which appears regularly in the graphs here:
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
So, yeah - the intent sounds good to me.
More information about the OpenStack-dev