14:04:05 <gmcharlt> #startmeeting Developer's meeting, 12 March 2013
14:04:05 <pinesol_green> Meeting started Tue Mar 12 14:04:05 2013 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:05 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:04:05 <pinesol_green> The meeting name has been set to 'developer_s_meeting__12_march_2013'
14:04:09 <bshum> #link Agenda:  http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2013-03-12
14:04:23 <krvmga> gmcharlt++
14:04:41 <gmcharlt> #topic Introductions
14:04:50 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
14:04:51 <paxed> #info paxed = Pasi Kallinen, Regional Library of Joensuu
14:05:00 <bshum> #info bshum = Ben Shum, Bibliomation
14:05:08 <senator> #info senator = Lebbeous Fogle-Weekley, Equinox
14:05:09 <ktomita> #info ktomita = Kyle Tomita, Catalyst IT Services
14:05:16 <acoomes> #info acoomes = Andrew Coomes, Catalyst IT Services
14:05:17 <phasefx> #info phasefx = Jason Etheridge, Equinox
14:05:19 <csharp> #info csharp = Chris Sharp, Georgia Public Library Service
14:05:34 <dbwells> #info dbwells = Dan Wells, Calvin College
14:05:35 <remingtron> #info remingtron = Remington Steed, Calvin College
14:05:49 <DPearl> #info DPearl = Dan Pearl, C/W MARS
14:05:49 <berick> #info berick = Bill Erickson, Equinox
14:05:53 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
14:06:06 <sseng> #info sseng = Srey Seng, Catalyst IT Services
14:06:24 <eeevil> #info eeevil = Mike Rylander, Equinox
14:06:28 <Dyrcona> #info Dyrcona = Jason Stephenson, MVLC
14:06:36 <j_scott> #info j_scott = Jon Scott - Lyrasis
14:06:56 <mrpeters> #info mrpeters = Michael Peters, Emerald Data Networks
14:07:11 <gmcharlt> #topic Action items from last meeting
14:07:28 <gmcharlt> #info bshum will take charge of wrangling patches to remove JSPac - status: started, see bug 1152655
14:07:28 <pinesol_green> Launchpad bug 1152655 in Evergreen "Remove JSPAC" (affected: 1, heat: 6) [High,Confirmed] https://launchpad.net/bugs/1152655 - Assigned to Ben Shum (bshum)
14:07:33 <gmcharlt> bshum: anything more to add?
14:08:09 <bshum> gmcharlt: Not specifically, I think tsbere's branch to initially hide toggle options is a good start.
14:08:19 <bshum> And the apache rewrite stuff we're using in production for the last couple months.
14:08:38 <tsbere> #info tsbere = Thomas Berezansky, MVLC
14:08:43 <bshum> I think we can start with that and slowly remove the underlying files as we go.
14:08:48 <gmcharlt> bshum: eeevil: any potential blockers to including in 2.4?
14:09:31 <eeevil> with bshum's leave, no blockers from me at all. I like slow and steady for removing stuff
14:10:45 <bshum> Seems like a good place to make the change.
14:10:54 <bshum> *pace
14:10:55 <gmcharlt> ok, sounds like
14:11:03 <mrpeters> i can +1 that the rewrites tsbere wrote work very well
14:11:13 <gmcharlt> #agreed commits to start removing JSPac will be available in 2.4
14:11:18 <gmcharlt> #info testing.evergreen-ils.org VM and buildbot resurrection: status:  IT'S ALLLIIIIIVE!!!1!!!
14:11:26 <gmcharlt> anything else to say about the buildbot?
14:12:41 <gmcharlt> guess not
14:12:43 <gmcharlt> finally
14:12:44 <gmcharlt> #info 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
14:13:12 <gmcharlt> I'll defer further discussion of OpenSRF releases to its rightful place in the agenda
14:13:20 <gmcharlt> #topic Google Summer of Code
14:13:40 <gmcharlt> I think the sense from the previous meeting is that we're not inclined to put in an application in this year
14:13:49 <gmcharlt> is anybody feeling differently now?
14:14:58 <bshum> I would have liked trying something this year
14:15:14 <bshum> But if everybody else is not feeling it, that's how it goes.
14:15:21 <dbwells> I'm still willing to co-mentor with anybody else, but have no knowledge of what goes into the application process.
14:16:30 <SimonHM> I though somebody just asked about GSOC this morning. For my opinion, for GSOC, do we have to have a wise project proposal, including timeline, requirements, components that you'll develop, etc ...
14:17:38 <gmcharlt> SimonHM: please refer to the GSoC websitefor the description of the program and application process; it's a bit much to rehash now
14:18:20 <bshum> I think a good thing to try is reviewing what's on the ideas page and updating it if we could.
14:18:33 <bshum> I've been meaning to add an idea of my own
14:18:37 <DPearl> Could the GSoC project do some work on setting up QA frameworks?
14:18:39 <phasefx> so, to be clear, we have no mentor volunteers at the moment?
14:18:45 <bshum> But I guess maybe asking for help on that subject would be good.
14:19:12 <berick> phasefx: i believe dbwells volunteered
14:19:32 <gmcharlt> I'm not really hearing that anybody is truly burning to apply, though ... I think it needs to be more than a nice-to-do level of committment
14:19:41 <phasefx> well, co-mentor in dbwells case, I thought
14:20:01 <berick> ah
14:20:13 <berick> gmcharlt: agreed
14:20:24 <kmlussier> DPearl: Testing has been on the GSoC list since Evergreen started participating. But no student has taken it on. http://evergreen-ils.org/dokuwiki/doku.php?id=dev:summer_of_coding_ideas
14:20:39 <DPearl> Too bad
14:21:50 <bshum> gmcharlt: fwiw, I *would* like to do it and I think it's still worth putting efforts to get better community resources to bear on the subject of introducing new developers to Evergreen (having been in that position myself)
14:22:19 <bshum> But GSOC is only one potential source of putting that to fruition, I wouldn't want to push that if nobody who's been a mentor/admin really wants to.
14:22:22 <ktomita> spring01
14:22:31 <ktomita> oops wrong window
14:22:59 <bshum> (haven't not been part of past GSOC efforts)
14:23:10 <phasefx> bshum: you want to be a mentor volunteer or co-mentor with dbwells?  I'd say that's all we need for an application to be worthwhile
14:24:14 <pmurray> @marc 845
14:24:14 <pinesol_green> pmurray: [Described in full under field 845 in the MARC 21 Concise Format for Holdings Data.] (Repeatable) []
14:24:18 <bshum> phasefx: Yes, I would volunteer to mentor or co-mentor with dbwells.
14:24:27 <phasefx> bshum++ dbwells++
14:25:19 <phasefx> so given that, is there any reason now that we shouldn't do this?
14:25:33 <kmlussier> bshum++ dbwells++
14:25:53 * gmcharlt is not volunteering to be an org admin this year, but will assist somebody who does
14:26:26 <bshum> gmcharlt: Perhaps we can have a conversation about how the process works based on your experience post-meeting.
14:27:55 <gmcharlt> bshum: sure
14:28:04 <gmcharlt> so I think to sum up
14:28:37 <gmcharlt> #agreed bshum and dbwells have volunteered to be co-mentors; bshum to discuss org admin with gmcharlt
14:29:16 <dbwells> I can also help with admin i.e. be the backup admin, since I think that is required.
14:29:35 <gmcharlt> dbwells: yep, it is
14:29:45 <gmcharlt> so moving on
14:29:56 <gmcharlt> #topic Release info - OpenSRF
14:30:32 <gmcharlt> as mentioned previously, I'm willing/able to cut an alpha later this week
14:31:03 <berick> gmcharlt++
14:31:11 <eeevil> gmcharlt: thoughts on including https://bugs.launchpad.net/opensrf/+bug/1111799 in that?
14:31:11 <pinesol_green> Launchpad bug 1111799 in OpenSRF "MultiSession response polling results in high CPU usage" (affected: 1, heat: 6) [High,New]
14:31:13 <berick> gmcharlt: let me know if I can be of service
14:31:22 <gmcharlt> is there anything in the pipeline that would warrant making upcoming OpenSRF release _required_ for EG 2.4?
14:31:41 * bshum vaguely recalls at least one ticket saying such
14:31:47 <gmcharlt> eeevil: yep, that's one of the ones I specifically want to include in the alpha, along with the Perl service reload patch
14:31:49 <bshum> An acq thing from earlier today
14:31:51 <eeevil> gmcharlt: funny you should ask ... -^
14:32:36 <gmcharlt> bshum: eeevil: sounds good ... can you point me to the specifcs, or is the the multisession patch?
14:32:55 <gmcharlt> (see, I'm using that patch RIGHT NOW to construct my my sentences)
14:33:06 <eeevil> :)
14:33:37 <eeevil> gmcharlt: some pullrequest code wants it, and parallel hold targetter would be calmed during initial startup
14:34:07 <gmcharlt> eeevil: works for me; I'll push it to OpenSRF master unless I find an unexpected bomb lurking therein
14:34:31 <gmcharlt> upshot
14:34:51 <gmcharlt> #info looks like Evergreen 2.4 will require a mandatory OpenSRF upgrade
14:35:12 <gmcharlt> moving on
14:35:29 <gmcharlt> #topic Evergreen - 2.4 release - reviewing dependencies
14:36:49 <gmcharlt> looks like dbs added serveral.  taking them a bit out of order...
14:37:16 <gmcharlt> SpiderMonkey/libjs - question is whether it's time to officially deprecate script-based circ in 2.4
14:37:24 <Dyrcona> +1 to deprecate
14:38:23 <mrpeters> +1 i think its time too
14:38:33 <eeevil> SITKA folken: thoughts?
14:38:38 <bshum> +1 (though we may need to offer a bit of warning)
14:38:52 <bshum> I think jamesrf is gone from our ranks.  Not sure who's new from SITKA.
14:38:52 <mrpeters> +1 to advance warning, for some it may be a big process to migrate
14:39:12 <eeevil> I have no objection in principal. perhaps we should start by removing the dep-installer bits
14:39:13 <gmcharlt> bshum: the deprecation woudl be the warning, I think -- i.e., if we deprecate now, we'd expect to remove it entirely in 2.6
14:39:24 <eeevil> hrm... but... that may not be safe by itself
14:39:42 <mrpeters> 2.6 is probably what, a year or more off?
14:39:59 <eeevil> mrpeters: more or less exactly a year off
14:40:09 <mrpeters> yeah, i'd say thats more than ample warning
14:40:28 <gmcharlt> eep, I conflated Koha's version number scheme with EG's
14:40:46 <gmcharlt> I meant to say 2.5, but no reason not to wait until 2.6 to remove it if folks need the time
14:41:15 <bshum> That said, are any developers currently working with sites that still use script based circ?
14:41:22 <csharp> @karma everkoha
14:41:22 <pinesol_green> csharp: everkoha has neutral karma.
14:41:29 <bshum> It's not like I'm actively testing 2.4 and script circ to make sure it'll still work.
14:41:35 <bshum> (just using myself as an example)
14:41:38 <eeevil> kogreen?
14:41:48 * phasefx is trying to remember how circ_mod_map works today, incidentally :)
14:42:01 <mrpeters> bshum: emerald has at least one, maybe more i would have to ask
14:42:42 <bshum> I just worry about our ability to support/test/maintain it if the vast majority are leaving it behind already.
14:43:12 <mrpeters> how often do we have someone asking in here about legacy scripts?
14:43:23 <phasefx> I think there's already one org unit setting that just breaks with legacy scripts
14:43:25 <csharp> we should drop it in 2.4 IMHO
14:43:27 <gmcharlt> (almost) certainly no new libraries are implementing it
14:43:34 <mrpeters> i don't often see it, so i'd assume those still using it are managing it well internally
14:43:50 <bshum> (or trapped on Evergreen 1.6 or something ;)
14:44:00 <csharp> bshum: yep
14:44:18 <csharp> in which case they have bigger fish to fry ;-)
14:44:34 <gmcharlt> #info there's general agreement to deprecate legacy circ scripts in 2.4; and remove in 2.6
14:44:43 <gmcharlt> moving on
14:44:57 <gmcharlt> XUlRunner - there's a proposal to merge bug 1043819
14:44:57 <pinesol_green> Launchpad bug 1043819 in Evergreen "Firefox/XULRunner 15 is out, we should bump version numbers" (affected: 1, heat: 6) [Undecided,Triaged] https://launchpad.net/bugs/1043819
14:45:30 <bshum> I tested it months ago and it worked pretty well.  The only trick is that the newer xulrunners 15+ seemed to have a stronger tendency to completely crash out the client.
14:45:55 <bshum> I didn't manage to collect other data on the subject quite yet.
14:46:15 <Dyrcona> So sounds like more testing is warranted. I'll be happy to have a look, too.
14:46:27 <eeevil> gmcharlt: in your work plugging the leaking dike (how many thumbs do you have?), do newer xulrunners have a net effect, + or -?
14:46:55 <eeevil> gmcharlt: or is that a variable you've managed to avoid ;)
14:47:02 <paxed> bshum: i wonder if that's caused by moz slow inching away from remote xul, and not testing it?
14:47:05 <gmcharlt> eeevil: I've mostly avoided it to date
14:47:26 <bshum> I did feel that xulrunner 15 was better at memory management as was suggested as part of those discussions.
14:47:34 <gmcharlt> my main opinion is that we have to be prepared to throughly test an XULRunner we include in the main staff client installer
14:47:38 <bshum> At the very least, it seemed to free up the memory used by opening new tabs "quicker"
14:48:35 <gmcharlt> bshum: which makes an interesting tradeoff with crashing quicker :)
14:48:55 <Dyrcona> :)
14:49:06 * tsbere sees crashing as a method of freeing up *all* the memory in use
14:49:11 <bshum> gmcharlt: I called it a plus that people who used it said that their clients didn't feel slow anymore.  Till they crashed with no warning.
14:49:13 <tsbere> So in that regard it frees more memory faster!
14:49:16 <eeevil> I'm of the opinion, for 2.4, that we stick with what we have and get the mem leak fixes (such as they are, today) in
14:49:22 <gmcharlt> but seriously, I think for now bumping up the XULRunner version has to be considered on a release-by-release basis, because we're really at the mercy of Mozilla, particularly wrt the garbaage collector
14:50:00 <eeevil> then we have 5+mo to evaluate moz.current
14:50:18 <gmcharlt> that sounds reasonable to me
14:50:23 * dbs reappears from conflicting meeting land to answer bshum's question: we're still using script-based circ :)
14:50:52 <gmcharlt> dbs++ # now applying hook to drag you further into _this_ meeting ;)
14:51:16 <gmcharlt> as far as 2.4 is concerned, I think we have a pending action item
14:51:40 <gmcharlt> #action Dyrcona, bshum, gmcharlt to test and recommend whether XUL 15 should be included in 2.4
14:51:50 <gmcharlt> moving on
14:52:26 <gmcharlt> libdbi / libdbd-drivers -- currently installed from source for Squeeze and Lucid, from packages otherwise
14:52:51 <gmcharlt> does anybody have specific information about the minimum version required?
14:52:59 <eeevil> 0.83
14:53:19 <eeevil> and 0.9 will be out soon-ish
14:53:53 <gmcharlt> eeevil: upshot - wheezy can't hit stable soon enough ;)
14:53:56 <eeevil> (with, btw, API-based transaction and savepoint support for PG)
14:54:11 <dbs> eeevil++
14:54:39 <eeevil> dbs: I'm just the messenger (I didn't code that, though I did prod for it)
14:54:41 <gmcharlt> next, yaz and Net::Z3950::SimpleServer
14:56:15 <gmcharlt> but, actually, moving on to the bigger question: 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).
14:56:27 <gmcharlt> where it, presumably, is reviewing dependencies
14:56:47 * gmcharlt is +1 for making it a release checklist item
14:56:56 * dbs thinks "yes" so that we don't forget in the future :)
14:57:10 <Dyrcona> +1
14:57:42 <bshum> +1
14:58:39 <Dyrcona> I think that work would need to coordinated somewhat with the "distro champions."
14:58:44 <berick> the idea being, each distro champion ...
14:58:45 <berick> ;)
14:58:57 <Dyrcona> ;
14:59:04 <berick> +1
14:59:50 <gmcharlt> ok
15:00:08 <gmcharlt> #agreed release checklist to be updated with steps about checking dependency versions
15:00:12 <gmcharlt> 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.
15:00:23 <gmcharlt> or rather
15:00:31 <gmcharlt> #topic 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.
15:01:39 <gmcharlt> I suppose not much more to say about this than "Down with Brown Bag!"
15:01:53 <Dyrcona> Question: Does it need to be tested on all "supported" distros?
15:02:47 <gmcharlt> that would be nice, but depends on the distro champions being available to actually do that testing
15:02:51 <dbs> Testing once would be better than zero :)
15:03:25 <alexlazar> Latest LTE of Ubuntu would be good enough
15:03:41 <dbs> In an ideal future, automatic vm-builders would install & test. /me wants to fast-forward to that ideal future without doing any work
15:03:49 <alexlazar> For Ubuntu that is.
15:04:03 <eeevil> dbs: can I bum a ride to that when with you?
15:04:07 <gmcharlt> +1 to automation
15:04:18 <gmcharlt> that brings us to
15:04:19 <gmcharlt> #topic Proposed addition to release manager processes: clearly articulate supported platforms (i.e., OS, distro, browsers)
15:04:47 <Dyrcona> Did we actually vote on the last one?
15:04:57 <Dyrcona> Or, did it not require a vote?
15:05:33 <gmcharlt> Dyrcona: fair point, it's worth a vote
15:05:36 <dbs> FWIW, +1
15:05:45 <Dyrcona> +1
15:06:09 <bshum> +1
15:06:26 <dbwells> +1
15:06:52 <acoomes> +1
15:07:32 <gmcharlt> +1 # but volunteers to do that must present themselves when the time comes
15:07:41 <gmcharlt> no mandates without volunteers! :)
15:08:17 * Dyrcona can test on Ubuntu for now, possibly others in the future.
15:08:37 <eeevil> I'll vouch for Deb Squeeze ;)
15:08:44 <gmcharlt> heh
15:09:01 <phasefx> + backports
15:09:19 * gmcharlt suggest that we move the platform support policy discussion to the mailing list so that we can have time to discuss kmlussier's proposal
15:09:30 <dbs> +1
15:09:35 <phasefx> +1
15:09:38 <Dyrcona> +1
15:09:42 <bshum> +
15:09:46 <gmcharlt> so
15:09:50 <gmcharlt> #topic Software Performance Evaluation
15:10:22 <kmlussier> Still on my continuing quest for a software performance evaluation. :)
15:11:03 <kmlussier> I've pulled together a document to send to potential consultants and would like to get feedback from the community. http://evergreen-ils.org/dokuwiki/doku.php?id=dev:testing:performance_draft_rfp
15:11:11 <kmlussier> Either here or on the mailing list.
15:11:26 <kmlussier> But, more importantly, I'm hoping to get some volunteers to work with us on this.
15:11:57 <kmlussier> Although MassLNC is committed to leading and providing financial support, I'm really hoping it can be a community effort.
15:12:33 <kmlussier> For volunteers, I think it would be good if we got multiple people involved in the selection of a consultant.
15:12:55 <kmlussier> But, also, once the project starts, it would be good to have a group of point people that can be the main contact for any consultant that is brought on.
15:13:11 <kmlussier> I don't think I have any more to add.
15:15:11 <anyzh> Has the afternoon meeting begun ?
15:15:21 <gmcharlt> anyzh: yes, it's in progress
15:16:06 <anyzh> Guys,please go for GSOC .
15:16:29 <Dyrcona> anyzh: We've passed that in the agenda.
15:16:31 <gmcharlt> any immediate feedback on kmlussier's proposal?
15:16:34 <kmlussier> I've already volunteered Dyrcona and tsbere, but, since they are MassLNC partners, it doesn't help in my efforts to get input from others in the community. ;-)
15:16:57 * Dyrcona was about to say he volunteered himself and tsbere.
15:18:18 * StephenGWills thinks it's sweet the way they always volunteer each other :)
15:18:25 * gmcharlt knows that some ESIers have started added feeding back as well
15:19:06 <gmcharlt> OK, I think that wraps it up unless folks have any last minute topics
15:19:37 <Dyrcona> Well, I just wanted to add that this performance evaluation is rather important to Evergreen's image, at least around here.
15:20:17 <anyzh> So,what have ul decided about GSOC ?
15:20:35 <Dyrcona> Several groups in MA are looking to migrate to a new ILS and none are considering Evergreen because of horror stories from 1 consortium in particular.
15:21:30 <Dyrcona> And, the members of that consortium are talking about a drop dead date that if things aren't fixed, they'll look for a different ILS, not that I think they'll find one that works for them.
15:21:40 <mrpeters> horror stories with evergreen?  that sounds badly exaggerated
15:21:51 <SimonHM> Oh, anyzh, I think you will want to refer to the GSoC website for the description of the program and application process; it's a bit much to rehash now. This is what I got for you as I remember you're the one asking about Gsoc
15:21:52 <Dyrcona> mrpeters: I wish it were.
15:21:59 <mrpeters> thats sad, Evergreen is awesome
15:22:01 <dbs> Dyrcona: That kind of honest feedback is very helpful -- thank you
15:22:13 <kmlussier> Yes, the situation is critical. I guess one follow-up question is whether there is silence to the proposal because people don't think this is a good thing. It's just hard to get a read on what others in the community are thinking.
15:22:46 <anyzh> Simonh:- I only wated to know if Evergreen is going to participate in Gsoc this year .
15:22:48 * dbs thinks it's great, has very few cycles these days to do much though
15:23:07 <kmlussier> dbs: Thanks. That's helpful.
15:23:17 <berick> ditto dbs
15:23:25 <bshum> kmlussier: Agreed, I love the idea; just wish I had more clones of me to go around.
15:23:26 <paxed> imo, it would be good, but i can't offer anything more on it.
15:23:34 <kmlussier> My main concern is that if others aren't involved in the process, any work done by a consultant might be ignored.
15:23:51 <kmlussier> But I could be wrong on that score.
15:24:37 <gmcharlt> kmlussier: as to that .. I think it's very important that any consultant have prior experience (and success!) dealing with an active F/OSS community
15:24:54 <eeevil> kmlussier: the inverse is true, too... the earlier any consultant engages (particularly, before actually declaring X broken. ideally while planning) the more likely they'll get time-slices, I think
15:25:50 <kmlussier> eeevil: Sure, and my efforts will be focused on making sure they do reach out to the community as soon as possible and use them as the main point of contact. I want private contact between the consultant and MassLNC to be minimal.
15:25:54 <eeevil> kmlussier: the problem with that, of course, is having a squishy project...
15:26:18 <eeevil> (by which I mean budgeting is harder)
15:26:25 <eeevil> both time and money
15:26:39 * kmlussier nods
15:26:56 <eeevil> and I don't mean to discourage at all
15:27:14 <eeevil> it just may take ... creative contract construction
15:27:43 <kmlussier> eeevil: Sure. We've been giving a lot of thought to that too.
15:27:57 <eeevil> I don't doubt it! :)
15:28:06 <kmlussier> But it sounds like there's support for MassLNC continuing as we are.
15:28:24 <kmlussier> And thanks to everyone who added details to http://evergreen-ils.org/dokuwiki/doku.php?id=dev:testing:performance_issues. Feel free to keep adding ideas/issues as they come up.
15:28:49 <gmcharlt> OK, I think that takes us to a nice stopping point
15:28:52 <gmcharlt> #endmeeting