Open Stack

On 08/16/2013 02:25 PM, Maru Newby wrote:
> 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.

I do not know the exact implementation that would work here, but I do
think it's worth discussing further. Essentially, a neutron bug killing
the gate for a nova dev isn't necessarily going to help - because the
nova dev doesn't necessarily have the background to fix it.

I want to be very careful that we don't wind up with an assymetrical
gate though...