So if I'm understanding you correctly, a job can fail and will be held onto in case one of the parent jobs causes a reset in which case it will be retested?
On Thu, Jun 5, 2014 at 11:24 PM, Jeremy Stanley <fu...@yuggoth.org> wrote: > On 2014-06-05 19:50:30 -0700 (-0700), Kevin Benton wrote: > [...] > > At a queue size of 20 and an 80% success rate. The patch in > > position 20 only has a ~44% chance of getting merged. However, > > with a queue size of 4, the patch in position 4 has a ~71% chance > > of getting merged. > [...] > > Your theory misses an important detail. A change is not ejected from > a dependent Zuul queue like that of the gate pipeline simply for > failing a voting job. It only gets ejected IF all the changes ahead > of it on which it's being tested also pass all their jobs (or if > it's at the head of the queue). This makes the length of the queue > irrelevant to the likelihood of a change eventually making it > through on its own, and only a factor on the quantity of resources > and time we spend testing it. > > The reason we implemented dynamic queue windowing was to help > conserve the donated resources we use at times when there are a lot > of changes being gated and failure rates climb (without this measure > we were entering something akin to virtual memory swap paging > hysteresis patterns, but with virtual machine quotas in providers > instead of virtual memory). > -- > Jeremy Stanley > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
