====== Development Meeting: January 9, 2013 ======

Held at

  * 10:00:00 a.m. Wednesday, January 9, 2013 in America/Los_Angeles
  * 1:00:00 p.m. Wednesday, January 9, 2013 in Canada/Eastern
  * 18:00:00 Wednesday, January 9, 2013 in UTC

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

  * Minutes:        http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-01-09-13.03.html
  * Minutes (text): http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-01-09-13.03.txt
  * Log:            http://evergreen-ils.org/meetings/evergreen/2013/evergreen.2013-01-09-13.03.log.html

===== Action Items from Last Meeting =====

  -  edoceo to work on setting up a dojo 1.6 test server
     - **STATUS?**
  - kmlussier to help coordinate end-user testing
     - **STATUS** - waiting for setup of dojo test server
  - bshum will remove jspacremovalblocker from bugs that are not blockers and eeevil will send message to general list to ask people to identify blockers.
      - **STATUS?** 
  - denials to add a mention in the docs about PHP & Android efforts 
      -  **STATUS?** 
  - GSOC_mentors to ensure related project code is moved to Evergreen git repos.
        - **STATUS?**

==== GSoC reports ====

[placeholder]

==== Release info ====

=== OpenSRF ===

[placeholder]

=== Evergreen ===

  * berick: http://libmail.georgialibraries.org/pipermail/open-ils-dev/2013-January/008729.html -- We seem to have general agreement on the list.  I just want to make sure it's mentioned in the meeting so everyone's on board.
  * berick: The next 2.3 and 2.2 release is scheduled for January 16th.  Merge while ye may.

== Staff client memory problems ==
  * Memory leaks are causing major disruptions in some libraries that have upgraded to 2.3. See https://bugs.launchpad.net/evergreen/+bug/1086458 and http://markmail.org/message/eec5sha2i3pdpga4 for more info.
  * Note: tsbere is working on a possible solution to some of the memory leak issues, though it is a longer term fix due to how much code needs to be changed.

== Proposals (tsbere) ==
  * To encourage more community communication and involvement I propose that new features (not bugfixes) require sign-offs from two or more groups in the community before being committed, regardless of commit bit status. That would prevent any single entity from pushing new features in without the community looking over them just because they have one or more core committers in their employ.
  * On a similar vein, to ensure communication time with the community is possible I propose that new features need to be in a pullrequest state on Launchpad for a minimum of a week before a core committer pushes them into the system. Again, not bugfixes.