15:01:10 <JBoyer> #startmeeting 2020-08-04 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-08-04
15:01:10 <pinesol> Meeting started Tue Aug  4 15:01:10 2020 US/Eastern.  The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:10 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:10 <pinesol> The meeting name has been set to '2020_08_04___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2020_08_04'
15:01:31 <JBoyer> #topic Introductions
15:01:37 <berick> drums, drums in the deep
15:01:45 <berick> #info berick Bill Erickson, KCLS
15:01:46 <JBoyer> #info JBoyer = Jason Boyer, EOLI
15:01:48 <Dyrcona> #info Dyrcona = Jason Stephenson, CWMARS
15:01:51 <gmcharlt> #info gmcharlt = Galen Charlton, EOLI, part of the 3.6 release team
15:01:57 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:02:04 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka)
15:02:15 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:02:28 <nfBurton> #info cburton = Chris Burton, Niagara Falls Public Library
15:02:53 <terran> #info terran = Terran McCanna, PINES
15:03:09 <JBoyer> Folks can feel free to introduce themselves as they continue to come in
15:03:13 <JBoyer> #topic Action Items from Last Meeting
15:04:07 <JBoyer> First up, now that I notice he may not be here, csharp was going to ask around PINES if lp 1821094 is ready or needs more testing, terran, do you know how that went?
15:04:08 <pinesol> Launchpad bug 1821094 in Evergreen 3.4 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094
15:04:32 <terran> I'm not sure
15:04:59 <miker> #info mike = Mike Rylander, EOLI
15:05:15 <terran> Elaine was fine with it
15:06:33 <alynn26> info alynn26 = Lynn Floyd Evergreen Indiana
15:06:45 <alynn26> #info alynn26 = Lynn Floyd Evergreen Indiana
15:07:01 <JBoyer> Ok, given the pullrequest tag and the comments we can assume it does the thing re: performance and it just needs a signoff and commiting.
15:07:15 <JBoyer> That's positive.
15:07:51 <JBoyer> Action item 2, berick, have you had an opportunity to consider EDI availability codes?
15:07:54 <csharp> #info csharp = Chris Sharp, GPLS
15:08:10 <berick> I have not, but I will
15:08:54 <JBoyer> Before I just add that back on berick, is anyone else working with EDI enough that they would like to take that on or assist?
15:09:18 <csharp> I can assist
15:09:28 <JBoyer> csharp++
15:09:35 <_sandbergja> #info _sandbergja is Jane Sandberg, Linn-Benton Community College
15:09:39 <_sandbergja> csharp++
15:09:40 <csharp> I'll need to refresh my knowledge of them, but yeah
15:09:41 <_sandbergja> berick++
15:09:58 <JBoyer> #action berick and csharp to consider approaches to lp 1627373
15:09:59 <pinesol> Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,New] https://launchpad.net/bugs/1627373
15:10:39 <csharp> I'll follow up with bug 1821094 too - that got dropped (like so many things)
15:10:40 <pinesol> Launchpad bug 1821094 in Evergreen 3.4 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094
15:11:02 <JBoyer> The last carried over action item, Dyrcona, did you have a chance to enter the LP bug about using jQuery in the OPAC? I didn't find it in a cursory search, but LP gonna LP.
15:11:18 <Dyrcona> Nope. I didn't get to it.
15:11:46 <csharp> "2020: I Didn't Get to It"
15:12:12 <JBoyer> Was the intent more than "we should just use it and throw everything else away?"
15:12:29 * csharp likes that better than "we're all in this together" and "in these unprecedented times"
15:12:38 <JBoyer> Because I imagine many of us can get behind that.
15:12:44 <Dyrcona> :)
15:12:56 <berick> csharp: :)
15:13:14 <nfBurton> The OPAC I'm targeting for 3.6 has jQuery always enabled
15:13:22 <Dyrcona> The intent was pretty much just replace Dojo with jQuery, and add jQueryUI for datepickers and things.
15:13:55 <Dyrcona> And, yeah, with nfBurton's work, it may be obsolete anyway.
15:14:09 <miker> ISTM, since we added a fake $() eons ago, we might as well just make that the real thing
15:14:15 <nfBurton34> Ugh IRC, but yeah there are a bunch of additions there
15:14:24 <JBoyer> That's what I was thinking. I wouldn't mind replacing all JS use with it, or at least requiring that it doesn't break when jQ is enabled.
15:14:52 <JBoyer> and nfBurton34 , Is the goal of the new OPAC that it's THE OPAC, or one of 2 options?
15:15:08 <JBoyer> miker +1 to that.
15:15:10 <nfBurton34> THE OPAC, but giving people time to OPT in
15:15:23 <nfBurton34> Or opt out?
15:15:36 <nfBurton34> IDK it was suggested it is an 'option' for a version
15:15:48 <nfBurton34> Kinda Beta-ing it out
15:16:09 <csharp> @band add THE OPAC
15:16:09 <pinesol> csharp: Band 'THE OPAC' added to list
15:16:12 <JBoyer> Ok, so at least optional for 3.6.
15:16:18 <nfBurton34> Yes
15:16:28 <csharp> nfBurton34++
15:16:34 <gmcharlt> yeah, agreed - optional for 3.6, maybe default for 3.7
15:16:40 <csharp> +1
15:16:51 <JBoyer> In that case I'd say it's still worth pursuing jQ in the meantime since it does cause problems in the existing OPAC.
15:16:51 <gmcharlt> I think question is when do we want to deprecate the old OPAC - I'm inclined to say 3.7
15:17:06 <nfBurton34> Yeah I had to change the load order of the jQuery
15:17:35 <JBoyer> gmcharlt, with the intent that it's then gone in ~3.8?
15:17:40 <gmcharlt> (which I realize is begging the question of whether to deprecate at all, but I think we should, in part so that we avoid a long-term committment that I don't believe we can colellectively make)
15:17:48 <gmcharlt> JBoyer: yeah, gone in 3.8
15:18:58 <Bmagic> +1 deprecation 3.7, gone 3.8
15:19:11 <csharp> gmcharlt++ # proper use of "begging the question"
15:19:34 <csharp> I'm good with the plan
15:19:39 <jeffdavis> Not necessarily opposed but that is an aggressive timeline for the main public-facing component of EG, esp considering many of us have probably done some degree of OPAC customization.
15:20:01 <JBoyer> Sounds like a plan then. We don't need to firm up the schedule today, but we should definitely look into making jQ work as expected.
15:20:02 <nfBurton34> It does make navigation FAR easier
15:20:25 <Bmagic> jeffdavis: I have the same thoughts, though, I think that the OPAC that nfBurton34 has worked out is mostly what the customizations are trying to get to....
15:20:54 <terran> Should deprecation wait for 4.x?  (In PINES we will consider moving to it sooner though)
15:21:00 <_sandbergja> I would be interested in a longer timeline
15:21:25 <_sandbergja> We only upgrade once a year, so it would go from optional to gone in one upgrade cycle
15:21:39 <_sandbergja> And I don't think we're the only ones who upgrade annually...
15:21:49 <csharp> deprecation doesn't necessary mean removal - like the XUL client stuck around in a "deprecated" state over a few releases
15:21:58 <csharp> we also upgrade annually
15:22:08 <jeffdavis> I don't think we need to decide now, main thing is to get the new OPAC in the next release, right?
15:22:09 <csharp> maybe just delay removal?
15:22:56 <JBoyer> The timing plans can probably be hashed out once the new OPAC is even an option, my primary point was "do we still pursue replacing dojo with jQuery?" and it sounds like yes.
15:23:27 <miker> JBoyer: +1 to s/dojo/jquery/ in the opac
15:23:27 <_sandbergja> JBoyer: yes to dojo -> jquery
15:23:36 <jeffdavis> +1 to that (Overdrive API stuff will need to be de-Dojofied but that was always expected)
15:23:41 <nfBurton34> jQuery > dojo
15:23:44 <JBoyer> So, does anyone feel strongly about taking that action item or will I do it after this meeting (lest I forget)
15:24:44 <Dyrcona> JBoyer: You can have it if you like. I couldn't get to it in 3 months, so....
15:25:10 <JBoyer> #action JBoyer to file LP bug about replacing Dojo with jQuery
15:26:07 <JBoyer> The three months in question does make it a bit more understandable though.
15:26:20 <JBoyer> Moving on!
15:26:22 <JBoyer> #topic OpenSRF Release Info
15:26:38 <JBoyer> Is there any OpenSRF release info to discuss?
15:26:54 <gmcharlt> short term, we have two patches that are enough to warrant cutting 3.2.1 IMO
15:27:25 <miker> ooo, I know what they are! :)
15:27:26 <gmcharlt> well, three, one's an easy merge
15:27:59 <gmcharlt> so I propose to take an action item to release 3.2.1 this month the same time as the Evergreen maint releases
15:28:08 <JBoyer> gmcharlt++
15:28:21 <gmcharlt> #action gmcharlt will cut OpenSRF 3.2.1
15:28:42 <JBoyer> #action gmcharlt to build an OpenSRF 3.2.1 release during the same timeframe as the Evergreen maintenance releases
15:28:54 <JBoyer> Oops, too wordy I suppose.
15:29:30 <Bmagic> words bad. " " good.
15:29:53 <gmcharlt> come back, JBoyer! a double #action is not the end of the world!  ;)
15:29:59 <JBoyer> Sigh. I may need a new IRC client. :/
15:30:03 <csharp> gmcharlt++
15:30:13 <JBoyer> On to Evergreen!
15:30:15 <JBoyer> #topic Evergreen Release Info
15:30:53 <JBoyer> Are we still on schedule for August 19th for the monthly point releases?
15:31:08 <gmcharlt> in ##eg-release I had proposed instead doing them on August 12 to avoid running into Feedback Fest
15:31:20 <csharp> I'm good with either
15:31:31 <gmcharlt> and I'm happy to continue with that plan, but want to confirm that other build team members are available
15:31:50 <Bmagic> I'm available for either date
15:31:52 <Dyrcona> What calendar is Feedback Fest on? I don't see it in Google.
15:32:42 <JBoyer> Dyrcona, currently it's been mentioned in a couple of emails and the dev meeting agenda. I need to see if I have / can get community calendar editing powers.
15:33:00 <terran> I can add it to the calendar - the schedule is here for now: https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap
15:33:13 <JBoyer> terran++
15:33:25 <Dyrcona> I could add it to the development calendar. I don't think I can edit the others.
15:33:38 <JBoyer> I'm also +1 to moving it away from Feedback Fest
15:33:39 <gmcharlt> I've added it to the community calendar - is it showing up for folks now?
15:34:06 <terran> Now it's on there twice :)
15:34:17 <gmcharlt> I'll remove the one I added :)
15:34:17 <Dyrcona> I wonder if doing the releases after feedback fest is better than before?
15:34:37 <terran> I'll add bug squashing week if it's not on there yet too
15:34:44 <gmcharlt> terran++
15:34:48 <JBoyer> I'd feel that way more about bugsquashing week, given their difference in focus.
15:35:09 <gmcharlt> Dyrcona: feedback fest is more focused on enhancements rather than bugfixes; i.e., I agree with JBoyer
15:36:28 <Dyrcona> OK. Fine with me. I was just wondering.
15:37:22 <_sandbergja> I'd prefer August 12th for point releases, so I can actually participate in feedback fest. :-)
15:37:47 <_sandbergja> And I am available then
15:37:51 <JBoyer> I don't think that's a voting matter, but are enough build team members available to shift it?
15:37:59 <csharp> sounds like it
15:38:07 <gmcharlt> agreed
15:38:09 <JBoyer> Huzaah.
15:38:34 <JBoyer> #info the next Evergreen Maintenance Release date is August 12th
15:39:15 <JBoyer> So, Any other Evergreen release news?
15:40:27 <JBoyer> Well, since I can't check my scrollback these may as well go in the minutes
15:40:42 <JBoyer> #info Feedback Fest is August 17 - August 21
15:41:02 <JBoyer> #info Bug Squashing Week is September 21 - September 25
15:41:02 <csharp> also remember http://irc.evergreen-ils.org/evergreen/2020-08-04
15:41:15 <gmcharlt> only other update is that mmorgan and I (and the other members of the RM team) will be sending out a summary on Monday
15:41:25 <JBoyer> csharp++
15:41:47 <JBoyer> gmcharlt++ mmorgan++
15:42:01 <JBoyer> #topic Hatch Release info
15:42:16 <berick> no recent Hatch changes
15:43:07 <JBoyer> It'll be nice when OpenJDK has all of the necessary parts to make it a single file install, but until then I don't suppose a lot needs to change.
15:43:48 <JBoyer> That said, Is 3.6 maybe a good time to pull the band-aid on Hatch Local Storage, or should that go on as is for a while longer?
15:44:15 <JBoyer> (In general, not trying to make more work for berick. ;) )
15:44:32 <berick> yeah we should remove that option from the config UI in the webstaff -- the bandaid has in essence been pulled already
15:44:39 <terran> +1
15:44:43 <csharp> +1000
15:44:46 <mmorgan> +1
15:44:52 <terran> We still have staff that we find out are using it
15:45:04 <mmorgan> Endless cause of confusion there.
15:45:05 <csharp> yeah, it's a pain to troubleshoot
15:45:10 <berick> i'll open a LP
15:45:14 <JBoyer> berick++
15:45:18 <csharp> berick++
15:45:49 <JBoyer> #action berick to open LP bug re: the removal of Hatch Local Storage in web staff client
15:46:10 <JBoyer> Onward!
15:46:11 <JBoyer> #topic New Business
15:46:30 <csharp> I have something tangentially dev-related
15:47:03 <JBoyer> csharp, go for it
15:47:43 <csharp> GPLS is decommissioning our email list server, and we have five Evergreen-related lists that need to be migrated to the Evergreen community list server (open-ils-general, open-ils-dev, open-ils-docs & the commits lists)
15:48:05 <csharp> so look for communications from me about when that will happen over the next couple of weeks
15:48:15 <gmcharlt> csharp++
15:48:17 <_sandbergja> csharp++
15:48:23 <JBoyer> csharp++
15:48:40 <rhamby> csharp++
15:49:12 <csharp> we've been talking about that for nearly 10 years, so good to finally see it happen :-)
15:50:05 <JBoyer> The new business entry on the agenda was mine; I wanted to remind people about LP 1703411 . Some good code that we needed came from it, but not SASL authentication, which we still need.
15:50:06 <pinesol> Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411
15:51:32 <JBoyer> I have the most bare-bones bit of the perl half of this working, so perl services can login via the PLAIN mechanism, but I may need some help with the C portions, and we should really aim for SCRAM support so we can remove "Turn off all of the security features" from our install instructions.
15:52:39 <JBoyer> I don't have a working branch out there yet (just banging on it on a local VM) but does this sound like the sort of thing anyone is interested in poking at?
15:52:50 <gmcharlt> I would be
15:53:00 <JBoyer> gmcharlt++
15:53:34 <JBoyer> Obviously I'll have to get what I have to date in a collab wip branch, which I'll try to do asap.
15:53:34 <berick> i'm definitely following along.
15:53:46 <JBoyer> berick++
15:53:53 <miker> me too
15:54:14 <Bmagic> seems like it's time
15:54:36 <JBoyer> I'll try to remember to mention it in here once it's up, and FYI, at present it's really not commit-worthy. ;)
15:55:02 <JBoyer> So, we move on to
15:55:07 <JBoyer> #topic Feedback for new features
15:55:18 <JBoyer> berick, you've got the first one.
15:55:23 <berick> hi..
15:55:38 <berick> heads up we have a new tag angularcatblocker
15:55:54 <berick> any angular staff cat issues that prevent its use in production should get this tag
15:56:01 <berick> or new regressions, etc.
15:56:18 <berick> i'm tracking them closely
15:56:59 <berick> also just curious if anyone has any strong feeling either way for making it the defult in 3.6 as it's one of the earlier-is-better things
15:57:02 <berick> if we want to merge it
15:57:25 <Bmagic> I like the launchpad tag. +1 3.6
15:57:44 <gmcharlt> I'm inclined to merge it sooner rather than later, in particular, before feedback fest
15:58:08 <berick> i saw the comment re: removing the org setting, gmcharlt
15:58:11 <berick> i'll look at that
15:58:15 <gmcharlt> and specifically before feedback fest so that /all/ test systems set up for FF are implicitly testing it as well
15:59:07 <JBoyer> That does make sense, should help with the slightly shorter release cycle also.
15:59:55 <_sandbergja> +1 merging it soon for 3.6
16:00:29 <JBoyer> berick, do you want an action item for that or would you like someone else to give it another look first?
16:00:41 <_sandbergja> As a side note, it will be really nice to have those broadcast messages in the Angular client
16:01:20 <berick> JBoyer: i have one thing to fix (removing org setting), but other than that I thing someone else would need to volunteer for testing the branch
16:01:33 <_sandbergja> I can volunteer
16:01:49 <berick> thanks _sandbergja++
16:01:52 <JBoyer> _sandbergja++
16:02:32 <JBoyer> #action _sandbergja to do some testing on the Angular staff catalog branch with the aim of merging pre-feedback fest
16:03:13 <JBoyer> And I suppose berick's second point on the agenda is fairly closely related, given the timing?
16:03:30 <berick> right, Ang 9 (or 10) bug 1864371
16:03:31 <pinesol> Launchpad bug 1864371 in Evergreen "Upgrade to Angular 9" [Undecided,Confirmed] https://launchpad.net/bugs/1864371
16:03:33 <gmcharlt> yeah
16:03:40 <JBoyer> #topic Angular 9 /10 update
16:03:57 <gmcharlt> I've looked over the branch and am in favor of going all the way to Angular 10, and doing so ASAP
16:04:02 <JBoyer> I just realized these minutes are going to be a bit sparse on what it is we;re actually talking about.
16:04:35 <Dyrcona> The minutes usually are sparse, but there's a link for the full log.
16:04:43 <gmcharlt> in part, selfishly, because I'd prefer to rebase the angular acq search branch at a predictable time to convert it from using ngbTabset to ngbNav
16:05:05 <berick> gmcharlt: *nod*
16:05:15 <berick> well, I can rebase the working branch and give it another once over this week
16:05:21 <gmcharlt> and I'd happily take on putting the 1864371 branch through its paces
16:05:39 <berick> even better! :)
16:05:42 <_sandbergja> berick: gmcharlt: from glancing over that branch, it looks like it's not as impactful as Angular 8 adding static to all those ViewChilds
16:05:50 <berick> _sandbergja: definitely not
16:05:55 <_sandbergja> Yes!
16:06:02 <gmcharlt> I also glanced over the ng-bootstrap and bootstrap release notes, and bumping up up to 7.0.0 and 4.5.1 respectively doesn't look like it will be too painful
16:06:06 <berick> and the tab/nav changes are encouraged but not strictly required yet
16:06:23 <berick> hold my last thought, i haven't tested latest bootstrap
16:06:35 <berick> pretty sure it's still just deprecated, though
16:06:37 <_sandbergja> I can take a look after you, gmcharlt
16:06:47 <gmcharlt> _sandbergja++
16:07:02 <berick> gmcharlt++ _sandbergja++
16:07:02 <JBoyer> gmcharlt++ _sandbergja++ berick++
16:07:06 <_sandbergja> it would be nice to be able to rebase the course materials work on Angular 10 too
16:07:11 <_sandbergja> :-)
16:07:35 <JBoyer> Would the aim for that also be pre-FF week?
16:07:58 <_sandbergja> That would be ideal, I think
16:07:58 <berick> +1 to pre-FF
16:08:16 <_sandbergja> So, when reviewing old PRs, we can easily check Angular 10 compatibility
16:08:27 <gmcharlt> yeah
16:09:02 <JBoyer> #action gmcharlt , _sandbergja , and berick will work to test and merge lp 1864371 to use Angular 10 in the staff client before Feedback Fest week.
16:09:03 <pinesol> Launchpad bug 1864371 in Evergreen "Upgrade to Angular 9" [Undecided,Confirmed] https://launchpad.net/bugs/1864371
16:09:11 <JBoyer> That sounds great.
16:09:54 <JBoyer> Given it's standing as a, uh, standing item, we can skip over discussionneeded for now.
16:10:07 <JBoyer> #topic Curbside pickup discussion
16:10:38 <gmcharlt> so, this one is mostly just a plea for reviewer and committer attention, especially now that we have some libraries using it in production
16:11:01 <gmcharlt> not much to say otherwise unless there are questions
16:11:47 <JBoyer> lp 1879983 for those reading the logs later
16:11:48 <pinesol> Launchpad bug 1879983 in Evergreen "Curbside Pickup" [Wishlist,Confirmed] https://launchpad.net/bugs/1879983
16:12:20 <mmorgan> Is the test server with that code still available?
16:13:00 <gmcharlt> mmorgan: as it happens, yeah, curbside.evergreencatalog.com is still up
16:13:18 <jeffdavis> we're testing curbside here, will share any feedback via LP
16:13:25 <gmcharlt> only thing it would need is refreshing it to the latest-and-greatest
16:13:27 <gmcharlt> jeffdavis++
16:14:18 <JBoyer> Any other questions or curbside discussion?
16:14:56 * mmorgan will try and devote some time to looking at curbside.
16:15:01 <gmcharlt> mmorgan++
16:15:11 <JBoyer> mmorgan++
16:15:16 <JBoyer> #topic Angular Acquisitions Search (LP 1850547 )
16:15:17 <pinesol> Launchpad bug 1850547 in Evergreen "Angular Acquisitions Sprint 3: Acquisitions Search" [Wishlist,Confirmed] https://launchpad.net/bugs/1850547
16:15:44 <JBoyer> I assume this is a similar request for eyes.
16:16:01 <gmcharlt> so, same deal as the curbside branch, but with a specific request that some of the angular core component changes be looked at (and could be merged independently)
16:16:10 <berick> i plan to review, but I'll wait until after Ang 10 rebase
16:16:37 <gmcharlt> there are a bunch of them, including new eg-file-reader and eg-interval-input components and changes to org-select, date-select, eg-grid, and eg-combobox
16:16:57 <gmcharlt> and even just eyeballing would be useful
16:17:11 <gmcharlt> I will plan on rebasing that branch ASAP once the angular 10 branch is in
16:17:44 * berick nods
16:18:41 <gmcharlt> but otherwise, I've nothing else specific to sa
16:18:42 <gmcharlt> y
16:19:10 <JBoyer> I'll also try to poke around at those two.
16:19:34 <JBoyer> #topic Patron API (LP 1887196)
16:19:35 <pinesol> Launchpad bug 1887196 in Evergreen "Support PatronAPI-compatible auth via RemoteAuth" [Wishlist,New] https://launchpad.net/bugs/1887196
16:19:43 <JBoyer> jeffdavis, take it away
16:20:14 <jeffdavis> I'm hoping to add support for PatronAPI, which is a patron authentication method used by III that a lot of vendors support.
16:20:57 <jeffdavis> But I know some countries have strange/confusing laws around copyrightability of APIs so I'm not sure if there are issues adding a PatronAPI-compatible API to EG?
16:21:32 <gmcharlt> IIRC, there's at least one shim running around that adds PatronAPI support to Evergreen, that TMK nobody's challenged
16:22:04 <JBoyer> I don't recall if the Google / Oracle fight is over, but given that we've so little money to take I'd assume that's not an issue.
16:22:24 <JBoyer> Unless Oracle buys III, in which case all bets are off. ;)
16:24:12 <jeffdavis> It seems like a bit of a grey area and it would be adding the API to EG itself (rather than an external shim), so I just wanted to flag it before anything gets committed. If we don't think there's an issue then that's good with me.
16:24:25 <JBoyer> Of note to potential testers, it requires LP 1850992 also, which would also be a great addition.
16:24:26 <pinesol> Launchpad bug 1850992 in Evergreen "Use RemoteAuth for EZProxy authentication" [Wishlist,New] https://launchpad.net/bugs/1850992 - Assigned to Jane Sandberg (sandbej)
16:26:10 <JBoyer> Any more discussion for jeffdavis about PatronAPI? I've let things run a bit longer than expected today.
16:26:45 <gmcharlt> there is also this: http://bricestacey.com/2009/06/03/Configure-EZProxy-to-Authenticate-Against-Voyager-ILS-for-WorldCat-Local-Navigator.html
16:27:16 <gmcharlt> so, not adding PatronAPI support to Voyager, but code that provides its as an endpoint
16:29:02 <gmcharlt> but I've nothing more to say
16:29:17 <jeffdavis> that's a handy link, thanks
16:29:33 <JBoyer> That's the first I've seen of the output of PatronAPI, I'm a little bummed that's becoming a defacto standard.
16:30:44 <JBoyer> Everyone is encouraged to check out LP bugs that have have pullrequests but need signoffs, and I don't believe we have any qa failing bugs at present.
16:30:53 <JBoyer> Have a great day eveyone.
16:30:55 <JBoyer> #endmeeting