[2934] explained the rationale of the imposed delay for a xfrout test.

tests/lettuce/features/terrain/transfer.py

@@ -84,7 +84,7 @@ def perform_axfr(step, zone_name, address, port):
     args = [ 'dig', 'AXFR', '@' + str(address), '-p', str(port), zone_name ]
     world.transfer_result = TransferResult(args)
 
-@step('A customized AXFR transfer of ([\w.]+)(?: from ([\d.]+|\[[0-9a-fA-F:]+\])(?::([0-9]+))?)?(?: with pose of (\d+) second)?')
+@step('A customized AXFR transfer of ([\w.]+)(?: from ([\d.]+|\[[0-9a-fA-F:]+\])(?::([0-9]+))?)?(?: with pose of (\d+) seconds?)?')
 def perform_custom_axfr(step, zone_name, address, port, delay):
     """Checks AXFR transfer, and store the result in the form of internal
     CustomTransferResult class, which is compatible with TransferResult.

tests/lettuce/features/xfrout_bind10.feature

@@ -19,6 +19,11 @@ Feature: Xfrout
 
     # Similar to the previous one, but using a much larger zone, and with
     # a small delay at the client side.  It should still succeed.
+    # The specific delay (5 seconds) was chosen for an environment that
+    # revealed a bug which is now fixed to reproduce the issue; shorter delays
+    # didn't trigger the problem.  Depending on the OS implementation, machine
+    # speed, etc, the same delay may be too long or too short, but in any case
+    # the test should succeed now.
     Scenario: transfer a large zone
 
     Load 50000 records for zone example.org to DB file data/xfrout.sqlite3