On 11/25/2013 10:24 PM, Dolph Mathews wrote: > > On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins > <[email protected] <mailto:[email protected]>> 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.
A race condition in a project which causes it to act with undefined
behavior some statistically significant part of the time in a relatively
small, single node, non highly parallel (at max 4 simultaneous requests)
seems catastrophically breaking to me.
-Sean
--
Sean Dague
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
