Differences

This shows you the differences between two versions of the page.

--- dev:meetings:2013-08-27 [2013/08/23 10:22] – pgTAP phasefx
+++ dev:meetings:2013-08-27 [2013/08/27 16:14] – lebbeous
@@ Line 3: / Line 3: @@
   * 2:00:00 p.m. Tuesday, August 27, 2013 in Canada/Eastern
   * 18:00:00 Tuesday, August 27, 2013 in UTC
+===== Minutes links ====
+  * 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]]
 ===== Action Items from Last Meeting =====
@@ Line 10: / Line 15: @@
       * **Status:** both releases out the door
   - gmcharlt will talk to bshum about updating display of 2.2 on the downloads page
-      * **Status:**
+      * **Status:** done (marked 2.2 as "deprecated")
 ==== GSoC reports ====
+Our student seems to have disappeared again.
 ==== Release info ====
@@ Line 25: / Line 30: @@
   * 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]
 ==== QA Topics ====
- * Do we want to adopt/encourage use of pgTAP for database changes? Examples here: http://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=Open-ILS/src/sql/Pg/t;hb=HEAD -- Jason
+ * 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
+==== DB maintenance plan ====
+ * 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
+==== Hack-A-Way 2013 plans ====
+ * 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 [[dev:hackfest:egfall2012|old page]])