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

• 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

1. bshum will take charge of wrangling patches to remove JSPac
   • STATUS: Started, see bug 1152655
2. ESI will recreate the testing.evergreen-ils.org VM
   • STATUS
3. jeff and Dyrcona will speak with denials about rebuilding the buildbot
   • STATUS: It's alive... ALIIIIIIVE!
4. 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

Mentoring organization application deadline is March 29, 2013.

[placeholder]

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

• MassLNC has started the process of creating 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?