15:00:30 <gmcharlt> #startmeeting Evergreen Development Meeting, 7 May 2019
15:00:30 <pinesol> Meeting started Tue May  7 15:00:30 2019 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:30 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:30 <pinesol> The meeting name has been set to 'evergreen_development_meeting__7_may_2019'
15:00:36 <JBoyer> mmorgan, if kiosk printing will do what you need and there's no need for a browser to print to any other printer or size, that's fine. Hatch works well, but for something like a selfcheck (that users no other printer) it may be overkill.
15:00:46 <gmcharlt> #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2019-05-07
15:00:58 <gmcharlt> #topic Introductions
15:01:06 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox, 3.4 RM
15:01:09 <JBoyer> #info JBoyer = Jason Boyer, IN State Lib, Evergreen IN
15:01:18 <phasefx> #info phasefx = Jason Etheridge, Equinox
15:01:19 <Dyrcona> #info Dyrcona = Jason Stephenson, CW MARS
15:01:22 <rhamby_> #info rhamby = Rogan Hamby, Equinox
15:01:27 <miker> #info miker = Mike Rylander, EOLI
15:01:42 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka)
15:01:47 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
15:02:01 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:02:18 <stephengwills> #info stephen g wills - for IGALSTEAM (Maine BALSAM Consortium)
15:05:23 <gmcharlt> #topic Announcements
15:05:50 <gmcharlt> #info The VM for evergreen-ils.org will be moved on 9 May 2019 and will be down for a couple hours in the early a.m. EDT
15:06:13 <gmcharlt> #info Other VMs, including git.evergreen-ils.org, will be moved as well, with the date to be determined
15:07:13 <gmcharlt> upshot: don't plan on 7 a.m. on Thursday for revamping all of the developer documentation on the wiki ;)
15:07:31 <gmcharlt> #topic OpenSRF 3.1.x update
15:08:12 <gmcharlt> largely due to bug 1823338 and its friends, I will plan on an OpenSRF update this week
15:08:14 <pinesol> Launchpad bug 1823338 in OpenSRF "SIP Checkin Speed vs Debug Logging" [Undecided,New] https://launchpad.net/bugs/1823338
15:10:19 <gmcharlt> as far as OpenSRF 3.2.x is concerned
15:10:40 <gmcharlt> two major changes proposed are removing the Java and Python bindings
15:11:12 <gmcharlt> there's been some discussion on the list, but I'm curious if anybody has entertained any thoughts about stepping forward to maintain either binding
15:12:07 <JBoyer> I was under the impression that the Java libs wouldn't be missed because they haven't worked in some time, haven't heard anything about Python, though I would think locations using Syrup would be interested...
15:12:09 * Dyrcona thinks Python is worth saving, but Java not so much. Not that I am stepping forward to maintain Python.
15:12:36 <Dyrcona> Yes, removing Python will make it impsosible to use Syrup, but Syrup is also dead.
15:13:01 <gmcharlt> I agree with that assessment - I also don't know of any active uses of the Java client, but Syrup is still being used
15:13:06 <Dyrcona> Sites using s
15:13:07 <JBoyer> Well, abandoned, anyway. Not 100% the same thing
15:13:28 <Dyrcona> Sites using Syrup should find an alternative, and yes, we use Syrup.
15:13:40 <dbwells> We are using Syrup, and for the foreseeable future, we would be willing to maintain Python insofar as it affects Syrup.
15:14:15 <Dyrcona> dbwells: You will need to take over and update Syrup as well. It will NOT install as is on currently supported distributions of Linux.
15:14:42 <miker> dbwells: that would mainly mean teaching it how to, at least, receive chunked responses as far as OpenSRF itself is concerned
15:14:48 <Dyrcona> By "currently supported" I mean both supported by us and the distribution vendors/communities.
15:15:16 <Dyrcona> For Syrup, that means updating to recent Django and moving to Python 3.
15:15:47 * dbwells waves his hands in a reassuring fashion
15:15:50 <gmcharlt> if somebody were to adopt the OpenSRF Python binding, is there any reason to still support Python 2?
15:16:07 <miker> (I have a WIP branch that allows perl to send over-large requests in a chunk-ish way, fwiw. no C or python support yet for any of that)
15:16:41 <Dyrcona> gmcharlt: Python 2 is EOL on January 1, 2020.
15:17:01 <dbwells> I will walk back my statement a little and say I am willing to try :)
15:17:07 <Dyrcona> :)
15:17:22 <gmcharlt> dbwells: are you sufficient interested to accept an action items along the lines of you will evaluate whether you can take on Python maintenance?
15:17:35 <dbwells> gmcharlt: That sounds perfect.
15:17:51 <dbwells> If we can't get Syrup to work, I've got a big job either way.
15:18:11 <gmcharlt> #action dbwells will evaluate the potential for assuming responsibility for the OpenSRF Python binding (and related updates of Syrup)
15:18:18 <gmcharlt> dbwells++
15:18:20 <JBoyer> dbwells++
15:18:26 <Dyrcona> dbwells++
15:18:33 <jeff> dbwells++
15:18:36 <gmcharlt> OK, anybody keen to have a change of heart and adopt the Java binding?
15:19:01 <remingtron> dbwells++
15:19:05 <gmcharlt> (note that I'm not specifically advocating for that unless there's an OpenSRF Java user out there that we're not aware of)
15:20:37 * gmcharlt interprets the dead silence as a no :)
15:20:49 <gmcharlt> any other opensrf topics before we move on?
15:21:54 <gmcharlt> ok, moving on
15:21:59 <gmcharlt> #topic Evergreen update
15:22:25 <gmcharlt> #info Please add items to the 3.4 roadmap here: https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.4
15:22:57 <gmcharlt> but while we're talking - what projects are folks working on that they expect to have completed this summer?
15:23:51 <JBoyer> I'd like to get my payment revamp pretty far along, but I'm still filling out a GDoc to try to get some feedback before heading off into blind alleys.
15:24:17 <Dyrcona> Stripe Elements API for credit card payments in the OPAC: https://bugs.launchpad.net/evergreen/+bug/1774892
15:24:18 <pinesol> Launchpad bug 1774892 in Evergreen "Wishlist: Upgrade to Stripe v3 (elements)" [High,Confirmed] - Assigned to Jason Stephenson (jstephenson)
15:24:23 <JBoyer> (which is to say there has yet to be a single line diff created for such cause... :-/ )
15:25:54 <jeffdavis> bug 1817645 should be done for 3.4
15:25:55 <pinesol> Launchpad bug 1817645 in Evergreen "Configurable patron auth and retrieval" [Wishlist,New] https://launchpad.net/bugs/1817645 - Assigned to Jeff Davis (jdavis-sitka)
15:26:04 <jeff> potentially some evergreen-side bits for "this is an externally managed hold/circ/etc" for things like NCIP and similar protocols/APIs.
15:26:23 <jeff> and i'd like to lend eyes/hands to jeffdavis' patron auth work
15:26:47 <jeffdavis> cool :)
15:27:32 <jeff> we're training system-wide on the web client now and so i have several "we hit these also" bugs in my sights, but those aren't features/roadmap items per se.
15:28:25 <gmcharlt> I've added the Strip v3 bug to the roadmpa
15:30:36 <gmcharlt> Equinox has some projects in the works as well, though updates to the roadmap won't be before tomorrow
15:30:52 <gmcharlt> OK, any other 3.4 topics? or discussion about maintenance releases?
15:32:02 <dbwells> I will send something to the list as well, but as always, we are interested in more Buildmaster help.
15:32:38 <dbwells> After about 2.5 years, I am looking to hopefully reduce my role in that area.
15:32:51 <gmcharlt> dbwells++
15:33:04 <gmcharlt> #action dbwells will send out a call for buildmasters
15:33:25 <Dyrcona> I've got a list of bugs that are "ready to go" but need more eyes. I can share that later.
15:33:46 <dbwells> Bmagic has helped me handle a large number of builds in that timeframe, and has agreed to help shepherd thing forward, but the more, the merrier.  Thanks!
15:34:01 <gmcharlt> Dyrcona: thanks!
15:34:15 <Dyrcona> Seems that releases have fallen on bad days for me, i.e. when I'm in multiple meetings.
15:34:41 <gmcharlt> ok, moving on
15:34:45 <gmcharlt> #topic Hatch update
15:34:54 <gmcharlt> berick: csharp: JBoyer: any news?
15:35:46 <terran> csharp is teaching a class right now so not present
15:36:23 <JBoyer> I haven't had time to look much at the new OpenJDK stuff, but it seems promising aside from the size.
15:37:02 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:37:40 * JBoyer needs to pull out his Win10 laptop and experiment...
15:37:54 <gmcharlt> JBoyer++
15:37:57 <gmcharlt> OK, moving on
15:38:02 <gmcharlt> #topic New business
15:38:36 <gmcharlt> #info Question: time to upgrade to ng-bootstrap 4.1.x?
15:39:02 <gmcharlt> this applies to the Angular side, of course
15:39:30 <gmcharlt> and was inspired by my thinking: gee, it would be handled to have more keyboard navigation support from ngbPopover
15:39:40 <gmcharlt> which, in fact, was added in 4.1.0
15:40:26 <miker> +1 any time before "production" IMO. one less version to chase later
15:41:01 <sandbergja> gmcharlt: do you have a link to release notes, by any chance?
15:41:19 <gmcharlt> sandbergja: yes - https://github.com/ng-bootstrap/ng-bootstrap/blob/master/CHANGELOG.md
15:41:28 <sandbergja> Thanks!
15:41:50 <gmcharlt> the vast majority of changes since 3.3.1 seem to be bugfixes
15:42:07 <JBoyer> bug fixes are best fixes.
15:42:10 <gmcharlt> the main change that gives me pause is this one: https://github.com/ng-bootstrap/ng-bootstrap/commit/a25d5d2
15:43:09 <gmcharlt> but I think that's mostly going to be a matter of checking styling of existing components
15:43:22 <gmcharlt> ok, I'll play with it
15:43:57 <gmcharlt> #action gmcharlt will work on upgrading ng-bootstrap past 3.3.0 for 3.4; will also evalulate whether that might be a safe backport to 3.3.x
15:44:00 <miker> that looks mostly structural to me .... but I'm no expert
15:44:27 <gmcharlt> #topic Feedback requests
15:44:34 <gmcharlt> #info Bug 1815229
15:44:35 <pinesol> Launchpad bug 1815229 in Evergreen "auth_proxy should have a "bail on fail" option" [Wishlist,New] https://launchpad.net/bugs/1815229
15:44:35 <sandbergja> gmcharlt++
15:44:43 <gmcharlt> jeffdavis: I think this one and the next is yours?
15:45:48 <jeffdavis> Yes. A couple of AuthProxy/LDAP related new features, fairly minor I think.
15:46:22 <jeffdavis> The code has been sitting in Launchpad for several months and we now have it in prod. Just hoping some folks could take a look.
15:46:37 <gmcharlt> #info bug 1786552
15:46:38 <pinesol> Launchpad bug 1786552 in Evergreen "LDAP: Bind user option" [Wishlist,New] https://launchpad.net/bugs/1786552
15:46:47 <gmcharlt> jeffdavis: I can commit to looking at it
15:46:57 <jeffdavis> thanks
15:47:06 <gmcharlt> in part, because I recently discovered another LDAP auth bug that I need to work on
15:47:49 <dbwells> I've looked at both bugs a bit.  I think the second makes good sense, but I'm less sure about the bail_on_fail option.
15:48:06 <gmcharlt> specifically, OpenILS::WWW::Proxy::Authen needs to be taughtly how to use open-ils.auth_proxy
15:48:15 <dbwells> jeffdavis: Did you consider other models for that?
15:48:52 <jeffdavis> What sort of other models?
15:49:37 <jeffdavis> I am definitely open to achieving the same result by other means.
15:50:01 <dbwells> Well, I am just a little leery of adding a single purpose option and then thinking later we need more nuance, and then having overlapping options.
15:50:20 <dbwells> I haven't thought it through completely yet, just an inkling :)
15:51:09 <dbwells> For instance, maybe an <exclude_org_units> option would work here and also cover other cases, without being too obtuse.
15:51:47 <dbwells> That is, allow application in the inverse.
15:51:49 <gmcharlt> dbwells: do you have a specific use case in mind that would affect how your insitution would use LDAP?
15:52:43 <dbwells> No
15:52:47 <jeffdavis> exclude_org_units would certainly be useful for us. I think I was trying to keep things simple, and "stop authentication if this method fails" seemed straightforward enough.
15:52:51 <dbwells> At least not yet.
15:53:22 <jeffdavis> The way AuthProxy handles org units is a bit tricky though, there is an open bug related to that...
15:53:42 <dbwells> Yeah, I don't want to overcomplicate just for completeness sake, just thinking out loud at this point.
15:54:06 <jeffdavis> ah, I'm thinking of bug 1715396 which I added lower down on the dev agenda :)
15:54:07 <pinesol> Launchpad bug 1715396 in Evergreen 3.1 "auth_proxy, native login fails when LDAP unavailable" [High,Confirmed] https://launchpad.net/bugs/1715396
15:54:45 <dbwells> Yeah, I knew this all felt familiar.
15:55:18 <jeffdavis> I'd certainly be ok holding off on the bail-on-fail thing for now if you/we want to give it some more thought.
15:55:39 <jeffdavis> I do get the concern.
15:56:08 <dbwells> Well, if gmcharlt doesn't mind, I can assign myself to just that piece and look again at 1715396 as well, since I had already commented there a while back.
15:56:22 <gmcharlt> that's fine
15:56:48 <jeffdavis> awesome, thanks both
15:56:52 <gmcharlt> (thought as a side note, in general I do plan on reviewing bug assignments that have stuck around longer than a few weeks this release cycle)
15:57:18 <gmcharlt> ok, moving on to the next few specific bugs in the agenda
15:57:21 <gmcharlt> bug 1715396
15:57:22 <pinesol> Launchpad bug 1715396 in Evergreen 3.1 "auth_proxy, native login fails when LDAP unavailable" [High,Confirmed] https://launchpad.net/bugs/1715396
15:57:25 <gmcharlt> bug 1794884
15:57:26 <pinesol> Launchpad bug 1794884 in Evergreen 3.2 "SRU/Z39.50 results can include non-OPAC-visible holdings" [Medium,New] https://launchpad.net/bugs/1794884
15:57:28 <gmcharlt> bug 1790231
15:57:28 <pinesol> Launchpad bug 1790231 in Evergreen "Subject heading link includes non-exact matches" [Medium,Confirmed] https://launchpad.net/bugs/1790231 - Assigned to Jane Sandberg (sandbej)
15:57:38 <sandbergja> I'm happy to review 1790231
15:57:45 <gmcharlt> sandbergja++
15:57:55 <sandbergja> And just assigned myself too!
15:58:06 <JBoyer> sandbergja++
15:58:21 <dbwells> I think I just agreed to 1715396 in my two bug bundle.
15:58:51 <gmcharlt> regarding 1794884, a question for miker: offhand, do you know if unapi.bre accepts a parameter to exclude OPAC-invisible items?
15:58:55 <sandbergja> dbwells++
16:00:45 <miker> gmcharlt: it does not, but it returns opac visibility info
16:01:04 <gmcharlt> right, which jeffdavis's patch makes use of
16:01:32 <jeffdavis> https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=efbbef05
16:01:36 <jeffdavis> is the patch
16:01:41 <gmcharlt> asking mostly because it strikes me that a mode to exclude OPAC-hidden copies in the first place might be a bit quicker
16:01:48 <gmcharlt> er, faster to run
16:02:15 <gmcharlt> not that that precludes jeffdavis' patch as a first pass
16:02:30 <miker> yeah, I think I'd start there
16:03:12 <gmcharlt> ok, we're past the end of the hour
16:03:15 <miker> of course, that cuts short the list, potentially, if you supply a limit
16:03:21 <gmcharlt> any last minute topics or brief announcements?
16:04:03 <jeff> throwing another bug out for eyeballs, bug 1794884 seems to have a proposed branch that didn't test cleanly, and an "ugly hack" for a patch.
16:04:04 <pinesol> Launchpad bug 1794884 in Evergreen 3.2 "SRU/Z39.50 results can include non-OPAC-visible holdings" [Medium,New] https://launchpad.net/bugs/1794884
16:04:07 <jeff> er.
16:04:32 <jeff> bug 1808055
16:04:32 <pinesol> Launchpad bug 1808055 in Evergreen "Search queries containing a filter in a subquery/group may drop the filter" [Undecided,Confirmed] https://launchpad.net/bugs/1808055 - Assigned to Mike Rylander (mrylander)
16:04:49 <miker> I'll commit to getting back to that soon
16:04:58 <miker> since I'm already assigned...
16:05:10 <jeff> I'm hoping to look at it again in the near future, but it's a broken feature in the meantime, and I suspect others are more qualified / well-versed in the relevant code.
16:05:13 <jeff> miker++
16:05:15 <jeff> thanks!
16:05:57 <gmcharlt> ok, thanks folks!
16:05:58 <gmcharlt> #endmeeting