[openstack-dev] Gate breakage process - Let's fix! (related but not specific to neutron)

Maru Newby marun at redhat.com
Fri Aug 16 18:25:07 UTC 2013


Neutron has been in and out of the gate for the better part of the past month, and it didn't slow the pace of development one bit.  Most Neutron developers kept on working as if nothing was wrong, blithely merging changes with no guarantees that they weren't introducing new breakage.  New bugs were indeed merged, greatly increasing the time and effort required to get Neutron back in the gate.  I don't think this is sustainable, and I'd like to make a suggestion for how to minimize the impact of gate breakage.

For the record, I don't think consistent gate breakage in one project should be allowed to hold up the development of other projects.  The current approach of skipping tests or otherwise making a given job non-voting for innocent projects should continue.  It is arguably worth taking the risk of relaxing gating for those innocent projects rather than halting development unnecessarily.

However, I don't think it is a good idea to relax a broken gate for the offending project.  So if a broken job/test is clearly Neutron related, it should continue to gate Neutron, effectively preventing merges until the problem is fixed.  This would both raise the visibility of breakage beyond the person responsible for fixing it, and prevent additional breakage from slipping past were the gating to be relaxed.

Thoughts?


m.







More information about the OpenStack-dev mailing list