Developer Meeting: November 15, 2012

Held at

• 10:00:00 a.m. Monday, July 16, 2012 in America/Los_Angeles
• 1:00:00 p.m. Monday, July 16, 2012 in Canada/Eastern
• 18:00:00 Monday, July 16, 2012 in UTC

• Minutes: http://evergreen-ils.org/meetings/evergreen/2012/evergreen.2012-11-15-13.07.html
• Minutes (text): http://evergreen-ils.org/meetings/evergreen/2012/evergreen.2012-11-15-13.07.txt
• Log: http://evergreen-ils.org/meetings/evergreen/2012/evergreen.2012-11-15-13.07.log.html

1. denials still going to write up "How to set up an alias for cherry-picking w/ signoff in tig"
   1. Status: Done http://www.evergreen-ils.org/dokuwiki/doku.php?id=dev:git:tig
2. berick will make sure the rc1 release actually gets some kind of announcement
3. senator and dbwells will work out the remaining details on bug 1024095 Extremely slow batch marc loading: Done via 579c2cb8 and 97966903
4. denials to patch make_release so that it sets the eg_version var on the upgrade scripts: Done via 367f0ad2b9 and 2e10326b

[placeholder]

• We found and fixed security holes. Thanks to folks like dbwells and miker for actually providing code to fix the security problems!

• I (dbs) for one felt completely exhausted going through the last round of security releases - and the concurrent cold/flu I was working through was just one small part of that.
• The biggest problem is that it felt like berick and I were going through the bulk of the QA effort ourselves - that is, the actual testing of the install & upgrade processes on different distros. Which is a huge problem from the potential for burnout, fatigue, overlooking gotchas and mistakes, etc. We collectively have to take the security fixes all the way to the finish line by testing & documenting & wrapping it up in coherent releases.
• If we're going to do closed security releases, more members of the dev/security team need to participate than just the release maintainers, as we're not able to follow the normal community process of getting feedback on betas/RCs/release announcements/upgrade documentation/automated testing platforms etc. It should *not* be the role of the release maintainer to also do all of the distro testing.

[placeholder]

• What is the plan for merging Joseph Lewis' work? Moving up to 1.6 would be better than being stuck at 1.3.
• If we want the development community to grow, shouldn't we be prioritizing getting efforts from new contributors into the actual codebase? If that means taking things the last mile with testing and polishing, core dev team members need to step up for that.

• Development community intends to support the server editions (rather than desktop, ARM, etc.) of given Linux distributions.
• Switch focus to testing and support for specific server images.
• If community members are passionate about a particular distro, we need them to step up and provide ongoing support: Makefile_DISTRO.install, docs, testing, and participation on the mailing lists.
• See IRC discussion

• When last we talked about what bug fixes we could merge for QueryParser & the driver, eeevil pointed at working/user/miker/QP-for-2-3 - but that has a problem: the unit test for QueryParser is failing rather miserably (run "prove -l lib t/21-QueryParser.t" to see)
• Would it be possible for the people working in that area to agree on what the expected output should be and fix up the test accordingly?

• 1066888 Expand and modularize concerto test data set
• 1066329 Add is_tt2() like is_json() to database, constraint on atevdef.template
• 1066226 More tests: Perl-Critic and TT2 template parsing
• Any progress on the litmus-like documented manual test cases?

• There are still some rumblings of discontent about killing off JSPAC until there's absolutely no loss of features
• Assuming that there are no dev team members that actually want to maintain JSPAC in 2.4, this might be another area to focus on.
• Do we have a concrete, vetted list of remaining tasks for TPAC (e.g. authority browse UI, ???) http://www.evergreen-ils.org/dokuwiki/doku.php?id=dev:opac:template-toolkit:plan seems to be both out of date & not specifically targeted at killing off JSPAC
  • Perhaps this should be a set of speciallly tagged bugs in launchpad ("tpac_to_kill_jspac"?) rather than a rarely-looked-at/rarely-updated wiki page.

• A pretty huge backlog of bugs are building up, with many pullrequests in the mix
• Some people suggest that squashing bugs should always be priority #1.
  • Even if those people are unbearably self-aggrandizing, they might have a point.