======Development Meeting: March 12, 2013======
Held at

  * 11:00:00 a.m. Tuesday, March 12, 2013 in America/Los_Angeles
  * 2:00:00 p.m. Tuesday, March 12, 2013 in Canada/Eastern
  * 18:00:00 Tuesday, March 12, 2013 in UTC

===== Logs and minutes =====

  * Minutes:        http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-03-12-14.04.html
  * Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-03-12-14.04.txt
  * Log:            http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-03-12-14.04.log.html
===== Action Items from Last Meeting =====

  - bshum will take charge of wrangling patches to remove JSPac
    * **STATUS**: Started, see [[https://bugs.launchpad.net/evergreen/+bug/1152655|bug 1152655]]
  - ESI will recreate the testing.evergreen-ils.org VM
    * **STATUS**
  - jeff and Dyrcona will speak with denials about rebuilding the buildbot
    * **STATUS**: [[http://testing.evergreen-ils.org/|It's alive... ALIIIIIIVE!]]
  - gmcharlt to do some branch management with an eye towards an OpenSRF 2.2 release in the next few weeks
    * **STATUS** started going through patches.  After testing of multi-session and service reload, can cut OpenSRF alpha later this week
==== GSoC ====

Mentoring organization application deadline is March 29, 2013.

==== Release info ====

=== OpenSRF ===

[placeholder]

=== Evergreen ===

  * 2.4 release:
    * Let's revisit all of the dependencies that we currently install from source for newer versions or for ditching, including:
      * yaz - currently installing 4.2.32; current source version is 4.2.51
      * Net::Z3950::SimpleServer - currently installing 1.15, current source version is 1.17
      * SpiderMonkey and libjs - who cares about the versions, but should we officially deprecate script-based circ as of 2.4?
      * libdbi / libdbi-drivers - only installed from source on Debian Squeeze and Ubuntu Lucid
      * XULRunner - let's look at merging https://bugs.launchpad.net/evergreen/+bug/1043819 so we can more automatically get the latest stable version (make bump-xul), getting stuck with old versions exposes us to known vulnerabilities
      * **Q**: Would it be worth turning this into a documented, repeatable release process that ultimately the release manager signs off on (although naturally anyone else could do the actual work & provide assessments / suggestions).
  * Proposed addition to release manager processes: No release tarball shall be released unless at least one person has gone through a clean install and confirmed that it actually works.
  * Proposed addition to release manager processes: Clearly articulate (in the release notes?) which operating systems and browsers (and versions & bitness of each) are supported by a given release. Not just Linux distros, which should have one or more distro champions; but also Windows (to answer anticipated questions like: "Is the staff client supported on Windows 8 64-bit?"); and a line in the sand for old browsers (Internet Explorer 6 anyone?) and potentially cutting-edge releases (IE 10? Ubuntu Raring?). This also assumes that any statements of support have corresponding testing.
==== Software Performance Evaluation ====
   * MassLNC has started the process of creating [[dev:testing:performance_draft_rfp|an RFP]] to find a consultant to perform a software performance evaluation. In general, we would like any feedback from the community on this RFP. Also, we'll take any recommendations for people or companies we should send this to.
   * We would like to involve the community in selecting a consultant(s). Is anyone willing to volunteer to work with us on this?