[openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board
joe.gordon0 at gmail.com
Tue Nov 26 20:29:09 UTC 2013
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
>> > 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.
>> Thierry Carrez (ttx)
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev