[openstack-dev] [all project] Treating recently seen recheck bugs as critical across the board

Flavio Percoco flavio at redhat.com
Tue Nov 26 09:07:30 UTC 2013

On 25/11/13 21:24 -0600, Dolph Mathews wrote:
>On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins <robertc at robertcollins.net>
>    This has been mentioned in other threads, but I thought I'd call it
>    out and make it an explicit topic.
>    We have over 100 recheck bugs open on
>    http://status.openstack.org/rechecks/ - there is quite a bit of
>    variation in how frequently they are seen :(. In a way thats good, but
>    stuff that have been open for months and not seen are likely noise (in
>    /rechecks). The rest - the ones we see happening are noise in the
>    gate.
>    The lower we can drive the spurious failure rate, the less repetitive
>    analysing a failure will be, and the more obvious new ones will be -
>    it forms a virtuous circle.
>    However, many of these bugs - a random check of the first 5 listed
>    found /none/ that had been triaged - are no prioritised for fixing.
>    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.

I agree with Dolph. I'd rather tag them instead of marking them as
critical. It is also true that it's not possible to land a patch if
the gate fails, which means these bugs can be interpreted as critical
as well. However, I personally don't think we should let the gate mark
those bugs as critical.

Would a combination of High + tag - elastic-recheck - make sense?

With the above it would be easier to triage them, to know where they
came from and to prioritise them correctly.


Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131126/5f03fe93/attachment.pgp>

More information about the OpenStack-dev mailing list