15:00:25 <gmcharlt> #startmeeting Development Meeting, 4 June 2019
15:00:25 <pinesol> Meeting started Tue Jun  4 15:00:25 2019 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:25 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:25 <pinesol> The meeting name has been set to 'development_meeting__4_june_2019'
15:00:31 <gmcharlt> #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2019-06-04
15:00:36 <gmcharlt> #topic Introductions
15:00:47 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox, 3.4 RM
15:00:49 <JBoyer> #info JBoyer = Jason Boyer
15:01:03 <sandbergja> #info sandbergja = Jane Sandberg, Linn-Benton Community College
15:01:04 <rhamby> #info rhamby = Rogan Hamby
15:01:15 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:01:22 <dbs> #info dbs = Dan Scott, Laurentian University
15:01:36 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
15:01:41 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:01:57 <Dyrcona> #info Dyrcona = Jason Stephenson, CW MARS
15:03:17 <gmcharlt> #topic Action items from previous meetings
15:03:25 <gmcharlt> so, dbwells, you had a couple
15:03:27 <gmcharlt> any updates?
15:03:32 <dbwells> Sure
15:04:01 <dbwells> First, some progress was made on getting Syrup working on modern Ubuntu/Python 3.
15:04:29 <dbwells> It is far enough along that an interface now loads and displays generic object strings.
15:04:48 <miker> #info miker = Mike Rylander, EOLI
15:05:13 <dbwells> One significant hurdle we have backburnered is regarding a Z39.50 Python module which has no working Python 3 version.
15:06:06 <dbwells> I don't have a good idea how that fits yet in the big picture, and whether we'll need to shepherd that along or replace it outright.
15:06:28 <dbwells> As far as buildmaster call, I decided to delay that until 3.1 is done in a few more months.
15:07:10 <dbwells> Since I was RM for two of our three supported releases, and made particular committments regarding 3.1 support, the time wasn't quite right yet to step back, I think.  But, soon :)
15:07:25 <gmcharlt> does that negate a desire for additional help?
15:08:14 <dbwells> Yes, I think for now we are good.  I expect to look for more help around late August.
15:08:39 <gmcharlt> ok
15:08:59 <dbwells> That said, the door is always open, of course.
15:09:18 <gmcharlt> w.r.t. the OpenSRF Python binding, do you have a sense yet about whether you are willing to assume reponsibility, or is it too early yet?
15:11:14 <dbwells> Our first priority is getting it working with Syrup, and I think that goal is shared by others in the community.  I would likely need help implementing some of the newer OpenSRF features from scratch.
15:12:03 <gmcharlt> ok
15:12:37 <gmcharlt> I think "assuming responsiblity"  here is more about willingness to drive, not writing the patches singlehandedly
15:13:04 <gmcharlt> I can help with respect to some of the new features, but do not promise idiomatic Python3 code
15:13:14 <dbs> I hope to be able to contribute some time to making at least the existing OpenSRF Python functionality available in Python 3, starting around August
15:13:20 <gmcharlt> dbs++
15:13:36 <JBoyer> dbwells++
15:13:46 <JBoyer> dbs++
15:14:03 <gmcharlt> #info dbwells has started work on porting Syrup to Python 3; one blocker is updating a z3950 module that doesnt' yet have a python3 equivalent
15:14:48 <gmcharlt> #info some initial additional promises of assistance for the python3 OpenSRF binding have been made
15:15:04 <gmcharlt> #info Call for additional buildmaster to be deferred until closer to August
15:15:27 <gmcharlt> as far my action item is concerned
15:15:42 <gmcharlt> I expect to drop a patch for that in a couple weeks
15:15:44 <gmcharlt> so
15:15:48 <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:15:53 <gmcharlt> moving on
15:15:57 <gmcharlt> #topic OpenSRF release
15:16:10 <gmcharlt> #action gmcharlt will cut OpenSRF bugfixes releases on 7 June
15:17:10 <gmcharlt> mostly just to accumulate bugfixes
15:17:40 <gmcharlt> I'm also looking at bug 1824181 and bug 1824184
15:17:42 <pinesol> Launchpad bug 1824181 in OpenSRF "Allow first argument to logger to be string or subroutine" [Undecided,New] https://launchpad.net/bugs/1824181
15:17:43 <pinesol> Launchpad bug 1824184 in OpenSRF "Change potentially slow log statements to subroutines" [Undecided,New] https://launchpad.net/bugs/1824184
15:17:47 <gmcharlt> particularly with an eye towards seeing if they can be safely backported to 3.1.x
15:18:32 <gmcharlt> any questions or other OpenSRF thoughts?
15:18:54 * miker begs for tuits...
15:18:57 <miker> for opensrf
15:19:13 * gmcharlt tosses a tuit into the air
15:19:21 <gmcharlt> miker: where are you specifically hoping it will land?
15:20:08 <miker> gmcharlt: c-side improvements to chunking, and parameter streaming ... but those are both too big for 6/7
15:20:11 <miker> I think
15:20:28 <gmcharlt> yeah, I think so as well
15:20:29 * miker watches tuit fall through the sewer grate, lost forever
15:20:49 <gmcharlt> I'm viewing the 6/7 releases as bugfixing anyway
15:21:07 <gmcharlt> ok, moving on
15:21:18 <gmcharlt> #topic Evergreen update
15:21:32 <gmcharlt> #info Feedback Fest #1 happened - https://wiki.evergreen-ils.org/doku.php?id=dev:3.4:feedback_fest_1
15:21:54 <gmcharlt> #info So did Bug Squashing Week - https://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing:2019-05
15:22:15 <gmcharlt> one thing I'm particularly curious about is feedback for, well, Feedback Fest
15:22:36 <gmcharlt> specifically, whether any changes to its format or structure should be contemplated for the second one
15:23:33 <Dyrcona> Seems like it was a good bit of work for you, gmcharlt.
15:25:14 <gmcharlt> Dyrcona: yeah, as I expected
15:25:19 <Dyrcona> From my point of view, I'd say it was useful and the overlap with bug squashing week seemed to simplify things.
15:25:53 <Dyrcona> Well, do you have any ideas for improvements, since you did the bulk of the work?
15:25:55 <gmcharlt> but the only part I found particularly problematic was the lack of a decent API in LP, but that's hardly news
15:27:00 <Dyrcona> Yeah, the API used to work, then didn't, but it was never that great to work with. It may be working again depending on Ubuntu release or Python version. I haven't tried it in a few years.
15:27:06 <gmcharlt> the main thing I'm thinking of doing differently for the second fest is buttonholing all of the committers earlier in the process to hopefully get a bit more evenness of the patch review work
15:27:59 <gmcharlt> I will note that compared to the two I ran for 3.0, the first 3.4 fest was the most productive yet
15:28:15 <gmcharlt> we just had/have a much bigger backlog of PRs w/o SOs
15:28:32 <JBoyer> I don't have much to add, but I will say that having the two weeks overlap does seem like a good idea that worked well, as the people that participate in one may or may not be able to in the other, but the two projects do support each other.
15:29:35 * gmcharlt makes notes
15:29:41 <gmcharlt> moving up
15:29:44 <gmcharlt> *on
15:29:49 <gmcharlt> #topic Hatch update
15:29:54 <gmcharlt> any updates on Hatch?
15:30:49 <JBoyer> None here.
15:31:02 <gmcharlt> ok
15:31:16 <gmcharlt> #topic Bug discussion
15:31:42 <gmcharlt> so one with the needsdiscussion tag I'd like to highlight is bug 1778414
15:31:45 <pinesol> Launchpad bug 1778414 in Evergreen "The catalog menu should include Item Status" [Undecided,Confirmed] https://launchpad.net/bugs/1778414 - Assigned to Meg Stroup (mstroup)
15:32:16 <gmcharlt> which basically boils down to if, and under what circumstances, we want to allow duplicate menu entries in the staff interface
15:32:20 <jeff> It would be good to get a new Hatch build out there, especially with regard to the Oracle license changes. To the best of my understanding, the only Hatch that works well with OpenJDK is not available on the download page yet.
15:33:34 <gmcharlt> JBoyer: any obstacle to ^^ that folks can help with?
15:34:27 <JBoyer> To my knowledge all that's really needed is testing. berick has a branch available to build your own windows installer with all of the new openjdk bits
15:34:48 <JBoyer> (looping up lp)
15:35:35 <JBoyer> Ah, bug 1830391 and there's also a pre-built installer to test.
15:35:36 <pinesol> Launchpad bug 1830391 in Evergreen "Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New] https://launchpad.net/bugs/1830391
15:36:24 <JBoyer> being an omnibus bug including Eg patches for one of the issues addressed might make it slightly more work to test, but if anyone wants to sign off on what they can test I'm sure it would help.
15:37:00 <gmcharlt> #info Call for testers for Hatch ombnibus bug 1830391 (https://bugs.launchpad.net/evergreen/+bug/1830391)
15:37:01 <pinesol> Launchpad bug 1830391 in Evergreen "Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New]
15:37:23 <jeff> Once it has signoff and is committed / etc, how does the installer generally make it to the download page for Hatch? Ad hoc at the moment?
15:38:03 <gmcharlt> I believe ad hoc
15:38:06 <JBoyer> Yeah, I believe so far berick has built the releases and shipped them to the web team as needed.
15:38:19 <jeff> Works for me! Thanks, and sorry for rewinding the topic. :-)
15:38:34 <gmcharlt> no worries
15:38:45 <gmcharlt> so bug to bug 1778414, he said, redundantly
15:38:46 <pinesol> Launchpad bug 1778414 in Evergreen "The catalog menu should include Item Status" [Undecided,Confirmed] https://launchpad.net/bugs/1778414 - Assigned to Meg Stroup (mstroup)
15:38:48 <gmcharlt> *back to
15:39:28 <gmcharlt> I don't personally have a strong feeling either way, but do think we should come up with a consistent policy
15:40:25 <miker> opinion: if we consider each menu as the lauching point for all of what a particular class of staff member needs to do (generally speaking), I think the duplication is fine
15:40:32 <gmcharlt> (I do have a stronger feeling that if we do run with having duplicate menu items, that we give each instance the same label unless there's a complelling reason to refer to a given action/page by multiple naems)
15:40:45 <miker> if we consider the menus like windows application menu bars, not so much
15:40:48 <JBoyer> I think as long as it's in the menus and any link to the same route always has the same name I'm +1 to it. Since you can't have multiple menus open at once it shouldn't be especially confusing.
15:41:31 <miker> IOW, they're not really like File, Edit, Settings, Tools
15:41:44 <sandbergja> miker: the cataloger here (who originally prompted this bug) saw them as windows application menu bars
15:41:54 <dbwells> gmcharlt++ # linking to Nielson Norman Group discussions
15:41:55 <sandbergja> and saw Item Status as being misplaced
15:42:01 <miker> but Circ Staff, Cat Staff, Acq Staff
15:42:11 <miker> sandbergja: ah, so you'd propose /moving/ it?
15:42:32 <jeff> "Circulation -> Item Status" and "Search -> Search for Copies by Barcode" both lead to the same ("cat" app) url, /eg/staff/cat/item/search
15:42:58 <sandbergja> miker: I'd prefer either moving or duplicating it, since it is such a key part of cat workflows
15:43:13 * JBoyer isn't especially fond of calling anything where you enter a direct identifier a "search"
15:43:28 <sandbergja> But, to be fair, I have only talked to cat folks about it, not circ folks. :-)
15:43:33 <miker> JBoyer: boy howdy...
15:43:48 <miker> sandbergja: yeah, I get the feeling it's pretty key to circ folks, too
15:43:54 <miker> for item-in-hand work
15:43:58 <JBoyer> miker, I mean, I did add back "search for patrons by barcode" to our search menu, I just didn't like it. ;)
15:44:26 <gmcharlt> JBoyer: we can only search for things... never find them ;)
15:44:42 <sandbergja> I am definitely in favor of having some more established principles for the menus
15:44:45 <JBoyer> gmcharlt++
15:45:43 <dbwells> I think as long as we are having task specific menus, duplication is inevitable to fully support those tasks/workflows.  Other systems use object specfic workflows (i.e. a Patron menu, an Item menu, a Record menu, etc.), but we don't have that :)
15:45:46 <miker> anyway, +1 to duplicating item status (specifically) and letting the thunderdome decide on others in the future
15:45:51 <JBoyer> I think we're all pointing in vaguely the same direction (duplication is fine in menus, try to always use the same name, Search is ... search.) Does that sum it up?
15:45:56 <Dyrcona> I'm inclined to not change it and tell people to customize it locally. I can see it getting out of hand if everybody wants all kinds of commands duplicated. At some point, duplication ends up being unhelpful.
15:46:33 <gmcharlt> so, since I'm not seeing a big cry for no duplication... how about this as a principle: "Menus in the Evergreen staff interface serve as an entry point to the functionality most used by various classes of library staff, and as such, duplication of menu items between menus is permitted provided that the same page/function has the same name in each copy."
15:46:48 <dbwells> +1 to duplicating this one, +1 to making labels the same
15:48:01 <miker> (we may just have to carry the search->copies-by-barcode as a wart)
15:48:41 <gmcharlt> Dyrcona: FWIW, I'm not much in favor of encouraging tweaks to staff templates or (even worse) Angular HTML. If there ends up being a strong desire for customization of staff menus, it would be more work, but I'd propose doing database-driven menus
15:48:47 <JBoyer> While I'm fine with Dyrcona's warning to not do this frivolously, the reason this is coming up is that the XUL client did have it in both places (with different names)
15:49:06 * phasefx is glad he was vetoed long ago on having an extra set of menus that started with the nouns Item, Bib, etc.
15:50:06 <Dyrcona> I agree that if duplication is going to happen, then the names and functions should be the same.
15:50:07 <JBoyer> phasefx, extra might have been over the top, but maybe instead? The world may never know. ;) (Or we may, depending on how annoyed / relieved Wf users are when they switch, heh.)
15:50:46 * phasefx was thinking Circ, Cat, etc. at the top, and Item, Bib, etc. at the bottom near the status bar ;)
15:51:24 <phasefx> I'm +1 gmcharlt's stated principle, fwiw
15:51:42 <miker> phasefx: like a software mullet: verbs at the top, nouns on the floor
15:52:00 <miker> ;)
15:52:11 <phasefx> and picture buttons in the middle
15:52:30 <JBoyer> I'm also +1 to gmcharlt's proposed principal.
15:53:44 <miker> +1 as well
15:54:33 <gmcharlt> ok, I've updated the bug
15:54:39 <jeff> eliminate menus. series of RPN style buttons. first, select BARCODE, then select ITEM...
15:54:51 <gmcharlt> we have six minutes -are there any other bugs or other topics folks want to bring up?
15:55:01 <gmcharlt> jeff: HP can have that so long as they sponsor Evergreen with all their money
15:55:06 <phasefx> live search box for all functionality
15:56:17 <gmcharlt> phasefx: all of Google's money for that one
15:57:09 <gmcharlt> any other last minute topics?
15:58:21 * gmcharlt now gives each of you two free minutes to use as you see fit
15:58:23 <gmcharlt> #endmeeting