====== Jan 13, 2015 Developers Meeting ======

===== Minutes ====

  * http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-13-14.09.html
  * http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-13-14.09.txt
  * http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-01-13-14.09.log.html
===== Action Items from Last Meeting =====

  * gmcharlt will release OpenSRF 2.4.0 on 13 November
  * kmlussier to have results of second Bug Squashing Day posted to blog by end of week.
    * **Status update:** Not done. Will post results as I begin planning for our next Bug Squashing Day (February).
  * <del>berick to write about his ideas for 2.next to the lists</del>

===== Updates =====

==== Release info ====

=== OpenSRF ===

  * OpenSRF 2.4.1
    * main feature target is adding config to enable use of standard WS/WSS ports

=== Evergreen ===

== Evergreen 2.8 Reminders ==

  * Document your new 2.8 features in Launchpad!
  * The Beta feature merge cut-off is Friday, Feb. 20th.
  * Pullrequests should target "2.8-beta" 
===== New Business =====

==== Quality Assurance ====
The August 2013 QA report from Equinox made several recommendations for moving forward on QA issues. [[http://nox.esilibrary.com/~jason/qareport/qa.html#_moving_forward]] The developer community has moved forward wtih the recommendation to include pgTAP tests with their database changes, but there are several recommendations that have not been implemented. I would like to start a discussion on what is needed to move forward with some of the other recommendations. What does the developer community think we need to be able to implement more QA procedures in the development process? -kml

==== Feedback for New Features Under Development ====

   * Overdrive API - [[http://markmail.org/message/cgcrmqdz4nrm5erv]]
   * Negative Balances / Billing Improvements Bug [[https://bugs.launchpad.net/evergreen/+bug/1198465]]
     * This bug is somewhat sprawling now, and the current branch conflicts with master in a few subtle but not simple ways
     * Is anyone willing to test as-is just for sanity checking, particularly the billing-to-cstore changes?
     * If not, can anyone commit to the following:
       * Testing the whole branch if all master conflicts are resolved?
       * Testing just the billing-to-cstore bits if that code is split into it's own branch?  (I imagine this would be the surest way to make at least **some** progress)