Open Stack

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