On Aug 16, 2013, at 11:44 AM, Monty Taylor <mord...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
