On Nov 26, 2013 8:48 AM, "Dolph Mathews" <[email protected]> wrote: > > > On Tue, Nov 26, 2013 at 5:23 AM, Thierry Carrez <[email protected]> wrote: >> >> Dolph Mathews wrote: >> > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins >> > <[email protected] <mailto:[email protected]>> 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. > >> >> >> -- >> Thierry Carrez (ttx) >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > > -Dolph > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
