Open Stack

On 06/12/2014 01:07 PM, Jaume Devesa wrote:
> ​Anita, thanks for the response. My comments inline:​
> 
> 
> 
>> Well then we are in a situation where development ceases until the third
>> party systems respond. Which is not a situation we want to put ourselves
>> in. We actually are actively avoiding that situation.
>>
>> ​I don't mean to run after the change is merged, but after is verified,
> which is the first step. And I don't mean neither that they should vote. So
> I don't see that means the development ceases until the third party
> respond...
> 
> The failure on the '.' at the end of the commit title is a style test,
>> not something the third party tests would run anyway.
>>
> 
> ​Absolutely agree. My point is that third party have had to run two times:
> one before the '.' patch and the other one after. And third party opinion
> is worthless if Jenkins says -1. Just want to avoid the first run.
> ​
> 
>> Thanks,
>> Anita.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
> 
> ​Regards,​
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
That assumes one situation when check tests run, when a new patchset is
submitted.

There are other situations when check tests run, on jenkins: recheck
(which is a requirement on third party systems as well), after a comment
has been submitted if the last run of check tests is older than 3 days
and also just prior to going into the gate pipeline.

Since we have various triggers and paths to merging already for patches,
it would slow down the flow of development - particularly around freeze
time, when every one wants their patches merged yesterday - to have to
wait for third party tests to report back after jenkins has verified.

Thanks,
Anita.