15:02:31 <csharp> #startmeeting 2020-02-04 Developer Meeting
15:02:31 <pinesol> Meeting started Tue Feb  4 15:02:31 2020 US/Eastern.  The chair is csharp. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:31 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:31 <pinesol> The meeting name has been set to '2020_02_04_developer_meeting'
15:03:12 <csharp> #info Agenda: https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-02-04
15:03:31 <csharp> #topic Roll Call
15:03:42 <csharp> #info csharp = Chris Sharp, GPLS
15:03:58 <berick> #info berick Bill Erickson, KCLS
15:04:05 <jeff_> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:04:09 <jeffdavis> #info jeffdavis = Jeff Davis, Sitka (BC Libraries Coop)
15:04:41 <sandbergja> #info sandbergja = Jane Sandberg, Linn-Benton Community College
15:04:52 <terranm> #info terranm = Terran McCanna, PINES
15:05:16 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin University)
15:05:22 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin University)
15:05:42 <csharp> #topic Action Items from Last Meeting
15:05:51 <csharp> #info gmcharlt will apply various code changes and nudges regarding the remaining webstaffblocker bugs
15:06:17 <csharp> anyone have an update on that?
15:06:44 * csharp notes the lack of EOLI folk
15:07:58 <abneiman> csharp: EOLI people are having an important internal meeting and will not be available to today's meeting; apologies, all
15:08:08 <csharp> abneiman: thanks for letting us know!
15:08:23 <csharp> #info said bugs: https://bit.ly/2vHWljR
15:08:26 <csharp> just two left
15:09:06 <csharp> (one is a security bug, so may not be visible to all)
15:09:15 <csharp> ok, moving on...
15:09:30 <csharp> # topic OpenSRF release info
15:09:34 <csharp> #topic OpenSRF release info
15:09:50 <csharp> anyone have updates on OpenSRF releases?
15:10:23 <csharp> looks like we haven't had any new commits since 3.2.0 was release
15:10:23 <csharp> d
15:10:53 <csharp> okey doke
15:11:03 <csharp> #topic Evergreen release info
15:11:42 <csharp> we saw point releases for 3.3 and 3.4 two weeks ago
15:12:16 <sandbergja> I have a release-related question
15:12:17 <csharp> eg builder team deserves our thanks, particularly Dyrcona and Bmagic, who performed the builds
15:12:22 <sandbergja> I am wondering how we can incorporate Angular i18n and poeditor.com into the release process.  Is this something simple that the build team could do?  Or a project for during the conference?  Or something longer term?
15:12:33 <terranm> Dyrcona++ and Bmagic++
15:12:39 <sandbergja> Dyrcona++
15:12:41 <sandbergja> Bmagic++
15:12:42 <berick> sandbergja: i was just thinking about that yesterday...  needs some revisiting for usre
15:12:50 <berick> release_team++ # big time
15:13:21 <sandbergja> As we get more and more Angular interfaces, fewer and fewer of the interfaces are actually available in localized versions
15:13:22 <sandbergja> :-(
15:14:19 <berick> right.  and one month out from 3.5 beta, we need to get the strings exposed for translation
15:14:38 <csharp> #info we need to address i18n and l10n issues with Angular as fewer and fewer interfaces are available in localized versions
15:15:41 <berick> i'll follow up on that.  i'm rusty on the poeditor stuff
15:15:48 <sandbergja> berick++
15:15:52 <csharp> #info 3.3.6 and 3.4.2 were released 1/29/2020 - first releases of the year
15:16:11 <berick> exporting the strings is simple enough.  just need to finalize the work flow for translators
15:16:12 <csharp> #action berick will follow up on i18n/l10n issues and report back
15:16:15 <sandbergja> If I can help with that at all, berick, let me know!
15:16:21 <berick> will do, thanks sandbergja
15:16:29 <csharp> #action sandbergja will assist berick as needed
15:16:53 <csharp> ok, so 3.5...
15:17:29 <terranm> I'm also happy to help with that if I have some direction
15:17:44 * dbwells tries to remember his poeditor.com password...
15:17:56 <alynn26> #info alynn26 = Lynn Floyd, Indiana
15:17:59 <csharp> I believe we have 60 or so bugs targeted for 3.5-alpha
15:18:12 <csharp> 41 have pullrequests and 8 have signoffs
15:18:48 <csharp> #info about 60 bugs targeted for 3.5-alpha - 41 with pullrequest tags and 8 with signedoff tags
15:19:08 <berick> on that note, calling all code reviewers and committers for feedback fest in 2 weeks.
15:19:40 <csharp> what are the specific dates for that for the minutes/logs?
15:19:45 <csharp> terranm?
15:19:50 <berick> 2/17 -> 2/21
15:19:55 <csharp> ok cool
15:20:00 <terranm> What Bill said
15:20:05 * berick notes 2/17 may be a holiday for some
15:20:26 <terranm> If we can get a bunch of those pullrequests on some sandboxes, the New Developers Group should be able to test a good chunk of them
15:20:30 <csharp> # feedback fest scheduled for the week of 2/17 - 2/22 - code reviewers and committers are expected to participate
15:20:38 <csharp> #info feedback fest scheduled for the week of 2/17 - 2/22 - code reviewers and committers are expected to participate
15:20:47 * csharp will get the hang of it
15:21:12 <sandbergja> terranm: would it help if we reserved some bugs specifically for the new devs group?
15:21:26 <sandbergja> e.g. some that are simpler, or some that match particular interests of your members?
15:22:06 <terranm> Anything that is testable without having access to the back end / logs is good
15:22:36 <terranm> Actually getting them installed on a sandbox is the main hurdle
15:23:02 <csharp> we can make at least one master server available if that's helpful
15:23:10 <terranm> csharp++
15:23:42 <alynn26> csharp++
15:23:56 <csharp> #action csharp will work with terranm to get at least one sandbox server running master + pullrequest patches
15:24:16 <csharp> any particular 3.5-targeted features that need special attention?
15:25:18 <jeffdavis> filters... let me look at bug #s
15:25:19 <csharp> we have the OpenAthens integration feature running on PINES production and have applied a couple of patches since to address flaws that only showed up post-deployment
15:25:59 <csharp> https://bugs.launchpad.net/evergreen/+bug/1842297 (for the logs)
15:26:00 <pinesol> Launchpad bug 1842297 in Evergreen "OpenAthens integration" [Wishlist,Confirmed]
15:26:37 <jeffdavis> that's great!
15:26:47 <csharp> while we can verify it's running peacefully on PINES, we don't yet know if the core feature of providing auth to other services works
15:27:29 <csharp> libraries are in the process of migration (coordinated by GALILEO, our sibling agency)
15:28:11 <csharp> any other features anyone wants to highlight/mention?
15:28:47 * berick checks the roadmap
15:28:49 <terranm> It'd be nice to get Hopeless Holds finished: https://bugs.launchpad.net/evergreen/+bug/1811710
15:28:50 <pinesol> Launchpad bug 1811710 in Evergreen "wishlist: Improvements to Hopeless Holds" [Wishlist,Confirmed]
15:29:24 <csharp> #info 3.5 roadmap: https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.5
15:29:51 <terranm> All 5 of the circ ones are really good improvements
15:29:52 <jeffdavis> bug 1846042 could also use some love, although I'd class it as a regression/bugfix rather than a feature request
15:29:53 <pinesol> Launchpad bug 1846042 in Evergreen 3.3 "Angular admin pages need filters" [High,Confirmed] https://launchpad.net/bugs/1846042
15:31:16 <csharp> #info request for attention for Hopeless Holds (https://bugs.launchpad.net/evergreen/+bug/1811710) and Angular admin page filters (https://launchpad.net/bugs/1846042)
15:31:17 <pinesol> Launchpad bug 1811710 in Evergreen "wishlist: Improvements to Hopeless Holds" [Wishlist,Confirmed]
15:31:18 <pinesol> Launchpad bug 1846042 in Evergreen 3.3 "Angular admin pages need filters" [High,Confirmed]
15:31:50 <berick> jeffdavis: for the grid filters, UX/Usability are the main concerns at this point?
15:32:13 <sandbergja> jeffdavis: I wonder if this commit might help with the cluttering filter issue: https://github.com/evergreen-library-system/Evergreen/commit/9077cbc427d544b25c932b51591126e4a2b2bead
15:32:13 <pinesol> sandbergja: [evergreen|Galen Charlton] LP#1855931: (follow-up) make grid filter control cells wrap as well - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9077cbc>
15:32:28 <jeffdavis> berick: yes, I think so
15:32:49 <jeffdavis> ah, I was trying to find that follow-up bug
15:32:55 <sandbergja> (just musing, I have not tested a rebased version of gmcharlt's branch for 1846042)
15:33:39 <terranm> PINES has this one in production and it seems to be working well: https://bugs.launchpad.net/evergreen/+bug/1570072  - I'm not sure if anyone else from ECDI has seen any issues with testing
15:33:40 <pinesol> Launchpad bug 1570072 in Evergreen "Hold request update notification preferences on change" [Wishlist,Confirmed]
15:34:44 <jeffdavis> terranm: do you want that targeted for 3.5? Currently it's 3.next
15:34:44 <csharp> ECDI = Evergreen Community Development Initiative for those who don't know
15:34:56 <Bmagic> do we have a list of bugs for the feedback fest?
15:35:02 <remingtron> csharp: thanks for translating
15:35:19 <terranm> jeffdavis: Since we already have it in production, I don't have any preference which it's targeted to
15:35:29 <csharp> jeffdavis: makes sense to me
15:35:47 <terranm> Bmagic: not yet - I'll take a look through the pullrequests. Maybe we can put some on your sandbox and some on one of ours.
15:35:59 <jeffdavis> Ha, fair enough. I've retargeted it.
15:36:10 <csharp> jeffdavis++
15:36:11 <terranm> jeffdavis++ :)\
15:36:15 <terranm> I mean, :)
15:37:06 <csharp> ok, unless there's more to talk about 3.5, let's move to Hatch
15:37:08 <Bmagic> also - getting into launchpad fu - do we have a guideline for how we target bugs, etc? When the milestone needs to change and whatnot?
15:38:19 <csharp> Bmagic: I don't know of specific documentation on that, but I can see it would be helpful
15:38:49 <Bmagic> word
15:38:59 <berick> Bmagic: any specific questions?
15:39:31 <Bmagic> I thought of it when thinking about a recent patch bug 1849736
15:39:32 <pinesol> Launchpad bug 1849736 in Evergreen "Add action trigger for email/sms for patron self registration" [Wishlist,In progress] https://launchpad.net/bugs/1849736
15:39:40 <csharp> #info there is a need for documentation around bug wrangling guidelines - specifically release/milestone/series targeting
15:40:08 <remingtron> Bmagic: There's a wiki page about some of it: https://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq
15:40:14 <csharp> remingtron++
15:40:20 <Bmagic> Not sure I did the right thing with LP
15:40:23 <Bmagic> remingtron++
15:40:46 <csharp> #info and like a magician, remingtron provided a wiki link: https://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq
15:40:57 <Bmagic> magician++
15:41:04 <berick> Bmagic: bug looks fine.  new features should target 3.5-alpha until it's cut
15:41:33 <csharp> RMs and other wranglers will untarget/retarget bugs as needed when the cut comes
15:42:06 <csharp> #topic Hatch
15:42:23 <csharp> any updates on that? - we saw an omnibus bug come through recently
15:42:33 <berick> I opened Hatch bug #1860187 recently
15:42:34 <pinesol> Launchpad bug 1860187 in Evergreen "Hatch Windows installer creates properties files with limited read access" [Undecided,New] https://launchpad.net/bugs/1860187
15:42:37 <berick> and we're tesing it locally
15:43:39 <csharp> we've seen some trouble in PINES with Hatch running on 32-bit systems, but we've disavowed Windows 7 support and the libraries have Windows 10 64-bit available to them
15:43:53 <csharp> so we didn't dig much on that
15:44:48 <Bmagic> I've seen that with 0.3.2 because it ships it's own jre - 64 only?
15:44:52 <berick> with hatch 0.3.2, 32-bit is not supported...
15:44:53 <berick> right
15:45:00 <csharp> ok - good to know
15:45:23 <csharp> again, probably not a real problem since people need to stop using EOL systems :-)
15:45:51 <terranm> There are 32-bit Windows 10 systems out there, though - at the very least, it should be mentioned on the downloads page / installation instructions
15:46:18 <csharp> ok, on to new business...
15:46:25 <Bmagic> csharp: been there as well and I've gone as far as replacing the alrady-installed (C:\Program File (x86)s\Hatch\java-*) folders with the 32 bit counter parts - I don't recommend it :)
15:46:36 <csharp> Bmagic: heh
15:46:41 <terranm> Bmagic: ew!
15:46:44 <csharp> #topic Feedback for New Features Under Development
15:47:04 <csharp> looks like berick has at least one item there
15:47:27 <sandbergja> I put the promise-related one there
15:47:31 <berick> i believe sandbergja goes...
15:48:04 <sandbergja> This grew out of conversations about bug 1821094
15:48:05 <pinesol> Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094
15:48:43 <sandbergja> gmcharlt suggested that -- in cases where we need to do a bunch of requests -- we batch those requests
15:49:01 <sandbergja> So we don't totally slow down everything for the user with sequential requests
15:49:12 <sandbergja> But don't clobber the server with simultaneous requests
15:49:35 <sandbergja> jeffdavis mentioned that this should be an approach that we take not just in Item Status, but throughout the Web client
15:50:05 <berick> sandbergja: your promise batching code looks sane.  i have not kept up with the bug... does that solve the issue in your tests?
15:50:18 <sandbergja> It does
15:50:31 <sandbergja> But all my tests have been on a little VM on my laptop
15:51:00 <sandbergja> So I'd really appreciate more help testing the specific case in bug 1821094
15:51:01 <pinesol> Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed] https://launchpad.net/bugs/1821094
15:51:35 <sandbergja> And also some discussion about whether we want to batch the promise resolving in other places in the AngularJS client
15:51:49 <sandbergja> Here's the specific commit: https://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=75176bca0ce8051a6dd4ba56f5613bce75901f09
15:52:15 <csharp> sandbergja: we can test it on a PINES server with realistic data/specs
15:52:26 <sandbergja> charp++
15:52:31 <sandbergja> That would be really helpful!
15:52:56 <csharp> #action csharp will arrange testing for sandbergja's fix to https://launchpad.net/bugs/1821094 on a realistic test server
15:52:57 <pinesol> Launchpad bug 1821094 in Evergreen 3.3 "Item status refresh after editing can get confusingly slow" [Medium,Confirmed]
15:53:11 <berick> i think that's a good tool to have in our toolbox.  I also think devs should consider the option of creating UI specific APIs for new interfaces.
15:53:28 <berick> batching some of the exising angjs stuff seems like it would be helpful
15:53:52 <sandbergja> berick: UI-specific APIs seem like they would be helpful for the AngJS->Angular transition
15:54:21 <csharp> heads up: I have kind of a hard stop at 4:00 - gotta pick up a kid
15:54:26 <berick> sandbergja: indeed
15:54:34 <sandbergja> Okay, I can be done with my item!
15:54:37 <sandbergja> Thanks, all!
15:54:53 <berick> sandbergja: but I also wouldn't want to cause too much disruption to the existing andjs code just to prep for angular.
15:55:08 <csharp> but if someone wants to take over and follow https://wiki.evergreen-ils.org/doku.php?id=community:using-meetbot and the agenda https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-02-04 you don't have to rush :-)
15:55:11 <sandbergja> that makes sense
15:56:49 <csharp> okay, so "needsdiscussion" tag was mentioned - anyone want to champion that cause?
15:57:41 * csharp can probably let his son wait a bit, so is willing to go past 4:00 EST if needed
15:57:53 <berick> who added that agenda item?
15:58:09 * csharp grumbles $deity knows I've waited for him enough
15:58:35 <berick> heh
15:58:54 <csharp> oh - hmm - looks like that comes free with the agenda boilerplate
15:59:00 <berick> ah
15:59:08 <csharp> yeah, so...
15:59:14 <csharp> berick: feel free to move to your topic
15:59:31 <berick> k
15:59:36 <berick> csharp: be free :)
16:00:21 <csharp> berick: thanks - I'll let you take it from here :-)
16:00:37 <berick> my agenda items essentially boil down to angular staff catalog:  what do we want to do for 3.5 and looking ahead to 3.6
16:00:52 <berick> WRT it being a replacement (whole or part) to the embedded tpac
16:01:42 <remingtron> berick: is there a list of missing features?
16:02:11 <berick> https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angular_staff_catalog
16:02:44 <berick> quite a few open pullreuquests.  a small handlful of not-yet-coded features
16:02:45 <csharp> as a parting comment, I'll mention there's *some* (not sure how widespread/intense) feeling here that staff need/expect the patron opac within the client - I'm not sure I agree, but it was a specific request from The Beginning of Evergreen in PINES
16:02:52 * csharp jets
16:04:01 <berick> as with the XUL client, it's one tab over
16:04:44 <sandbergja> Does anybody have a sense for how much the Angular catalog is currently being used in production?
16:05:26 <Dyrcona> I'll add that having the patron in the staff client was one of the selling points of Evergreen at MVLC, because staff could see more or less what patrons saw.
16:05:37 <berick> i haven't heard one way or the other, sandbergja
16:05:57 <sandbergja> My vague sense is that it's not quite ready to be the default catalog, but definitely ready to be less hidden...
16:06:24 <berick> re: what patrons see, there is a tab in the detail page that shows the patron view.  you can also open a new tab to the tpac.  i'm confused what the issue is on that.
16:07:26 <terranm> I honestly haven't looked at it since Bill did a demo for the catalogers group a few months ago, but Chris enabled it on one of our test servers so I'll make a point to look further with real data
16:07:36 <jeffdavis> We haven't enabled the Angular catalogue in production here, but I've proposed making it visible. We're seeing a lot of slowness in the staff catalogue and I wonder if the Angular version would be an improvement.
16:07:41 <berick> sandbergja: same.  until it gets more use in the wild, making it the default is a hard sell.
16:08:18 <berick> and by the same token, if no staff know it exists, no one will use it
16:08:38 <berick> it's a bit complicated, since using it requires extra steps (since all the links lead back to the tpac catalog)
16:09:30 <jeff_> is there anything architectural preventing a mode/setting where any catalog links (from, say, grids/etc) go to the angular staff catalog?
16:09:48 <berick> jeff: just a whole lot of if/else statements
16:09:58 <berick> or a redirect
16:10:03 <sandbergja> Dyrcona: here is how the patron view of individual bib records is currently showing up in the Angular catalog: http://www.sandbox.lbcc.linnlibraries.org/patron_view_tab.gif
16:10:27 <jeff> maybe a prefix that's set in one place and then used everywhere we link?
16:10:34 * Dyrcona forgot about the meeting until his name was mentioned earlier. :)
16:10:43 <sandbergja> Dyrcona: fwiw, the catalogers working group seemed pretty happy with the patron view tab
16:11:03 <terranm> +1 to the patron view tab
16:11:07 <jeffdavis> sandbergja: that's a surprising number of reference copies of that particular title
16:11:32 <berick> jeff: maybe.  but it gets complicated with routerLink's, target=_self, etc. depending on the context
16:14:14 <jeffdavis> berick: sounds like more testing is wanted before we make it the default, but maybe we can at least make it more visible (or not call it "Experimental" anymore or whatever) in 3.5?
16:14:27 <terranm> +1
16:14:35 <remingtron> berick: maybe during feedback fest we could invite EG users to test the staff catalog and give feedback
16:14:48 <remingtron> (and/or during a bug squashing week)
16:14:57 <terranm> +1
16:15:30 <berick> remingtron: on that note, I'll be posting all of the pending staff catalog pullreqs to a demo server for fests and squashes
16:15:40 <remingtron> cool
16:16:12 <berick> so i'll post a LP about making it visible by default in 3.5, while retaining the option to hide it
16:16:30 <sandbergja> berick++
16:16:45 <berick> can just keep the same org setting, requiring an explicit 'false' to hide it.  and will request feedback on labeling
16:17:25 <berick> #action berick to open LP on showing link to ang staff cat by default in 3.5
16:17:52 <berick> anything else on that topic?
16:18:32 <berick> #topic QA-related bugs
16:18:55 <berick> did someone add this one or is it another boilerplate entry?
16:19:18 <jeff> berick: you don't appear to be chair, so none of your commands are being picked up by meetbot. fixing.
16:19:18 <remingtron> boilerplate, I think
16:19:28 <berick> jeff: oh bleh
16:19:36 <jeff> added you.
16:19:40 * berick notes the LP link produces no results, so...
16:19:43 <berick> thanks jeff
16:19:57 <berick> #action berick to open LP on showing link to ang staff cat by default in 3.5
16:19:58 <jeff> if you re-do your #info and #topic i think that's all
16:20:03 <jeff> er, action. yeah.
16:20:25 <berick> i'll skip the QA topic since it seems to be a no-go
16:20:34 <berick> ok, any other business to discuss today?
16:21:48 <berick> #idea more cowbell
16:21:50 * berick is practicing
16:21:51 <berick> ok
16:21:53 <berick> #endmeeting