15:04:43 <gmcharlt> #startmeeting Evergreen Development Meeting, 6 February 2019
15:04:43 <pinesol> Meeting started Wed Feb  6 15:04:43 2019 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:43 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:04:43 <pinesol> The meeting name has been set to 'evergreen_development_meeting__6_february_2019'
15:04:53 <gmcharlt> #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2019-02-06
15:05:02 <gmcharlt> #topic Introductions
15:05:10 <Dyrcona> #info Dyrcona is Jason Stephenson, CW MARS
15:05:16 <gmcharlt> #info gmcharlt = Galen Charlton, EOLI
15:05:20 <dpearl> #info dpearl is Dan Pearl, CWMARS Inc.
15:05:22 <abowling> #info abowling is Adam Bowling, Emerald Data Networks
15:05:30 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
15:05:31 <JBoyer> #info JBoyer = Jason Boyer, Evergreen Indina, ISL
15:05:34 <miker> #info miker = Mike Rylander, EOLI
15:05:36 <dbwells> #info dbwells is Dan Wells, Hekman Library (Calvin College)
15:05:36 <abneiman> #info abneiman is Andrea Buntz Neiman, EOLI
15:05:54 <berick> #info berick Bill Erickson, KCLS
15:06:03 <stephengwills> #info Stephengwill working with Maine Balsam Library Consortium
15:06:13 <rhamby> #info rhamby is Rogan Hamby, EOLI
15:06:42 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:07:14 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:07:49 <gmcharlt> #topic Action items from previous meeting
15:08:10 <gmcharlt> berick, JBoyer, csharp: where do we stand with a Hatch release?
15:08:24 <JBoyer> It lives.
15:08:33 <berick> indeed
15:08:33 <JBoyer> Thanks to gsams testing
15:08:36 <JBoyer> gsams++
15:08:43 <gmcharlt> gsams++
15:09:08 <gmcharlt> #info New Hatch release has been made
15:09:21 <abowling> berick++
15:09:24 <abowling> jboyer++
15:09:26 <abowling> gsams++
15:09:29 <gmcharlt> berick, Bmagic: where stands the Dymo branch?
15:09:46 <berick> I hope to spend some time on that this and next week, in fact
15:10:05 <gmcharlt> great
15:10:12 <gsams> I've been testing that as well this week
15:10:12 <gmcharlt> I'll just carry the action item forward then
15:10:24 <gmcharlt> #action Bmagic, berick, gsams et al will poke more on the Dymo branch
15:10:33 <berick> gsams++ great
15:10:52 <gmcharlt> #topic OpenSRF release
15:11:07 <gmcharlt> #info OpenSRF 3.1.0 was released on 2019-01-17
15:11:28 <gmcharlt> anybody seeing issues running it (and not just the websocketd stuff) in production?
15:11:57 <miker> no me! :)
15:12:11 <csharp> we're running it in a test environment that's pretty well-used - no complaints yet
15:12:24 <Dyrcona> I haven't used it in production, but it seems to work fine on my VMs, even with Evergreen 3.0.
15:12:32 <csharp> (OpenSRF 3.1.0 + websocketd)
15:12:38 <gmcharlt> ok
15:12:43 <JBoyer> We actually have master running in production here and haven't noticed any issues
15:12:48 <Dyrcona> I have backported the websocketd stuff to OpenSRF 3.0 and that works fine in production.
15:13:03 * JBoyer was impatient for websocketd
15:13:14 * csharp is impatient for it now
15:13:18 <gmcharlt> I've got some questions about future directions (in addition to the topics Dyrcon's raised for later)
15:13:43 <gmcharlt> first - are folks OK with the removal of Tahr being targeted for 3.1.1 (as opposed to a 3.2.0)?
15:14:03 <Dyrcona> I'm fine with that. I had hoped it would be gone by 3.1.0, myself.
15:14:05 <gmcharlt> related - any reasons pro or con for making 3.1.0 be the minimum version for Evergreen 3.3?
15:14:29 <dbwells> We are running a December master of OpenSRF in production, so not exactly 3.1.0, but pretty close.  No complaints!
15:14:46 <berick> no objection to Tahr support removal
15:14:54 <csharp> took me a second to realize that "Tahr" is referring to Ubuntu' 14.04
15:14:54 <gmcharlt> and another q: any reason not to remove the apache2-websocket stuff from the core installation instructions for 3.1.1?
15:15:01 <berick> csharp: me too :)
15:15:08 <csharp> I think it has to be done - it's EOL as of April
15:15:14 <abowling> it's not so trusty anymore ;)
15:15:20 <berick> zing
15:15:21 <csharp> abowling++
15:15:27 <Dyrcona> heh.
15:15:27 <JBoyer> abowling++
15:15:28 <gmcharlt> just a pile o'bones...
15:15:31 <Dyrcona> abowling++
15:15:46 <miker> gmcharlt: should we consider pinning a websocketd version for each opensrf release going forward?
15:15:54 <berick> gmcharlt: +1 to removing apache2-websocket from docs.  it's complicating the setup.
15:15:56 <csharp> gmcharlt: +1 for websocketd-only
15:16:13 <miker> I mean, it's a low risk, but options changing under us...
15:16:15 <JBoyer> +1 to removing 14.04 support,
15:16:19 <csharp> it's so frickin' simple, my mom could do it!
15:16:20 <gmcharlt> and my final small question for now: any reason why starting up websocketd could be done as a new osrf_control command?
15:16:20 <Dyrcona> +1 for dropping apache2-websocket
15:16:27 <JBoyer> and +1 to dumping apache-websockets
15:16:35 <dbwells> +1 to removing the apache2-websockets instructions.  I am enjoying not killing random stuck Apache processes every few days.
15:16:38 <miker> and +1 to both removing 14.04 and apache-websockets
15:16:39 <gmcharlt> obviously that would bake in running it as the opensrf user, but that doesn't seem like a big deal
15:16:54 * csharp imagines his mom actually trying to install websocketd on a Linux server
15:16:57 <abowling> +1 removing apache2-websocket and tahr
15:17:03 <stephengwills> balsam runs 3.1.8 w/ apache-websockets.  will need help on ow to convert to new method.  is Balsam alone in this?
15:17:10 <abowling> csharp++
15:17:27 <csharp> stephengwills: nearly everyone is still running it - not alone by far
15:17:30 <Dyrcona> gmcharlt: Do you envision starting websocketd as part of --start-all or would it be an entirely separate command?
15:17:55 <berick> gmcharlt: i had considered adding it as an osrf_control command, so no objections there.  I also run it as user 'opensrf' in the systemd setup, fwiw.
15:17:57 <JBoyer> I'm fairly happy with it being a separate systemd service.
15:18:06 <csharp> I think it should be separate
15:18:14 <Dyrcona> conversion to websocketd is rather straight forward.
15:18:15 <gmcharlt> Dyrcona: I think either a separate command or maybe adding a flag to opensrf{_core?}.xml indicating that it shoudl be started via a --startl-all
15:18:28 <miker> Dyrcona: IMO, since it opens a new listening port, rather than actively connecting to /something else/ (xmpp server), I'd be in favor of a separate command
15:18:36 <csharp> --start-lol
15:18:54 <Dyrcona> gmcharlt: OK. I ask because I start websocketd via sudo to read our SSL certs.
15:18:59 <miker> csharp: the irony is that you just decremented a great joke ;)
15:19:05 <csharp> heh
15:19:20 <Dyrcona> I'm for keeping it separate, personally.
15:19:43 <gmcharlt> miker: re websocketd versions, strikes me as the sort of thing to note compatibility when doing new releases of OpenSRF
15:19:51 <gmcharlt> though hopefully short of a full pin
15:20:04 <miker> Dyrcona: are you using haproxy? (nginx localhost might free you from that)
15:20:14 <JBoyer> It also hinges on another version actually being released... :/
15:20:23 <miker> gmcharlt: sure, I'm more raising the question than advocateing
15:20:36 <gmcharlt> JBoyer: happy news on that front - I see that commits are showing up in websocketd's github repo again
15:20:43 <miker> JBoyer: point
15:20:46 <JBoyer> Ah, very nice.
15:20:50 <miker> oh, good!
15:20:53 <Dyrcona> miker: No. We have ldirectord and no proxy for the SSL. Our web staff clients connect to the high-numbered port directly.
15:21:01 * JBoyer wasn't looking forward to learning Go. ;)
15:21:11 <Dyrcona> We're a bit odd in that respect.
15:21:19 <miker> what's one more language?
15:21:43 <gmcharlt> ah, and in particular 0.3.1 was released 9 days ago
15:22:09 <gmcharlt> or prereleased, anyway
15:22:23 <berick> JBoyer: hopefully we never have to
15:22:23 <gmcharlt> oh, with .debs available
15:22:32 <gmcharlt> ok, so summarizing the discussion
15:22:52 <gmcharlt> #agreed patch for removing Trusty Tahr support will be applied for a 3.1.1 release
15:23:11 <gmcharlt> #agreed apache2-websockets instructions will be removed or seriously deemphasized for a 3.1.1 release
15:23:35 <gmcharlt> #action gmcharlt will open a bug to continue discussions about osrf_control or other means of websocketd startup management
15:24:24 <gmcharlt> so I think that leaves the question of thoughts on having 3.1.x be the minimum required version for Evergreen 3.3
15:25:27 <JBoyer> If there's anything about 3.3 that would be made simpler by also dropping 14.04 that would be a good time to sync them up.
15:25:29 <gmcharlt> on the one hand, there's no actual technical requirement yet, although I _might_ write a patch to take advantage of the new 503 status to make the OPAC display a sensible message if open-ils.search or open-ils.storage gets overcapacity
15:25:39 <Dyrcona> I don't have a problem with that, but I think it does actually work with 3.0, doesn't it?
15:25:56 <gmcharlt> on the other hand - requiring it woudl be a way of encouraging folks to switch to websocketd
15:26:18 <Dyrcona> JBoyer: We do not want to ship 3.3 with support for Trusty Tahr, since 14.04 is EOL in April.
15:26:37 <gmcharlt> (and I'm content to open a bug and punt the discussion over there)
15:27:15 <gmcharlt> which I'll do
15:27:24 <miker> gmcharlt: one question
15:27:30 <gmcharlt> miker: yeah?
15:27:38 <miker> actually, nevermind
15:27:44 * gmcharlt exhales
15:27:47 <miker> heh
15:27:51 <Dyrcona> :)
15:27:58 <gmcharlt> #action gmcharlt will open bug about whether to require OpenSRF 3.1.x for Evergreen 3.3
15:27:59 <JBoyer> Dyrcona, I see, makes sense with their release cadences that it's only really a Q for OSRF.
15:28:08 <miker> once we start builing binaries (ha!) I'll ask :)
15:28:17 <gmcharlt> so that brings us to
15:28:17 <miker> building, even
15:28:25 <gmcharlt> #topic Evergreen release
15:28:31 <gmcharlt> dbwells?
15:29:00 <dbwells> An update was sent to the general list this morning, so nothing to add beyond that.
15:29:04 <dbwells> Any questions?
15:30:12 <dbwells> Then my plan to reduce my role in this meeting worked brilliantly.
15:30:19 <Dyrcona> :)
15:30:23 <gmcharlt> #info Evergreen 3.3 release update from dbwells: http://libmail.georgialibraries.org/pipermail/open-ils-general/2019-February/015605.html
15:30:34 <JBoyer> dbwells++
15:30:38 <dbwells> gmcharlt++ # thanks
15:30:41 <stephengwills> lol dbwells++
15:30:46 <abowling> dbwells++
15:30:52 <Dyrcona> dbwells++
15:30:56 <gmcharlt> quick, somebody come up with a question that will take dbwells 15 minutes to answer!
15:30:56 <jeff> dbwells++
15:31:04 <gmcharlt> (seriously, any questions for him before we move on?)
15:31:18 <berick> i have a question..
15:31:21 <berick> (just in time)
15:31:39 <berick> generally for 3.3, any plans to furhter excise XUL bits?
15:31:55 <berick> or do we retain status quo for a bit
15:32:14 <gmcharlt> I for one don't have time to do anything comprehensive dissection
15:33:13 <dbwells> If folks are generally amenable to more removal, I can throw some tuits that way.
15:33:51 <gmcharlt> I'm in support of that
15:34:02 <csharp> +1 to de-XUL-ification
15:34:12 <berick> no strong preference, but will be good to reach some consensus there, since XUL is technically usable in 3.2.  Is 3.3 where it fully stops working, i guess is the question.
15:34:12 <JBoyer> +1
15:34:19 * csharp is happy to help (at least with testing)
15:34:42 <Dyrcona> Did we ever set a release for removal of XUL?
15:34:48 <csharp> PINES is running 3.2 without XUL (so far) - I think that's a good indicator that we can leave it behind
15:34:51 * Dyrcona doesn't remember.
15:35:32 <berick> Dyrcona: iirc, 3.2 was the last xul milestone discussed
15:36:38 <dbwells> I believe the push was to defeat all webstaffblocker bugs before conceding to removal.  There are just three such bugs at the moment, so that seems doable.
15:36:44 <gmcharlt> yeah, that matches my memory
15:37:37 <sandbergja> I have another 3.3 question: according to this, all new UIs should be in Angular as of 3.3: https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angjs_to_ang_migration#migration_timeline_proposal
15:38:08 <sandbergja> Is that still the case?
15:38:28 <sandbergja> And more specifically, should I rewrite this in Angular: https://bugs.launchpad.net/evergreen/+bug/1790727
15:38:28 <pinesol> Launchpad bug 1790727 in Evergreen "New feature: add a daily schedule view of existing bookings" [Wishlist,New]
15:38:47 <berick> sandbergja: that's not the case
15:38:49 <berick> well, wait
15:38:54 * berick re-reads
15:39:25 <berick> sandbergja: sorry, i read that as /all/ UI's...
15:39:43 <berick> i do think new UI's should be implemented in Angular if it's reasonable to do so.
15:39:55 <miker> (re Angular, berick, I plan to have your Server Admin page in place RSN, so that I can stay true to "new UIs in Angular7")
15:40:04 <jeffdavis> sandbergja: how big of a burden would it be for you to reimplement?
15:40:05 <miker> s/page/branch
15:40:32 <berick> miker++
15:40:45 <sandbergja> jeffdavis: not sure yet; I'll do some exploration this afternoon
15:41:01 <jeffdavis> Sitka was hoping to test the bookings daily schedule this week and looking forward to having it in 3.3
15:41:13 <berick> i'd say at this stage there's some flexibility
15:41:19 <berick> i mean if the code is already written...
15:41:34 <sandbergja> yeah, I just barely missed 3.2 :-(
15:41:38 <gmcharlt> agreeded - especially since it's a relatively small (codewise) addition to an existing AngularJS app
15:42:50 <sandbergja> Okay, I'll plan to keep that targeted for 3.3 then, but still do some exploration about re-implementing in Angular, since it will have to happen eventually anyway
15:42:58 <gmcharlt> sandbergja++
15:42:59 <sandbergja> If that works for y'all
15:43:13 <dbwells> sandbergja: You have two weeks, I don't see the problem ;)  No, I agree that this seems fine :)
15:43:13 <JBoyer> sandbergja++
15:43:13 <berick> +1
15:43:20 <berick> heh
15:43:25 <gmcharlt> looing at the webstaffblocker bugs, they have active branches, so I think it would be reasonable to paln that all three will be fixed by the release of 3.3.0
15:43:59 <gmcharlt> so back to the original question... I think we can be free to taken up dbwells' offer of tuits to disable more of XUL
15:44:03 <gmcharlt> *to take up
15:44:14 <gmcharlt> any objections?
15:44:22 <dbwells> gmcharlt: sounds good!
15:45:02 <Dyrcona> No objection from me.
15:45:02 <gmcharlt> so
15:45:43 <gmcharlt> #agreed we're amenable to XUL removal continuing in for 3.3 to a degree that it may no longer be an option for use
15:45:54 <gmcharlt> #action dbwells will contribute time to XUL removal prior to release
15:46:05 * berick pours some Scotch on the ground
15:46:17 <gmcharlt> so moving on
15:46:18 <gmcharlt> #topioc Hatch
15:46:27 <gmcharlt> #info Hatch version 0.2.0 released including Firefox support released.
15:46:36 <gmcharlt> anything else to say about Hatch that wasn't already?
15:46:53 <berick> nothing from me
15:46:56 <JBoyer> Nothing from me.
15:47:31 <gmcharlt> ok
15:47:33 <gmcharlt> on to new business
15:47:36 <gmcharlt> #topic Should we remove Java libs from OpenSRF and Evergreen?
15:48:13 <Dyrcona> Seeing as Java no longer builds, I say yes.
15:48:27 <berick> both are way behind w/ recent osrf changes
15:48:41 <gmcharlt> are there any known uses of that code?
15:48:42 <jeffdavis> Is it worth polling the broader EG community (via the mailing lists I guess) to see if anyone is still using them somehow?
15:48:55 <berick> jeffdavis: i'd say yet
15:48:57 <berick> er, yes
15:49:17 <gmcharlt> yeah, it is at least a good courtesy
15:49:40 <gmcharlt> (and there's always the chance, however unlikely, that somebody has been maintaining a Java binding quietly who might speak up)
15:49:57 <JBoyer> It would be good to emphasize that they're going away unless someone wants to take a more active role in their maintenance.
15:50:17 * Dyrcona agrees with JBoyer.
15:50:24 * gmcharlt has no objection to framing it that way
15:50:53 <gmcharlt> (it would be a 3.2.x thing, though)
15:51:02 * abowling is thinking of the judge in My Cousin Vinny to anyone who wants to keep it: That is a lucid, intelligent, well-thought out objection...Thank you, your honor...Overruled
15:51:19 <gmcharlt> Dyrcona: shall you send out such a notification/query?
15:51:36 <Dyrcona> Sure!
15:51:49 <Dyrcona> Maybe not today, but by Friday at the latest.
15:52:11 <gmcharlt> #action Dyrcona will query the dev community to see if any users of OpenSRF's Java bindings are still out there?
15:52:15 <gmcharlt> moving on
15:52:19 <gmcharlt> #topic Should we update or remove Python libs from OpenSRF and Evergreen?
15:53:08 <Dyrcona> It's a different situation from Java, in that it builds and srfsh.py works on Ubuntu 18.04, but not Ubuntu 16.04, and IIRC, Syrup uses it, but Syrup is abandonware.
15:53:52 <Dyrcona> I haven't tested it on Debian since Debian 7, so I don't know if Python works on Stretch or Jessie.
15:53:56 <stephengwills> I just used marc_convert.py for an on-boarding last week.  Does that require any Osrf or Eg libs?  or is it stand alone?
15:54:37 <Dyrcona> And, then, there's another wrinkle. Our Python libs are version 2.7 compatible, and Python 2.7 is EOL on Jan 1, 2020.
15:54:59 <berick> i'm pretty sure it's not 100% with perl/c osrf, but I also have not looked at it in a long time
15:55:10 <berick> 100% compatible, i mean
15:55:11 <Dyrcona> stephengwills: Did you configure OpenSRF and Evergreen with --enable-python?
15:55:34 <gmcharlt> my inclination there would be to  also do a community query, but maybe frame this one as being (initially) a call for a Python maintainer
15:56:35 <JBoyer> I'm +1 to that. "Happens to work in certain versions of certain OSes" is a pretty rough claim to support.
15:57:05 <gmcharlt> if folks are amenable, I can save Dyrcona some effort and make that query
15:57:07 <miker> berick: I'm nearly 100% sure it's not, currently, for some message types. fwiw
15:57:22 <berick> miker: yeah...
15:57:28 <gmcharlt> (and perhaps help Dyrcona avoid coming off as the sole chopper-of-bindings ;) )
15:57:33 <Dyrcona> :)
15:57:35 <miker> chunking, bundling, and now 503
15:57:40 <gmcharlt> yeah
15:58:06 <gmcharlt> I'll run with that
15:58:11 <Dyrcona> Well, if we keep Python, I'd suggest we update the code to be Python 3.x (which is much easier than it sounds) and keep it up to date with latest changes.
15:58:43 <gmcharlt> #action gmcharlt will send query about (a) whether there are any active users of Evergreen's Python bindings and (b) volunteers to help maintain it and ideally upgrade to 3.x
15:58:55 <gmcharlt> so moving on
15:59:03 <gmcharlt> #topic Miscellenaous
15:59:05 <gmcharlt> #info Beware update to Angular 7 requires npm update (or rm -rf node_modules; npm install) in Open-ILS/src/eg2
15:59:14 <gmcharlt> berick: anything more to say about that?
16:00:05 <berick> just wanted to give a heads up
16:00:24 <gmcharlt> berick++
16:00:32 <Dyrcona> berick++
16:00:42 <gmcharlt> next up - doing a poll to see if a new standing time for the dev meeting would work better for folks
16:00:50 * Dyrcona wants to look at more of the Angular bugs.
16:01:03 <gmcharlt> it's been a while since the question was asked... so who wants to run the poll?
16:01:40 <remingtron> I'll do it!
16:01:47 <gmcharlt> remingtron++
16:02:06 <gmcharlt> #action remingtron will run poll to see if a new standing day/time for the dev meeting would be better
16:02:18 <gmcharlt> #info Hope to get some movement on bug 1811288 since it will impact most of the active Angular dev branches.
16:02:18 <pinesol> Launchpad bug 1811288 in Evergreen "Angular Fieldmapper Editor should use combobox for linked fields" [Medium,New] https://launchpad.net/bugs/1811288
16:02:43 <gmcharlt> berick: regarding that, both phasefx_ and I have need to poke at the new combobox anyway, so we can offer tuits
16:03:08 <berick> gmcharlt++
16:03:17 <berick> great, holler if I can help
16:03:32 <JBoyer> That branch just puts it in the sandbox initially, yes?
16:03:53 <berick> it goes into the fm-editor which is used in lots of places
16:03:57 <miker> also for berick, but for later (just planting the seed), I'd like to talk about being able to pass initial filters to admin (local and server) pages, for linked dependent config (if that makes sense)
16:04:03 <berick> + a sandbox example of a certain type of use
16:04:18 <gmcharlt> so... we have 7.5 more seconds
16:04:19 <JBoyer> Ah, good.
16:04:22 <gmcharlt> any last-second topics?
16:04:33 <berick> miker: sounds good
16:04:51 <gmcharlt> ok, thanks folks!
16:04:53 <gmcharlt> #endmeeting