On 07/21/2014 04:38 AM, Matthew Booth wrote:
I would like to make the radical proposal that we stop gating on CI
failures. We will continue to run them on every change, but only after
the change has been successfully merged.
Benefits:
* Without rechecks, the gate will use 8 times fewer resources.
* Log analysis is still available to indicate the emergence of races.
* Fixes can be merged quicker.
* Vastly less developer time spent monitoring gate failures.
Costs:
* A rare class of merge bug will make it into master.
Note that the benefits above will also offset the cost of resolving this
rare class of merge bug.
Of course, we still have the problem of finding resources to monitor and
fix CI failures. An additional benefit of not gating on CI will be that
we can no longer pretend that picking developers for project-affecting
bugs by lottery is likely to achieve results. As a project we need to
understand the importance of CI failures. We need a proper negotiation
with contributors to staff a team dedicated to the problem. We can then
use the review process to ensure that the right people have an incentive
to prioritise bug fixes.
I'm generally in favour of this idea...I've only submitted a relatively
small number of changes, but each time has involved gate bugs unrelated
to the change being made.
Would there be value in doing unit tests at the time of submission? We
should all be doing this already, but it seems like it shouldn't be too
expensive and might be reasonable insurance.
Chris
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
