Open Stack

On Aug 16, 2013, at 11:44 AM, Monty Taylor <mordred at inaugust.com> wrote:

> 
> 
> 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…

What are your concerns regarding an 'asymmetrical gate'?  By halting neutron development until neutron-caused breakage is fixed, there would presumably be sufficient motivation to ensure timely resolution.

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev