Differences

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

--- dev:meetings:2013-10-15 [2013/10/15 10:19] – Adding agenda item for OmniTI work klussier
+++ dev:meetings:2013-10-15 [2022/02/10 13:34] (current) – external edit 127.0.0.1
@@ Line 3: / Line 3: @@
   * 1:00:00 p.m. Tuesday, October 15, 2013 in Canada/Eastern
   * 17:00:00 Tuesday, October 15, 2013 in UTC
+===== Minutes links ====
+  * Minutes: [[http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-10-15-13.06.html]]
+  * Minutes (text): [[http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-10-15-13.06.txt]]
+  * Log: [[http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-10-15-13.06.log.html]]
 ===== Action Items from Last Meeting =====
   * [extra old action item from summer doldrums] Start on the 2.6 development road map page
-    * **Status:**
+    * **Status:** [[faqs:evergreen_roadmap:2.6|Roadmap for Evergreen 2.6]]
   * [extra old action item " " "] bshum to summarize bug tracking based on feedback from developers
     * **Status:**
   * [extra old action item " " "] kmlussier to raise bug squashing day to the lists for further discussion/feedback
-    * **Status:**
+    * **Status:** http://georgialibraries.markmail.org/thread/22six3nkgbhr3f3t
   * gmcharlt to release opensrf 2.2.1 soon(?) post-vacation
     * **Status:**
@@ Line 22: / Line 27: @@
     * **Status:**
+===== Updates =====
 ==== Release info ====
@@ Line 31: / Line 38: @@
 === Evergreen ===
-[placeholder]
+.3.11 and 2.4.3 are in place on evergreen-ils.org -- need web site updates.
+berick: i'm planning on skipping this week's maint. release for 2.3 since we just did one.
+==== Update on OmniTI Performance Work ====
+===== New Business =====
-=== Update on OmniTI Performance Work ===
+==== Discuss freezing of master during beta/RC phase ====
+During the last release process, 2.4 was not branched off from master until it was final.  This effectively meant that master was frozen for new features during the beta/RC phase, and new features were expected to wait in feature branches.  This was done for several reasons: to make the release process more effective by not requiring constant backporting (with possible problems once new features are added), to encourage more testing of the actual release code (since many sites run master), and to provide a general stabilizing effect for the release.  This idea which started in 2.4 (and maybe earlier?) was kept for 2.5, but some have raised questions about whether this should be our practice going forward.