Signoff / review checklist

Yes/No	Item
	Have you run `make check && make livecheck` with zero failed tests?
	If the patch adds or modifies a stored procedure, is it accompanied by pgTAP unit and/or regression tests? If not, has the patch author provided an explanation as to why such a test cannot be feasibly written? (Also, an additional signoff will be required.)
	If the patch adds or modifies Perl code, is it accompanied by unit and/or regression tests in `t` or `live_t`? If not, has the patch author provided an explanation as to why such a test cannot be feasibly written? (Also, an additional signoff will be required.)
	Does this commit have an associated release notes entry, if applicable? New features, new config.tt2 entries, new user or org unit settings, changes in behaviour should have a release notes entry.
	Have you tested normal Evergreen functionality before and after the commit to ensure that it remains the same (or changes only in the way that the commit describes it should)?
	If the commit adds new text, has it been added using the appropriate translation infrastructure? Please avoid constructed sentences.
	Do the changes introduce any accessibility problems? Examples include using images of text instead of actual text; failure to use ALT tags for significant images; use of tables for layout instead of for tabular data… The Chrome Accessibility Developer Tools offers a helpful accessibility audit.
	If the change introduces a new dependency, has that dependency been added to Makefile.install, and called out in the Release Notes, and a heads-up given to the broader community of testers / fellow developers / distro maintainers?
	If the change removes a dependency, has that dependency been removed from Makefile.install?
	for the committer who pushes the patch(es) If there is a schema change, have you (the patch-pusher) updated the upgrade SQL and `Open-ILS/src/sql/Pg/002.schema.config.sql` with a schema change ID?
	Does "`eg_db_config.pl –create-database –create-schema –load-all-sample`" return without errors? (consider running a second time with "`\| grep ERROR`" if the output is overwhelming)
	Do all of the commits have commit messages with a) short first line summary; b) a description with lines less than 72 chars wide; c) `Signed-off by` line indicating DCO compliance; d) appropriate `Author` credit?
	Does the change follow the agreed-upon Evergreen coding style conventions?
	Does the change include appropriate comments for more complicated bits of code / database schema objects?
	If third-party code is being integrated in the codebase, does it fall under a license compliant with ours (GPL v2, with the "or later" clause)?
	(Docs) Does `cd docs && perl generate_docs.pl –base-url="http://example.com"` return cleanly?