====== 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 [[https://chrome.google.com/webstore/detail/accessibility-developer-t/fpkknkljclfencbdbgkenhalefipecmb?hl=en|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? |