On Tue, 2013-11-26 at 12:29 -0800, Joe Gordon wrote: > On Nov 26, 2013 8:48 AM, "Dolph Mathews" <dolph.math...@gmail.com> wrote: > > > > > > On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez <thie...@openstack.org> > wrote: > >> > >> Dolph Mathews wrote: > >> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins > >> > <robe...@robertcollins.net <mailto:robe...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev