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... _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
