Open Stack

On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins
<robertc at robertcollins.net>wrote:

> 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.


>
> Thoughts?
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131125/586aef5f/attachment.html>