As great as 'drush make' is the perils of unstable network connectivity can thwart it - a single failed download of a module due to a git server being down will result in a failed build. Likewise running 'drush make' on a less-than-stable wifi connection can lead to frustrating builds. This happens surprisingly often, especially if you're rebuilding frequently either as part of your CI process or have transient development environments (e.g. if you're using Vagrant).
To help with this I've added three new parameters which gives drush the power to attempt multiple downloads before giving up and failing. Additionally it ensures drush doesn't retry automatically, giving the offending connectivity issue time to correct itself. The new parameters are:
download-attempts - the number of times a download must be attempted before failing
download-retry-delay-min-seconds - the minimum number of seconds to wait before retrying a failed download
download-retry-delay-max-seconds - the maximum number of seconds to wait before retrying a failed download. After a failed download drush will retry a random number of seconds between download-retry-delay-min-seconds download-retry-delay-max-seconds to prevent flooding of the download source.
Implementing these changes was fairly straightforward - drush uses a factory pattern style function to determine which 'private' function will do the actual job of downloading the file in question. Rather than just passing back the result of the 'private' function, make_download_factory now also includes the the retry logic, issuing an error if the maximum number of retry attempts are reached without a successful download. The only other piece of work was to refactor drush make's applyPatches method, which was calling one of the 'private' download functions directly, so that it went through the factory method to call a new 'simple' download function.
The pull request is over at https://github.com/drush-ops/drush/pull/726/files
Hopefully it's of use, please share your comments!