• 11:00:00 a.m. Tuesday, August 27, 2013 in America/Los_Angeles
• 2:00:00 p.m. Tuesday, August 27, 2013 in Canada/Eastern
• 18:00:00 Tuesday, August 27, 2013 in UTC

• Minutes: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-08-27-14.04.html
• Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-08-27-14.04.txt
• Log: http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-08-27-14.04.log.html

1. gmcharlt will cut OpenSRF 2.2.1 by Friday
   • Status:
2. berick and eeevil to cut 2.3.9 and 2.4.1 on 2013-07-17
   • Status: both releases out the door
3. gmcharlt will talk to bshum about updating display of 2.2 on the downloads page
   • Status: done (marked 2.2 as "deprecated")

Our student seems to have disappeared again.

[placeholder]

• 2.3.10 released 8/23
• 2.4.2 cut 8/23, release as soon as a second set of eyes pass over the tarball

[placeholder]

* Do we want to adopt/encourage use of pgTAP for database changes? There is also a script that can generate a baseline set of tests for verifying the entire Evergreen schema; we could use that script once and forever after maintain those scripts whenever we develop database upgrade scripts. Thoughts? – Jason

• Example tests: http://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=Open-ILS/src/sql/Pg/t;hb=HEAD
• Test generator script: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/make-pgtap-tests.pl;hb=HEAD

* Mike Rylander re-raises the proposal of carving the baseline SQL schema files in stone at major releases and using change-specific upgrade scripts to roll forward to a given, known-good state at minor version and revision upgrades. Benefits:

• Reduced schema churn
  • More people can take more time to understand the schema
  • Make deprecate/supercede scripts useful, which means the functionality might materialize
  • Realistically clear the way for an intelligent upgrade scripts that inspect config.upgrade_log and apply exactly what is needed
• Simpler change management
  • Do things in one place, not two
  • Committers have less to do AND to test

* Question raised on whether there's a list of attendees / list of topic areas

• Suggestion to create a wiki page similar to last year's Hack-A-Way with ideas (see old page)