15:00:45 #startmeeting Evergreen Development Meeting 2018-08-08 15:00:45 Meeting started Wed Aug 8 15:00:45 2018 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:45 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:45 The meeting name has been set to 'evergreen_development_meeting_2018_08_08' 15:00:57 #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-08-08 15:01:30 #topic Introductions 15:01:37 #info Dyrcona is Jason Stephenson CW MARS 15:01:40 #info gmcharlt = Galen Charlton, Equinox 15:01:41 #info miker == Mike Rylander, EOLI 15:01:44 #info dpearl is Dan Pearl (C/W MARS Inc.) 15:01:55 #info berick = Bill Erickson, KCLS 15:02:00 ha! pinesol, hush 15:02:08 #info abneiman is Andrea Neiman, EOLI 15:02:26 #info remingtron is Remington Steed, Hekman Library (Calvin College) 15:02:40 #info dbwells is Dan Wells, Hekman Library (Calvin College) 15:03:54 #topic Action items from previous meeting 15:04:15 one was csharp loading an update for the Hatch FF add-on 15:04:21 csharp: did that happen? 15:05:13 csharp may not be here. He said earlier he has a schedule conflict. 15:05:13 i think csharp said he'd be missing the meeting 15:05:16 ah, OK 15:05:26 so, next was in regards to OpenSRF 3.0.2 15:05:57 and since testing for bug 1774703 in production has not been promising, and it looks like we'll likely be changing websocket servers, no bugfix release 15:05:59 Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703 15:06:13 but I have issued a call for roadmap entries for OpenSRF 3.1 today 15:06:33 gmcharlt++ 15:06:38 #info Roadmap entries for OpenSRF 3.1 can be added here: https://wiki.evergreen-ils.org/doku.php?id=dev:opensrf_roadmap 15:06:53 with, at present, websocketd being the biggest one targetted 15:07:07 * Dyrcona ponders adding SASL support. 15:08:00 there's also https://bugs.launchpad.net/opensrf/+bug/1702978, which is just a bugfix, but the full fix adds a small change to the ABI 15:08:01 Launchpad bug 1702978 in OpenSRF "memcache keys containing % fail" [High,Confirmed] 15:08:05 #info dbs = Dan Scott, Laurentian 15:08:10 win 31 15:08:25 dbs: ancient history man, ancient history 15:08:30 Christel just posted this "denial" on the freenode blog https://freenode.net/news/spam-shake Why does this blog post mention "10.2 million" THREE times? 15:08:35 This blog is essentially an ad for the Handshake ICO scam with a one-line "denial" of involvement mixed in there. It's obviously very unethical of Christel to not mention her own involvement in the scam which the blog post promotes. 15:08:39 Consider Andrew Lee's involvement, Andrew Lee is Christel's boss at London Trust Media and he also controls the majority of freenode voting rights. Andrew Lee also heads the handshake ICO scam. Coincidence? 15:08:56 #info kmlussier is Kathy Lussier, MassLNC 15:09:13 #action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF 15:09:23 but for another update 15:09:41 #info berick and gmcharlt have scheduled a presentation to discuss new Angular at the hack-a-way 15:10:10 it will be on Monday 11/5 15:10:26 so y'all will be expected to be fresh! and full! of vim! and vigor! 15:10:34 (or be full of emacs, if you must) 15:10:39 heh 15:11:09 * bshum has a soft spot for nano 15:11:17 #info kmlussier and JBoyer finished their review of https://bugs.launchpad.net/evergreen/+bug/1750894 15:11:19 Launchpad bug 1750894 in Evergreen "Wishlist: Store web staff workstation settings on the server" [Wishlist,Fix committed] 15:11:28 and that does it for action items 15:11:40 and for that matter, the OpenSRF release update 15:11:46 so, without further ado 15:11:50 #topic Evergreen release 15:11:52 berick? 15:12:14 jump into 3.2 stuff? 15:12:20 alright.. 15:12:20 sure 15:12:27 buildmasters wanted. 15:12:42 first builds will be early next month 15:12:52 #info https://docs.google.com/spreadsheets/d/1gZayHfF7qK0zwLMEAXt-PbKBMiAM_F6EZguqzIYceBY/edit#gid=0 15:13:19 i realized I have some travel plans this month 15:13:46 so I propose we push the feature slush deadline back from the 17th to the 22nd 15:13:57 +1 15:14:03 not critical, but I'd prefer to be around for the deadline 15:14:12 (though I'll be away for the days leading up to it) 15:14:17 +q 15:14:19 +1 15:14:21 :) 15:14:37 that may mean pushing back the feature freeze, but I was going to see how things go 15:14:53 I'm always in favor of later feature freeze deadlines. :) 15:15:20 :) one in the plus column there 15:16:03 and finally, csharp had some good luck testing the ang6 code today 15:16:15 cool 15:16:16 there's some momentum toward including it in 3.2 15:16:35 if we do, we need to decide soon what in the 3.2 code should be available to staff 15:16:42 so we can test those bits specifically 15:16:49 we're limited to some admin UI's at this point 15:17:17 Is it all of the admin uis or just some of them? 15:17:23 also, good everyone understands that means adding a new build step when installing from source. 15:17:26 I'd prefer just dojo-replacing code ATM (and infrastructure and static-ish pages) 15:17:36 Dyrcona: just some of them 15:17:44 miker: agreed 15:17:46 * Dyrcona agrees with miker. 15:18:01 +1 15:18:07 it's about 2/3 of the server->admin pages and acq admin pages 15:18:34 i can propose a list of pages to thumbs up/down if that helps 15:18:39 I can probably arrange some testing of those soon, even though I'll be out most of next week. 15:18:39 then we can test them 15:19:47 ok, so I'll get the ang6 branch into final merge-able state and.. 15:20:12 put together a list of admin UI's that should be suitable for using in 3.2 as replacements for the dojo versions. 15:20:25 that will also mean modifying the links in the angjs app to point to the same new UI's 15:21:40 otherwise, re: 3.2, we've closed a few more blockers in the past ~week 15:21:41 berick++ 15:22:00 and of course, those are not bound by the feature slush, but sooner the better, obviously 15:22:12 any questions for me? 15:23:16 Well, I have a question for "room" generally. 15:23:31 What do we think the odds of being able to remove XUL in 3.2 are at this point? 15:23:40 * kmlussier was about to ask a similar question. 15:23:46 good question 15:24:09 * gmcharlt can commit to a patch to disable it sufficiently for release purposes 15:24:15 We've actually had at least one library "give up" and go back to XUL on 3.0. 15:24:19 but that's kinda the much easier question 15:24:29 the room asks back: what's the bar for removing XUL? all blockers gone? something more (or less)? 15:24:52 We still have a handful of blockers - https://bit.ly/2MvbmsT 15:25:01 Well, I guess that's part of my question, too, because I don't have a definitive answer on what the bar should be. 15:25:36 My thought was that blockers are blockers that prevent people from moving to the web client. 15:25:43 * miker suspects that bug 1768947 might be gone now, with the new offline code in 15:25:45 Launchpad bug 1768947 in Evergreen "web client: non-hatch white screen issues" [Medium,Confirmed] https://launchpad.net/bugs/1768947 15:26:07 that's the hope 15:26:13 and some of those have pullrequests... 15:26:21 My preference would be that we remove XUL no matter what from 3.2, and that we commit to supporting 3.1 until all blockers are gone. I can do my part for the second piece of that. 15:26:24 miker: The code just went in today. I thought it would be good to keep it open until people start using EG with the fix. 15:26:34 and some of those i18n bugs might need re-verifying after the IDL fix 15:26:39 kmlussier: totes agree 15:27:24 My preference is to wait on xul removal until the blockers are gone. Otherwise, we could be supporting 3.1 for a very long time. It's extra motivation. 15:27:36 i'd be a little surprised if we haven't broken some stuff in XUL by now 15:28:04 I share dbwells' view 15:28:35 I'd rather an extended 3.1 support period (which I can also help with) than an indefinite postponement of the cutoff 15:29:10 kmlussier: from another perspective, removing XUL is motivation to fix the blockers 15:29:13 I think having XUL removed from 3.2 is a really strong motivation to work on blockers. 15:29:19 It also does no good to keep XUL if much of it is broken. 15:30:01 the biggest "breakage" AFAIK is copy alert msg vs alert matrix 15:30:16 but that's a known quantity 15:30:21 In any case, I would be willing to take an action item to test any webstaffblockers with a pullrequest. 15:31:07 There are a couple of bugs there without pullrequest tags that I know are big concerns for our libraries. 15:32:02 if anyone can describe a way to reproduce bug 1724029, i'll happily fix that one. 15:32:04 Launchpad bug 1724029 in Evergreen "Web Client: Patron Search sorted by last name not working as expected" [High,Confirmed] https://launchpad.net/bugs/1724029 15:32:24 or give me SSH access to their prod servers! 15:32:39 berick: right on 15:34:29 we have a little over a month before RC is cut. 15:34:43 if it looks like we're really close on the blockers, that can also be pushed back. 15:34:57 i'd rather not yet, just to avoid procastination 15:35:20 Here is my concern. Way back in the jspac removal days, we had a bunch of bugs with blocker tags on them. But we decided to remove jspac without addressing the blockers, and a lot of them sat in LP without any love. 15:35:33 I really don't want to delay removing the XUL client, but I would hate to see something like that happen again. 15:37:00 an increasingly broken XUL client also imposes costs on users 15:37:44 and new blockers will be opened during the 3.2 cycle :| 15:38:04 berick: Of course! :) 15:40:07 so... I think it's fair to say that we have an open question - but one that maybe we can punt until closer to release? 15:41:13 my only request is the XUL removal code be merged by beta cutting day (1 month from today) so it can get some real testing 15:41:42 so ideally decide then-ish 15:41:46 sounds like a plan, or a guideline, anyway 15:42:44 any other questions regarding 3.2? 15:42:58 or any questions or updates regarding maintenance releases? 15:45:19 Nope 15:45:20 ok 15:45:30 #topic Hatch updates 15:45:40 * gmcharlt summons the spirit of csharp-past 15:45:46 #info No new releases since last meeting 15:45:49 onward 15:46:00 #topic Feedback for stuff under development 15:46:16 #info Dyrcona would like eyes on the patch for bug 1780660 15:46:17 Launchpad bug 1780660 in Evergreen "Add More Workstation Functions to OpenILS::Utils::TestUtils" [Wishlist,Confirmed] https://launchpad.net/bugs/1780660 15:46:24 Dyrcona: any comments to add? 15:46:37 Just a bit of me being selfish and cleaning up some test code. 15:47:17 When writing Perl tests recently, I noticed we had at least 3 different implementations of code to add workstations for testing. 15:47:45 So, thought I'd come up with a single version of the necessary functions and add them to TestUtils. 15:47:52 Dyrcona++ 15:48:05 +1 15:48:14 I'm also using the changes in the tests in my working branch, so I'd like the changes to go in before I rebase. 15:48:45 Should be simple to test. Just check out the branch cd to perlmods and run make livecheck 15:49:20 I rebased the branch after someone updated a test this week, too. 15:49:36 Dyrcona++ 15:50:08 * miker is willling to simply push it having read the commit 15:50:11 So, that's my shameless plug. :) 15:50:30 the CI tester will tell us if it is unhappy 15:50:42 :) 15:50:56 DRY: applies to cubicle farms and workstations? 15:50:59 * gmcharlt ducks 15:51:44 DONE 15:51:45 miker: heh, oh yeah, let's put that machine to work 15:52:27 ok 15:52:40 so any other pull requests that folks would like to draw attention to? 15:52:54 * miker dusts of his committing finger 15:53:18 [evergreen|Jason Stephenson] LP 1780660: Add more workstation functions to OpenILS::Utils::TestUtils. - 15:53:40 I'd like to see the %-in-usernames patch go in ASAP 15:54:07 there's one for each of EG and OpenSRF 15:54:23 miker: Which bug number is that? 15:54:37 * miker looks... terrible LP searching... grumble 15:55:18 Is that bug 1702978 ? 15:55:20 Launchpad bug 1702978 in OpenSRF "memcache keys containing % fail" [High,Confirmed] https://launchpad.net/bugs/1702978 15:55:35 Dyrcona: yeppers 15:55:53 there's a non-abi-breaking version posted currently 15:56:29 Are there any advantages to the abi-breaking version? 15:57:04 it would keep someone from accidentally implementing a similar bug 15:57:37 but that part can be reserved for OpenSRF 3.1 IMO 15:57:40 but requires tighter coordination between EG and OSRF 15:58:11 regarding things in need of testing, several cataloging bugs have PRs -- bug 1732761 bug 1675882 bug 1739460 bug 1739286 -- a couple of which are flagged as blockers 15:58:17 Launchpad bug 1732761 in Evergreen "Web Client - When adding vols/copies to multiple branches, circ library does not populate" [High,Confirmed] https://launchpad.net/bugs/1732761 15:58:17 OK. I'll see about having a look at it. 15:58:18 Launchpad bug 1675882 in Evergreen "webclient: adding individual copies defaults circ OU to workstation OU" [Medium,Confirmed] https://launchpad.net/bugs/1675882 15:58:19 Launchpad bug 1739460 in Evergreen "Web client: branch library shelving locations not visible to HQ workstation" [High,Confirmed] https://launchpad.net/bugs/1739460 15:58:20 Launchpad bug 1739286 in Evergreen "web client: Cannot set default search box in Z39.50" [Low,Confirmed] https://launchpad.net/bugs/1739286 15:58:27 abneiman++ 15:59:19 what's the status of 1732761 since it references the omnibus? 15:59:25 which was already merged 16:00:28 ditto bug 1675882 16:00:30 Launchpad bug 1675882 in Evergreen "webclient: adding individual copies defaults circ OU to workstation OU" [Medium,Confirmed] https://launchpad.net/bugs/1675882 16:00:44 are they branches built atop the omnibus, but not merged w/ the omnibus? 16:00:55 1732761 is in master 16:01:11 * miker will mark it dup and close 16:01:15 awesome 16:01:20 miker++ 16:01:29 Speaking of the omnibus, should that be backported to 3.0? 16:01:59 We've tested it here with 3.0.10 and it works. There's a conflict, but I know how to resolve it. 16:02:24 berick: checking the other ... Dyrcona: I'm for it 16:02:27 +1 to backporting omnibus 16:02:48 miker: bug 1739460 too please, unclear what to merge 16:02:49 Launchpad bug 1739460 in Evergreen "Web client: branch library shelving locations not visible to HQ workstation" [High,Confirmed] https://launchpad.net/bugs/1739460 16:02:50 berick: 1675882 is already marked dup of obnibus, actually 16:03:56 oh, so it is. 16:04:12 For bug 1739460, I thought people were no longer able to replicate the original problem. Is it still needed? 16:04:13 Launchpad bug 1739460 in Evergreen "Web client: branch library shelving locations not visible to HQ workstation" [High,Confirmed] https://launchpad.net/bugs/1739460 16:04:26 berick: well, 1739460 is working as intended -- filtering locations based on selected copies. I don't know if that's what people want, though... 16:05:23 the actual code is belt-and-suspenders for filtering by numeric values, really 16:05:48 so... maybe it doesn't hurt to merge? 16:06:27 that would be user/miker/lp-1739460-all-relevant-locations ? 16:06:39 berick: yessir 16:06:52 OK, i can merge that, I've already tested it once 16:06:55 * berick grabs 16:07:28 and.. that takes us past the hour 16:07:31 thanks, folks! 16:07:34 #endmeeting