Comment 6 for bug 1596595

Thanks for the feedback, Galen.

If the lack of unit tests is the main concern, then my preference would be to start working on those over breaking the code into smaller pieces. I don't see a clear path forward there.

The one exception is that it should be possible (from a user perspective) to ignore the new features and run the code as before to get the same results as the existing hold targeter, randomness in current_copy selection notwithstanding.

==

For the unit tests, my plan is to write Perl live tests that run the new targeter against a set of specially selected/crafted holds and analyze the results for correctness. My goal is not to implement a tool for comparing the results of the existing targeter to those of the new targeter.

==

We could also consider supporting both hold targeters for a release cycle, so that people can easily fall back to the original if problems arise. This would be a simple matter of creating an alternate hold_targeter.pl.