13:03:52 <gmcharlt> #startmeeting
13:03:53 <pinesol_green> Meeting started Wed Jan  9 13:03:52 2013 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:03:53 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:04:11 <denials> gmcharlt++ # seamless chair switchery
13:04:12 <gmcharlt> #info agenda is http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:next
13:04:40 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
13:04:53 <denials> #topic Roll call / introductions
13:05:01 <tsbere> #info tsbere = Thomas Berezansky, MVLC
13:05:05 <denials> #info denials = Dan Scott, Laurentian University
13:05:11 <kivilahtio1> #info kivilahtio1 = Olli-Antti Kivilahti, Regional Library of Joensuu
13:05:20 <dbwells> #info dbwells is Dan Wells, Hekman Library
13:05:28 <remingtron> #info remingtron is Remington Steed, Hekman Library
13:05:29 <paxed> #info paxed = Pasi Kallinen, Regional Library of Joensuu
13:06:14 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
13:06:20 <DPearl> #info DPearl = Dan Pearl, C/W MARS
13:06:22 <kmlussier> gmcharlt++
13:06:34 <eeevil> #info eeevil = Mike Rylander, ESI
13:06:53 <gmcharlt> OK, folks can continue to introduce themselves, but lets move on to the actual agenda
13:06:54 <gmcharlt> #topic action item from last meeting - edoceo to work on setting up a dojo 1.6 test server
13:07:08 <gmcharlt> edoceo isn't here, but does anybody else happen to know the status of this?
13:07:15 <senator> #info senator = Lebbeous Fogle-Weekley, ESI
13:07:35 <gmcharlt> ...
13:07:41 <gmcharlt> ok, moving on
13:07:54 <gmcharlt> #topic action item from last meeting: kmlussier to help coordinate end-user testing
13:08:28 <gmcharlt> the agenda indicates that this is awaiting the dojo test server, so unless kmlussier has more to say, I guess we can move on
13:08:44 <gmcharlt> #topic action item from last meeting: bshum will remove jspacremovalblocker from bugs that are not blockers and eeevil will send message to general list to ask people to identify blockers.
13:08:49 <kmlussier> Nothing more from me.
13:08:53 <bshum> #info Done.
13:09:02 <bshum> Well my part anyways.
13:09:21 <gmcharlt> bshum: great
13:09:22 <bshum> I think there was emails going around about blockers.
13:09:50 <eeevil> that evolved into a poll thanks to mrpeters-isl
13:09:58 <gmcharlt> yes, though more reminders probably won't hurt, especially given the desire many of us have to remove JSPac in 2.4
13:10:35 <gmcharlt> eeevil: willing to do more prodding?
13:10:44 <eeevil> aye
13:11:03 <gmcharlt> #action eeevil to continue to prod folks about jspac removal blockers
13:11:14 <gmcharlt> #topic action item from last meeting - denials to add a mention in the docs about PHP & Android efforts
13:11:17 <denials> #info Still to be done
13:11:29 <denials> #action denials to add a mention in the docs about PHP & Android efforts'
13:11:44 <gmcharlt> #topic action item from last meeting - GSOC_mentors to ensure related project code is moved to Evergreen git repos.
13:12:06 <gmcharlt> dbwells: eeevil: tsbere: senator: status?
13:12:11 <berick> #info berick Bill Erickson, ESI
13:12:23 <tsbere> I had Joe using Evergreen-hosted repos from the start.
13:12:28 <dbwells> #info It's all in here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/drizea/android
13:12:54 <senator> #info need to talk to pranjal about it
13:13:04 <denials> Can collab branches be force-pushed?
13:13:17 <tsbere> #info Joseph Lewis's dojo branch is here: http://git.evergreen-ils.org/?p=evergreen/joelewis.git;a=shortlog;h=refs/heads/dojo_1.8
13:13:25 <tsbere> denials: By the person who started them only
13:13:58 <eeevil> there are several branches, one of which is here: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/dsy/extension_in_c
13:14:24 <gmcharlt> great, thanks all
13:14:49 <gmcharlt> #topic OpenSRF release
13:15:06 <gmcharlt> this is just listed as a placeholder on the agenda -- anybody have anything concrete to say?
13:15:09 <denials> #info [placeholder]
13:15:11 <denials> :)
13:15:21 <gmcharlt> :)
13:15:33 <denials> I'm not aware of any pressing concern for a release, other than if we drop the /opensrf default prefix
13:15:53 <gmcharlt> fair enough
13:16:02 <denials> (which would be driven more by a desire to standardize install locations in Evergreen, per a branch I pushed)
13:16:03 <gmcharlt> #topic Evergreen monthly maintenance release schedule
13:16:09 <gmcharlt> #info http://libmail.georgialibraries.org/pipermail/open-ils-dev/2013-January/008729.html
13:16:39 <gmcharlt> I agree with berick that it sounds like there was no significant disagreement about this on the mailing list
13:16:54 <gmcharlt> but is there any additional discussion?
13:17:06 <berick> i have nothing to add
13:17:35 <gmcharlt> any objections to point releases being done on the 3rd Wednesday of each month?
13:18:13 <eeevil> I have an adjacent question
13:18:30 <gmcharlt> eeevil: go for it
13:18:44 <eeevil> major releases at the same time, a week later, or not tied to point releases at all? opinions!
13:19:27 <tsbere> Major releases at the same time would make sense
13:19:29 <eeevil> (FWIW, I'd prefer the major release not be tied to point releases, BUT I can see how "same time" would be useful to some)
13:19:49 <tsbere> But major releases and point releases at the same time would be more work all at once
13:20:00 <eeevil> right
13:20:04 <tsbere> I think I would want to vote for split on the work side alone
13:20:06 <denials> A week later would mean first point release would be 3 weeks later, rather than 4.
13:20:29 <eeevil> denials: or 7... ;)
13:20:30 <denials> Which would probably be warranted :)
13:20:30 <gmcharlt> I'd prefer that they not occur on that same day due to the work involved, and favor giving the RM discretion about the specific date
13:20:55 <gmcharlt> hopefully +/- only about a week, not indefinitely ;)
13:21:00 <denials> I think we agreed in several other conversations that the RM gets to move the date if things aren't release-ready
13:21:22 <gmcharlt> +1
13:21:32 <eeevil> denials: actually, yeah, having x.x.1 as a 3-week cleanup release sounds sane, but it also means lack of installation of x.x.0 ;)
13:21:35 <denials> RC at the time the point releases come out, to give one last week of hardcore testing to find brown paper bags?
13:22:04 <denials> eeevil: with our track record, I doubt most sites want .0 releases no matter how long after the .1 comes :/
13:22:42 <tsbere> A week earlier than the point releases (skipping that month for point releases on the new version, obviously) gives a little more time for finding things to go into the first potential point release
13:23:19 <denials> +1 to that
13:23:35 <eeevil> ok... so, RM's discretion, but generally co-incident (or, temporally related) with point releases is desirable.  (hint, this is prep for the schedule email I'm working on)
13:24:04 <gmcharlt> so to make this a concrete proposal, how about a vote on the following as a whole package: 1. the RC for a major Evergreen releases to be targeted for the week before point release day 2.  the .0 release to be targeted for the week after point release 3. RM has discretion to reschedule to avoid brown-bag releases
13:24:55 <denials> +1
13:25:00 * tsbere was thinking full release a week before the rest of the point releases, but isn't that concerned either way due to MVLC not using releases
13:25:16 <eeevil> +1
13:25:23 <bshum> +1
13:25:29 <senator> +1
13:25:41 <dbwells> +1
13:26:01 <gmcharlt> +1
13:26:08 <berick> +1
13:26:50 <gmcharlt> going once...
13:27:06 <gmcharlt> going twice...
13:27:12 * gmcharlt calls it
13:27:17 <senator> sold to the man in the ridiculous fedora
13:27:20 <gmcharlt> #agreed Evergreen maintenance/point releases for supported release series will be made on the 3rd Wednesday of each month, barring exceptional situations
13:27:26 <gmcharlt> #agreed The RC for a major Evergreen releases to be targeted for the week before point release day
13:27:37 <gmcharlt> #agreed .0 release to be targeted for the week after point releases
13:27:43 <gmcharlt> #agreed RM has discretion to reschedule to avoid brown-bag releases
13:28:00 <gmcharlt> #info the next 2.3 and 2.2 release is scheduled for January 16th. Merge while ye may.
13:28:15 <gmcharlt> any thing else on this before we move to the next topic?
13:28:31 <berick> nope
13:28:42 <gmcharlt> #topic Staff client memory problems
13:28:55 <gmcharlt> #info 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.
13:28:56 <pinesol_green> Launchpad bug 1086458 in Evergreen 2.3 "Staff client memory leaks in 2.3 and later" (affected: 3, heat: 20) [High,Triaged]
13:29:01 <kmlussier> I added that to the agenda.
13:29:27 <kmlussier> It's been reported by a few Evergreen libraries, and C/W MARS has been experiencing major problems with memory leaks since upgrading to 2.3.
13:29:35 <Dyrcona> Step 1. Get rid of Dojo in the staff client.
13:29:53 <denials> Dyrcona: oh, you've confirmed that?
13:30:05 <kmlussier> It's to the point where some libraries are not able to function. Lines out the door while they need to restart their clients.
13:30:09 <Dyrcona> It's one of the culprits, yes.
13:30:25 <berick> Dyrcona: why did it start in 2.3?
13:30:30 <berick> if it's dojo..
13:30:31 <kmlussier> So I'm hoping it's something the dev community can focus on.
13:30:42 <denials> Perhaps because it's Dojo from 3 years ago, rather than current dojo.
13:30:47 <Dyrcona> It's didn't start in 2.3. We've seen it all along, for two years.
13:30:57 <tsbere> I suspect that dojo is interacting more and more badly with upgraded xulrunner, making it more obvious as time goes on
13:31:02 <krvmga> for us in C/W MARS, it didn't start in 2.3, it just got worse.
13:31:10 <eeevil> Dyrcona: you mean, new-xulrunner made something much worse
13:31:18 <bshum> I always thought that the new xul being larger in general just amplified existing difficulties.
13:31:32 <bshum> There was murmuring about weird memory issues even before we landed on new-xul.
13:31:36 <bshum> Just much less vocal.
13:31:42 <gmcharlt> I know that there was some discussion of testing with xulrunner 15 ... has anybody got results from that?
13:32:14 <bshum> We had a library report pain and suffering with xul 17.  I just asked them to test again with a new xul 15 client yesterday.
13:32:28 <bshum> Once I know more I'll report our findings too.
13:32:59 * gmcharlt issues a plea for folks to centralize this kind of information
13:33:02 <tsbere> There are other concerns I have about some of the staff client javascript, particularly our treeviews (and the util.list code in particular)
13:33:11 <gmcharlt> bug 1086458 seems to be as good a choice as anything
13:33:13 <pinesol_green> Launchpad bug 1086458 in Evergreen 2.3 "Staff client memory leaks in 2.3 and later" (affected: 3, heat: 20) [High,Triaged] https://launchpad.net/bugs/1086458
13:33:25 <DPearl> Is EG dependent on a minimum version of xulrunner?  I'm doing tests with earlier xul's and I don't want to break anything.
13:34:12 <tsbere> At the moment it depends on 3.5+, but I may be breaking the ability of it to work before 4
13:34:27 <gmcharlt> tsbere: there's a note in the agenda that you're working on a possible longer-term fix; what's the nature of that?
13:35:35 <tsbere> It is a multi-step process. Step 1 is "make a fully functional fieldmapper that isn't in dojo and can be re-used across windows". That gets us the benefit of local windows not needing to re-parse the IDL (or re-fetch it in some cases)
13:36:27 <tsbere> My personal long term goal: 100% removal of dojo from the staff client
13:37:28 <denials> tsbere: so... that would explain why joelewis' work didn't really go any further :/
13:38:03 <tsbere> I gave up trying to figure out how to convert between dojo versions, given that it seemed to react more and more badly with non-HTML documents (which all of our XUL ones are)
13:38:26 <kivilahtio1> tsbere++
13:39:05 <phasefx> you also mentioned removal of DOM manipulation for xul lists, and using the nsITreeView interface, I think
13:39:14 <tsbere> yes, that is where util.list complaints come from
13:39:48 <tsbere> I figure once I have basic networking in place I will integrate a treeview interface factory into this as well
13:40:27 <tsbere> Note that everything I can find (and every person I have talked to) recommends not doing the DOM manipulation for those lists.
13:41:33 <gmcharlt> ambitious -- and controversy about the wholesale removal of dojo aside -- do we have anything concrete to offer in the short term to users of 2.3 if it turns out that going to xulrunner 15 doesn't offer enough relief?
13:41:42 * phasefx thinks that's a good direction (nsITreeView)
13:42:20 <phasefx> maybe run the staff client within a vm and take virtual image snapshots :-/
13:43:32 <phasefx> things get sluggish, restore to a previous snapshot.  even if the authtoken in the snapshot goes stale, it's faster to re-auth then than restart the entire client
13:44:07 <Dyrcona> yeah, the grey-haired grannies on the circ desk will love that "solution."
13:44:12 <phasefx> not a solution that could be widely/easily implemented, so stretching, yes :)
13:44:26 <krvmga> Dyrcona: you took the words out of my mouth.
13:44:29 <paxed> Dyrcona++
13:45:26 <denials> Well, assuming those are the primary culprits, it's good to have the info out in the open where more people can possibly contribute to a solution.
13:46:13 <phasefx> pre-emptive restarts during slow periods before things get sluggish, may be more viable
13:46:13 <krvmga> the situation is critical in C/W MARS.
13:46:30 <paxed> and it's not a general xulrunner bug?
13:46:44 <gmcharlt> do we have profiler data? any kind of memory leak data beyond gut feelings?
13:46:44 <bshum> phasefx: We've already instituted pre-emptive restarting as part of shift changes, etc.
13:46:53 <tsbere> Note that we have seen issues with some antivirus packages in a couple of libraries, and other software that hooks all mozilla apps can create issues as well
13:46:57 <phasefx> it's just like memory leaks in any web browser.  If you do something out of the norm with your javascript, leak
13:47:00 <kmlussier> I believe C/W MARS has too, but krvmga could confirm.
13:47:23 <tsbere> Leftovers from our previous ILS created major issues until uninstalled after migration, for example
13:47:31 <kmlussier> That is, they have done pre-emptive restarting.
13:47:47 <eeevil> let's pretend for a moment that new-xulrunner is the proximate cause, not dojo or DOM manipulation since they were not killing everything before. what would be the cost (in effort) of de-new-xulrunnering, I wonder?
13:47:47 <tsbere> and at least one antivirus package rendered one library unable to function. I believe that was a full Trend Micro security suite.
13:47:54 <phasefx> so a bug in xulrunner moreso than a bug in dojo; javascript shouldn't be able to cause memory leaks in an ideal environment
13:48:19 * Dyrcona would like to see this "ideal environment."
13:48:26 <tsbere> Every browser has memory leak issues with javascript and dom objects
13:48:39 <tsbere> Some are just better about it than others
13:48:41 <krvmga> kmlussier: yes, this is true. but the staff client memory use runs wild almost immediately
13:48:53 <phasefx> using closures, recursion, excessive DOM manipulation...
13:49:04 <paxed> would the xulrunner devs be interested in helping us out?
13:49:11 <denials> there have been numerous iterations of the JS engine in XULRunner; again, Dojo 1.3 would have been targeted & tested with XUL 3-ish, so wouldn't be surprising for old Dojo to interact badly with new XUL
13:49:12 <Dyrcona> You can't really compare the staff client to a browser anyway.
13:49:31 <Dyrcona> The staff client is stressing the JavaScript runtime way more than normal browser use.
13:50:50 <phasefx> I'm not convinced of that, but I would say that our javascript is certainly stressing XUL windows in different ways than Firefox/Thunderbird are
13:51:43 <DPearl> I am observing slowly increasing memory for my client even though it is idle.
13:51:45 <phasefx> here's a concrete suggestion.  Run two staff clients simultaneously; restrict one to one set of interfaces, and another to a different set.  Narrow down which interfaces are causing leaks
13:52:12 <phasefx> or which interfaces are causing leaks more drastically
13:52:22 <denials> So, again, assuming old Dojo is one of the primary culprits (and as gmcharlt suggested, reproducible memory profiling would be nice), we could 1) upgrade to current Dojo 2) switch to jQuery or some other JS framework 3) write and test our own JS framework?
13:52:49 <krvmga> phasefx: the checkin/checkout, other patron-related screens
13:53:12 <dbwells> We upgrade to 2.3 a few weeks ago, and no complaints yet.  I am going to poke around a bit, since it seems like something we are *not* doing is causing the problem.
13:53:24 <phasefx> krvmga: happens faster the more items get pumped through those lists?
13:53:24 <krvmga> most of our problems seem to revolve around circulation.
13:53:39 <DPearl> Agreed: circulation
13:53:44 <krvmga> i'm guessing because more transactions pile up more quickly in this area.
13:53:47 <bshum> I would agree with krvmga that circulation tends to be the culprit.
13:53:50 <tsbere> I don't think we need a "framework" as it is, at least not for the staff client.
13:54:09 <tsbere> XUL itself is basically a framework. We just need to plug our pieces into it. And I am working on that already.
13:54:28 <phasefx> krvmga: bshum: how about using the web-based self-check (on a staff machine) for circ as an emergency fallback?
13:54:30 <bshum> (or at least, the people using circ machines complain more than any other department)
13:54:53 * dbwells wanders downstairs to circ to check on the current memory usage
13:54:54 <kivilahtio1> If frameworks are considered, I vote for jQuery
13:54:55 <krvmga> phasefx: we have considered this but it doesn't deal with all the other patron-related business
13:55:06 * phasefx nods
13:55:08 <krvmga> fines, account problems, etc.
13:55:23 <phasefx> but may slow the rate of trouble
13:55:48 <krvmga> it also reinforces the idea that EG is broken and why are we using it...
13:55:49 <phasefx> trying to think of short-term stop-gap strategies
13:55:55 <bshum> I'd also point out that it's not a consistent problem.  It only affects 1 or 2 machines of each library.  Not all of them.
13:56:01 <bshum> For us anyways.
13:56:35 <denials> kivilahtio1: my general point was that any JavaScript that we use needs to be current & tested, and that Dojo / jQuery both get tested by magnitudes more than just our community. albeit, our XUL usage is pretty niche.
13:56:43 <denials> bshum: oreally?
13:56:55 <denials> That's a pretty important data point
13:57:24 <kivilahtio1> denials: got that, but still I vote for jQuery, as no way we should program our own. And jQuery is cool z3
13:57:26 <gmcharlt> krvmga: what about at CW/MARS - is the probably wide-spread or affecting just particular libraries and/or workstatiosn?
13:57:58 <krvmga> gmcharlt: we've just been doing some surveying along this line and it seems to be affecting everyone
13:58:11 <krvmga> some are more prone to complain than others
13:58:20 <krvmga> but when asked they all give similar responses
13:59:06 <krvmga> the workstations that experience the problem the worst are the circ stations
13:59:43 <kivilahtio1> krvmga: what is the rate of memory consumption increase?
13:59:54 <denials> Our circ desk replaced its 4-year-old machines with 1GB of RAM with newer, more memory-full models; there had been some issues with those after we moved to 2.3, but since then no complaints
14:00:01 <eeevil> kivilahtio1: there are significant (html, non-xul) staff client interfaces already built atop dojo ... replacing all those would be part of jquery-izing, so a modern dojo is really a more natural next step given our resources
14:00:20 <krvmga> kivilahtiol: the last time i checked it was a couple of megs per transaction. i havent checked in the past day or so.
14:01:06 <tsbere> eeevil: My personal goal is still 100% dojo removal from staff interfaces. I am willing to re-write as many things as I need to in order to accomplish that as it is. ;)
14:01:08 <kivilahtio1> eeevil: figures. And seems to be more reasonable. I was just excited about the possibility for change ;)
14:01:20 * tsbere is *not* willing to turn things into jquery
14:01:27 <kivilahtio1> tsbere: why?
14:01:29 <krvmga> after a couple of hours of business, EG memory use can be pushing 2GB
14:01:35 <eeevil> tsbere: personal goals aside, perhaps that's a discussion for the community as a whole?
14:02:01 <kivilahtio1> kfvmga: but do you get idle memory loss?
14:02:01 <tsbere> eeevil: I brought this up at an in person meeting. I was told to come up with a way to accomplish several things. I am working on that now. :P
14:02:29 <kivilahtio1> krvmga: do you get memory loss when idling?
14:02:41 <krvmga> kivilahtiol: i'd have to check. although some people have reported this to me, i haven't seen it personally.
14:02:43 <eeevil> huh ... wow
14:03:09 <gmcharlt> to sum up -- unless we get lucky and the act of switching to xulrunner 15 provides enough temporary relief -- I'm not seeing that any short-term solution is on the table
14:03:32 <krvmga> gmcharlt: this is disastrous for us here.
14:03:33 * denials will check circ desk memory stats, like dbwells, but will have to take off in 28 minutes
14:03:43 <kivilahtio1> krvmga: are you running on windows?
14:04:18 <krvmga> kivilahtiol: virtually everyone in the consortium runs windows machines. (i think we have one exceptional bunch running some flavor of linux)
14:04:21 <jeff> i'm joining the meeting late, so i'm sorry if this has been mentioned already and i missed it: is there a minimum version of Evergreen where these memory problems seem to have started?
14:04:22 <bshum> gmcharlt: I'll be sure to write our findings to the bug ticket with newer xulrunner testing.  But I don't think that'll be enough to make the difference by itself.
14:04:26 <tsbere> I agree with gmcharlt, there is no short term solution. At this point we should move on and let people collect data.
14:04:30 <eeevil> gmcharlt: that's my read ... new-xulrunner pushed dojo over a tipping point (or, that's the consensus blue-sky, no-data-shown guess), and we're not willing to entertain rolling back new-xulrunner, I guess?
14:05:05 * denials hates to bring up another release subject, accordingly, but is there any hope of putting the release naming discussion to bed (at least for another year)?
14:05:06 <tsbere> eeevil: We could change the xulrunner version to a *lower* one. I think we are technically compatible all the way back to 1.9.2/3.5 still....
14:05:06 <gmcharlt> eeevil: well, rolling back new-xulrunner is an option; do we have an answer to your question about how much effor that would entail?
14:05:11 <kivilahtio1> krvmga: do the linux guys suffer as well=
14:05:27 <eeevil> gmcharlt: I've seen no answer... maybe I missed it
14:05:28 <senator> denials: i certainly plan no more replies to that or similar threads, fwiwi
14:05:30 <krvmga> kivilahtiol: i have no data atm.
14:05:48 <tsbere> gmcharlt: Minimal changes to use an older xulrunner version. Singificant ones to undo the changes to make newer ones work.
14:06:00 * gmcharlt squelches the version number discussion for the moment
14:06:12 <eeevil> denials: let's call it RM discretion and watch the fireworks? ;)
14:06:34 * jeff belatedly sees the answer to his question staring him in the face in the title of the bug
14:06:45 <eeevil> I WILL CALL HIM GEORGE ... POINT THREE
14:06:55 <kivilahtio1> eeevil: ++
14:07:17 <eeevil> in all seriousness, please, squelch it :)
14:07:28 <gmcharlt> tsbere: krvmga: I can arrange testing with an older xulrunner version in fairly short order (i.e., today)
14:08:00 * gmcharlt crosses fingers
14:08:00 <denials> One random circ workstation that's been running for 6 hours (Windows 7) is at 760 MB
14:08:01 <krvmga> gmcharlt: bshum: didn't bshum test with multiple old xulrunner versions?
14:08:03 <tsbere> gmcharlt: Just change the version. You can probably even "make XULRUNNER_VERSION=blah win-xulrunner" type thing to play with multiple.
14:08:32 <gmcharlt> krvmga: bshum can speak for himself, of course, but I thought he was testing with *newer* versions
14:08:37 <Dyrcona> Somebody asked if we have memory leak issues with xulrunner on Linux?
14:08:46 <bshum> Yes, I've been testing xulrunner 14+
14:08:53 <kivilahtio1> Dyrcona: I asked krvmga
14:09:07 <bshum> Downgrading to me is a bad step backwards that I'd prefer not to take if only for speed/compatibility reasons.
14:09:15 <krvmga> Dyrcona: in C/W MARS we have one library that is using linux on their machines
14:09:23 <Dyrcona> kivilahtio1: Ok.
14:09:37 <Dyrcona> I'm using it on my desktop, but hardly use the client at all.
14:09:55 <dbwells> All of our circ stations ranged from 150 to 500MB of memory usage, also after 6+ hours of use, FWIW
14:10:30 <gmcharlt> bshum: in the short term, which xulrunner version is used can readily be left at the discretion of local sites; I agree that we wouldn't want to permanently bake in a requirement to use an antique version of xulrunner
14:10:34 <krvmga> dbwells: those are the kind of numbers we had before the upgrade to 2.3.1
14:10:36 <gmcharlt> we already have enough of that :)
14:10:37 <paxed> Dyrcona: kivilahtio1 and me also use it on linux, but just for testing stuff, not working with it.
14:10:58 * gmcharlt reigns the discussion in
14:11:09 <kivilahtio1> unfortunately, for political reasons
14:11:24 <gmcharlt> #action testing to be performed by various parties with older xulrunner versions
14:11:57 <gmcharlt> and dare I propose this: #action a meeting gets called to hash out the future of the staff client
14:12:00 <gmcharlt> ?
14:12:18 <phasefx> +1
14:12:24 <bshum> +1
14:12:25 <krvmga> +1
14:12:25 <paxed> agreed
14:12:25 <kmlussier> +1
14:12:25 <senator> +1
14:12:32 <eeevil> +1
14:12:34 <jeff> +1
14:12:38 <tsbere> So long as it is not at the conference I +1 that ;)
14:12:45 <eeevil> weapons required?
14:12:51 <kivilahtio1> we get one in four months!
14:12:55 <gmcharlt> tsbere: yeah, I rather think it needs to be held earlier than the conference :)
14:13:08 * tsbere just doesn't want to miss it due to not being *at* the conference ;)
14:13:09 <kivilahtio1> or before te conference?
14:13:10 <denials> +1
14:13:24 <gmcharlt> #action gmcharlt will call a development meet to hash out the future of the staff client, to occur before the EG conference
14:13:27 <kivilahtio1> so we have one year to cool down
14:13:28 <dbwells> Concerning the memory leak, I would be curious to know if consortium size somehow plays a role.  We have only 12 org units.  I'll add some of these thoughts and data to the bug.
14:13:29 <kmlussier> I think sooner is better.
14:13:41 <gmcharlt> kmlussier: agreed
14:13:55 <jeff> of cource, irc and mailing list conversations can end up being more productive than just "a meeting", a meeting or so could serve as kickoff/waypoints
14:13:59 <jeff> (savepoints?)
14:14:01 <denials> gmcharlt: can I also propose "Sites running 2.3, please submit detailed workstation profiles - RAM, Windows version, 32 or 64 bit, what other programs are installed and running, etc"
14:14:32 <gmcharlt> denials: and attach them to bug 1086458
14:14:33 <pinesol_green> Launchpad bug 1086458 in Evergreen 2.3 "Staff client memory leaks in 2.3 and later" (affected: 3, heat: 20) [High,Triaged] https://launchpad.net/bugs/1086458
14:14:34 <gmcharlt> +1
14:14:43 <krvmga> denials: we can try that but it's going to be hundreds of machines
14:14:46 <denials> dbwells: our # of circ transactions is probably 1/10th or 1/100th of a public library, so there's that :/
14:14:58 <denials> krvmga: well, representative samples :)
14:15:01 <jeff> average circulation operations performed on a workstation having the issue vs one not having the issue may also be useful. i'll mention that in the bug also.
14:15:01 <dbwells> denials: right
14:15:07 <jeff> (if not already there)
14:15:10 <krvmga> denials: :)
14:15:25 <kmlussier> krvmga: Do your academics report this problem?
14:15:30 <dbwells> denials: but nothing we can't emulate ;)
14:15:35 <gmcharlt> #action denials will issue a call for Evergreen 2.3 users to submit detailed workstation profiles
14:15:51 <gmcharlt> and now
14:15:56 <krvmga> kmlussier: i am getting a steady stream of reports now from both publics and academics
14:16:29 <gmcharlt> #topic proposals changing the procedure for  reviewing and pushing new feature patches
14:16:54 <gmcharlt> #info proposal #1 from 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 wi
14:17:06 <gmcharlt> #info ...  without the community looking over them just because they have one or more core committers in their employ.
14:17:29 <gmcharlt> #info proposal #2 from tsbere - 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.
14:17:57 <kivilahtio1> Sounds great
14:18:19 <gmcharlt> FYI, I will be ending the meeting no later than 12 minutes from now
14:18:56 <bshum> I'm +1 to proposal 2 if only because I've been participant to pushing new changes without waiting for all the comments to settle first.
14:19:10 <gmcharlt> tsbere: your proposal text seem pretty complete, but is there anything you want to add?
14:19:34 <tsbere> I don't think so, unless people have questions for me, anyway.
14:19:43 <jeff> seems reasonable at first glance. i'd be interested in hearing from anyone who sees issues or overlooked subtleties.
14:19:49 <paxed> are there enough active community members so proposal #1 doesn't keep stuff in limbo?
14:19:56 <senator> i'm -1 on these
14:20:08 <senator> because of stuff sitting in limbo as it is
14:20:28 <senator> in the future, when we have more active testers of master and feature branches, maybe
14:20:37 <kivilahtio1> that is a solid point
14:21:02 <kivilahtio1> well, we need to wait for 1 week for acceptance. If things stay in the limbo for two weeks, we can ommit to master?
14:21:06 <tsbere> I figure that saying "no, work from group A can't go in without someone else looking at it" results in each group doing more looking at other work, instead of possibly looking at only their own stuff.
14:21:37 <kivilahtio1> but this would help alleviate issues with internationalization for example
14:21:42 <phasefx> I'm -1 on first, +1 on second.  I think if multiple committers from the same organization are inappropriately fast tracking things, the community should call them on it, but we shouldn't encumber ourselves beforehand
14:21:59 * jcamins probably doesn't count, being a Kohan, but can't resist throwing in his two cents on an issue near and dear to his heart.
14:22:00 <kivilahtio1> so we have more time to make sure that things can be internationalzied
14:22:14 <jeff> trial period, where it is encouraged to wait the week and get sign-off from another organization, and see if this results in more things stuck in limbo?
14:22:42 <jcamins> Koha has adopted a QA policy requiring at least two, and generally three, different entities to review a patch before it gets pushed.
14:22:45 * denials points at http://evergreen-ils.org/dokuwiki/doku.php?id=dev:signoff_review_checklist again (which we liked last time, but hasn't been formally adopted) for the sake of kivilahtio1's i18n concern, at least
14:23:00 <dbwells> I think both of these proposals are good common sense guidelines, but I am not in favor of mandating them until there is a clear reason to do so.
14:23:12 <jcamins> It works well enough for keeping problematic code out, but it does not do much to encourage people to review code.
14:23:30 <denials> keeping problematic code out is a win :)
14:23:38 <denials> my code would never get in
14:23:43 <jeff> one issue i can see would be where there is not cross-organizational expertise in an area. no examples immediately jump to mind.
14:23:55 <berick> edi comes to mind
14:24:33 <jeff> apologies if i'm forgetting/overlooking a serials expert, but senator or dbwells being on vacation could present a potential roadblock.
14:24:34 <kivilahtio1> don't we get karma for code reviews?
14:24:35 <kmlussier> berick: I agree with you on the edi point.
14:25:09 <phasefx> for documentation commits, I'd be inclined to reduce barriers even further, and not even require double sign-offs
14:25:15 <denials> yeah. I'm with dbwells. Maybe add a note to the commit checklist saying "Generally it's a good idea to let the community take a peek before this is committed - has the bug been open and branch visible for a few days?"
14:25:24 <paxed> and what jeff said tells me there's not enough active people for either of those proposals to work for now...
14:25:26 <denials> phasefx: we don't require double sign off for docs. so that's good
14:25:32 <phasefx> gut
14:25:33 * gmcharlt tosses out an idea -- since part of the concern is getting eyes on code and making sure that more than one organization understands what's going on ... what about trying the occassional 30-minute IRC meeting where somebody does a walkthrough of a new proposed feature patch?
14:25:39 <jeff> tsbere: do you have any opinion on adopting these as recommendations and not strict rules?
14:26:05 <paxed> gmcharlt++ # would also help noobs (like me) understand what's going on
14:26:05 <tsbere> I already use them as personal guidelines, I figured making them official might help ;)
14:26:11 <kivilahtio1> gmcharlt: dont we have blueprints for that?
14:26:16 <paxed> ...without explicitly bugging people in here
14:26:25 <gmcharlt> kivilahtio1: blueprints aren't interactive
14:26:29 <jcamins> Since you have more people who can push code, a compromise position might be to send messages to the developer list saying "I would like to push these five patches in the next two days. Would anyone else like to test?"
14:26:43 <jeff> "new feature Q/A" in irc sounds promising.
14:26:54 * senator can live with what jcamins is saying now
14:26:55 <kivilahtio1> jeff: ++
14:26:57 <senator> we sometimes do that anyway
14:27:20 <senator> and gmcharlt's idea doesn't sound bad either
14:27:40 <jcamins> senator: yeah, I've seen some announcements on IRC, and it seems a fairly simply addition to put the announcements on a mailing list.
14:27:49 * jcamins is going to steal gmcharlt's idea for Koha.
14:27:59 <kivilahtio1> we just need to read the mailing list
14:28:43 * gmcharlt calls a vote - that 1. tsbere's two proposals be accepted as recommendations but not requirements 2. and that around the time of the conference, we see how the pullrequest queue is doing
14:29:37 <denials> 1. +1
14:29:45 <bshum> +1
14:29:58 <Dyrcona> (+1, +1)
14:30:04 <denials> 2. Ideally before, so things could get lined up for $RM_VERSION_NAME
14:30:10 <kivilahtio1> (+1,+1)
14:30:18 * denials takes off
14:31:45 <jeff> +1
14:31:54 <paxed> +1
14:32:22 <phasefx> +1
14:32:52 <senator> +1, +1
14:33:48 <dbwells> +1, +1
14:34:47 <kivilahtio1> Speaking of 30-minute IRC-meetings I have a question regarding searching after this meeting has adjourned
14:34:56 <gmcharlt> #agreed accepted as recommendations - new feature patches ought to have signoffs from two or more groups in the community; new feature pull requests should wait at least a week before being pushed
14:35:17 <gmcharlt> #agreed review of the pullrequest queue to occur by (or before) the 2013 EG conference
14:35:23 <gmcharlt> and ... that's a wrap
14:35:26 <gmcharlt> #endmeeting