On Mon, Nov 25, 2013 at 8:12 PM, Robert Collins <robe...@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 <rbtcoll...@hp.com> > Distinguished Technologist > HP Converged Cloud > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- -Dolph
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev