• 10:00:00 a.m. Tuesday, October 15, 2013 in America/Los_Angeles
• 1:00:00 p.m. Tuesday, October 15, 2013 in Canada/Eastern
• 17:00:00 Tuesday, October 15, 2013 in UTC

• 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

• [extra old action item from summer doldrums] Start on the 2.6 development road map page
  • Status: 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: http://georgialibraries.markmail.org/thread/22six3nkgbhr3f3t
• gmcharlt to release opensrf 2.2.1 soon(?) post-vacation
  • Status:
• csharp to test 2.4.2 rc so we can officialize it
  • Status:
• senator to find old incomplete action items to move forward (with help from the channel in making sure I get the right ones)
  • Status:
• eeevil to commit a techref doc explaining how to build pgTAP test
  • Status:
• eeevil to publish detailed plan about freezing baseline schemas between EG releases and using deprecates/supersedes in database upgrade scripts. This will go on the mailing list and the thread should structure further discussion of pros and cons of eeevil's plan.
  • Status:

[placeholder]

2.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.

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.