Open Stack

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.

>
>>
>>
>> --
>> Thierry Carrez (ttx)
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
>
> -Dolph
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131126/eac87f42/attachment.html>