15:01:39 <gmcharlt> #startmeeting Development meeting, 6 June 2018
15:01:39 <pinesol_green> Meeting started Wed Jun  6 15:01:39 2018 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:39 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:39 <pinesol_green> The meeting name has been set to 'development_meeting__6_june_2018'
15:01:49 <gmcharlt> #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-06-06
15:02:01 <gmcharlt> #topic Introductions
15:02:07 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
15:02:15 <csharp> #info csharp = Chris Sharp, GPLS
15:02:40 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Coop
15:02:44 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
15:02:51 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:02:57 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:02:59 <berick> #info berick = Bill Erickson, KCLS
15:03:18 <abneiman> #info abneiman = Andrea Neiman, EOLI
15:05:08 <JBoyer> #info JBoyer = Jason Boyer, IN State Library
15:05:44 <miker> #info miker = Mike Rylander, EOLI
15:05:50 <gmcharlt> groovy
15:05:55 <gmcharlt> #tpic Action Items from Last Meeting
15:06:06 <gmcharlt> #item OpenSRF 3.0.1 was released
15:06:19 <gmcharlt> #item gmcharlt did indeed write that blog post announcing 3.1.0
15:06:38 <gmcharlt> #item gmcharlt did indeed put out a call for 3.2 RM
15:06:51 <gmcharlt> (... and then proceeded to VERY SNEAKILY dig a pit underneath berick)
15:07:02 <gmcharlt> #action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF
15:07:08 <JBoyer> There's a release manager in my tiger pit!
15:07:11 <berick> heh
15:07:22 <gmcharlt> any questions on those points?
15:08:28 <gmcharlt> ok, moving on
15:08:35 <gmcharlt> #topic OpenSRF release info
15:08:42 <gmcharlt> #item OpenSRF 3.0.1 released
15:08:53 <gmcharlt> hmm
15:08:59 <gmcharlt> #info OpenSRF 3.0.1 released
15:09:06 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:09:12 <kmlussier> comcast--
15:09:26 <csharp> comcast--
15:09:27 <gmcharlt> anyway, I think the additinal work on the websockets code looks like it will warrant a 3.0.2 release later this month
15:09:34 <miker> comcast-- # that one's for akilsdonk
15:09:51 <JBoyer> The chunking/bundling changes?
15:10:10 <miker> JBoyer: I think that's all on the evergreen side, if you mean csharp's work
15:10:28 <gmcharlt> yeah, I was thinking more of bug 1774703
15:10:28 <pinesol_green> Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703
15:10:41 <JBoyer> Ah, yes.
15:10:46 <Dyrcona> charter--
15:11:27 * Dyrcona forgot about the meeting....
15:11:28 <gmcharlt> not that 1725317 isn't also a concern... but I think that has the potential to turn into something that warrants a /3.1.0/, as fixing it for real would entail updating some client javascript code
15:11:40 <Dyrcona> #info Dyrcona is Jason Stephenson CW MARS
15:12:08 <Dyrcona> On the topic at hand, I am testing that fix in production starting tonight.
15:12:20 <gmcharlt> Dyrcona++
15:12:35 <gmcharlt> and also things like bug 1729610 might call for a 3.1
15:12:36 <pinesol_green> Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610
15:12:58 <JBoyer> +1
15:13:02 <gmcharlt> and bug 1626139 definitely would
15:13:02 <pinesol_green> Launchpad bug 1626139 in OpenSRF "Deprecate OSRFGatewayLegacyJSON (/gateway)" [Low,Confirmed] https://launchpad.net/bugs/1626139
15:13:35 <gmcharlt> so, the more that I'm thinking about it, the more I think I'm talking myself into planning a 3.1.x series sooner rather than later
15:13:56 <gmcharlt> possible as a minimum required version for 3.2
15:14:06 <gmcharlt> soooo.... berick in particular, thoughts on that?
15:14:22 <gmcharlt> and are there other OpenSRF things you would particularly want for Evergreen 3.2?
15:14:33 <berick> those all sound good to me
15:15:22 <JBoyer> Where are we on the Plain/SASL deprecation timeline for ejabberd?
15:15:53 <berick> good question
15:15:55 * csharp is curious about that too
15:15:58 <JBoyer> (Not to throw another log on the pile, but it also seems worthy of a X.y+1)
15:16:03 <Dyrcona> Well, we (i.e. bshum and I) have not gotten OpenSRF to communicate with ejabberd on Ubuntu 18.04, yet.
15:16:08 <csharp> right
15:16:18 <gmcharlt> JBoyer: yeah, I think the question is whether to make it a goal for 3.1.x
15:16:28 <gmcharlt> ... which I think is at least reasonable to try for
15:17:22 <gmcharlt> ok
15:17:26 <miker> anyone want to volunteer to look for (at least) perl and C libs to leverage, either that hand the caller a socket (ideally) or manage the SASL stuff for us given a socket?
15:17:30 <csharp> I think 18.04 support is a reasonable goal for the next release, but I know there are higher priorities
15:18:01 <gmcharlt> #action gmcharlt will do a bugfix release of OpenSRF 3.0.2, particularly upon successful testing of bug 1774703
15:18:02 <pinesol_green> Launchpad bug 1774703 in OpenSRF "Websockets processes locked at 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/1774703
15:18:03 <miker> (and, can we target a version of ejabberd, rather than a disto release?
15:18:13 <gmcharlt> #action gmcharlt will put out a call for roadmap entries for OpenSRF 3.1.0
15:18:26 <csharp> miker: yeah, was just looking to see what's going on with Debian
15:18:48 <gmcharlt> yeah, all other things being equal, targetting an ejabberd version level seems better
15:19:17 <gmcharlt> ok, moving on
15:19:22 <gmcharlt> #topic Evergreen release update
15:19:27 <gmcharlt> berick: you have the floor
15:19:48 <berick> k...
15:19:55 <berick> first off, quick reminder of https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.2
15:20:12 <berick> if there are any other big ticket items, will be good to have them in the list
15:21:05 <berick> early in the cycle, so I don't have much else to report on 3.2 at the moment.  happy to field questions, though
15:22:41 <gmcharlt> berick: one thing I'm kinda hoping for is the Angular stuff to get in sooner rather than later
15:23:18 <berick> hey, that segues nicely into my next agenda item ;)
15:23:49 <gmcharlt> heh
15:24:25 <berick> one final 3.2. thing before we move on, thanks for all the work on these, and keep up the awesome work:  https://bugs.launchpad.net/evergreen/+bugs?field.tag=webstaffblocker
15:25:29 <berick> so the Angular stuff...
15:25:51 <berick> i'm hoping everyone had a chance to glance at https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angjs_to_ang_migration#migration_strategy_proposal
15:25:58 <berick> i know we talked about it some in IRC already
15:26:39 <berick> i'm looking to get input both on the dev plan and the timing
15:26:47 <berick> becuase it will impact 3.2.
15:26:53 <berick> if nothing else, how we allocate resources
15:27:23 <gmcharlt> one comment regarding the timing: I feel like we should try to get /something/ visible (other than just the navbar) present in 3.2 as a Angular app
15:27:57 <miker> question:
15:28:22 <gmcharlt> even if it's nothing more than just a minor egrid-based admin interface page
15:28:35 <miker> is template /nesting/ possible in angular6? a la base.tt2, so we don't have to repeat ourselves for wrappers?
15:28:45 <csharp> *cough* Library Settings Editor
15:28:50 <berick> gmcharlt: as it stands, I have ported quite a few admin UI's already.
15:29:03 <gmcharlt> berick: ah, OK
15:29:12 <JBoyer> The staff opac would certainly be something and the fact that F-key shortcuts would always work would stop any complaints about functionality cold. (at some of our libs, anyway)
15:29:35 * csharp thought of the staff OPAC too
15:29:50 <berick> and I'm also in favor of earlier deployment -- i didn't want to be pushy in my timelines :)
15:30:36 <gmcharlt> we'd also want to be sure that we're exposing strings for translation
15:30:45 <berick> miker: it's certainly possible to have components that load other components within them
15:31:08 <berick> miker: not sure if that exactly answers your question, but if you give me a specific example, I could probably scetch something out
15:31:38 <berick> JBoyer: the staff opac would be a pretty tall order for 3.2 unless we make it a big priority
15:31:43 <miker> berick: my hope is that we can avoid having to touch a bunch of files when, say, we add an attribute to a component
15:31:55 <berick> there's still a lot of work to do on the staff opac
15:32:28 <berick> for 3.2 i'm thinking navbar and a nice set of admin UI's is a good target
15:32:35 <JBoyer> I wasn't sure how far complete it was, having only poked at it a little bit on your demo server. I'd probably prioritize ditching dojo ahead of that then.
15:32:50 <csharp> +1 to ditching dojo
15:32:52 <gmcharlt> berick: (and the batch OPAC actions project would add another functional point to be reimplemented in an Angular staff OPAC - namely, multi-select of records from search results)
15:33:06 <berick> *nods*
15:34:38 <berick> BTW I occasionally add notes to https://wiki.evergreen-ils.org/doku.php?id=dev:browser_staff:angjs_to_ang_migration#notes
15:34:57 * berick has more notes to add for today
15:35:07 <csharp> berick++
15:35:19 <dbwells> berick++
15:36:06 <berick> how can I better expose what I'm working on?  do we need a temporary repository?  should I migrate my branch to a collab branch?
15:36:34 <csharp> gitlab!
15:36:42 <berick> it does take a little getting used to, so I'd like to avoid as many surprises as possible
15:37:21 * csharp plans to install berick's branch on his test/dev server this week
15:37:32 <berick> csharp: cool, holler if I can help
15:37:40 <csharp> will do
15:37:47 <gmcharlt> berick: +1 to a collab branch
15:37:50 <JBoyer> A collab branch sounds good
15:37:56 <csharp> agreed
15:38:05 <berick> sounds good.  I'll open a LP for that too
15:38:06 <gmcharlt> berick: and would it be useful to call a special IRC meeting?
15:38:26 <gmcharlt> or a webinar from which you could do a show-and-tell?
15:38:34 <Dyrcona> csharp: I tried upgrading node on an existing vm and got nothing but errors afterward.
15:39:00 <Dyrcona> This was related to testing the ang6 branch. I have not had time to go back and try again.
15:39:11 <csharp> Dyrcona: ah - good to know
15:39:23 <berick> gmcharlt: i would be happy to participate
15:39:28 <gmcharlt> ok
15:39:30 <berick> whatever works best for everyone
15:39:54 <gmcharlt> #action gmcharlt to work with berick to see about setting up some kind of presentation/meeting to discuss angular
15:40:20 <gmcharlt> in the interest of time, any other Evergreen topics to discuss not otherwise on the agenda?
15:40:21 * miker suspects he can guess the main hack-a-way activity
15:40:29 <berick> :)
15:40:49 <gmcharlt> miker: we should tell rhamby to book the CIRCULAR room, natch ;)
15:40:58 <JBoyer> "You can have lunch AFTER the OU Editor is written in Ang6!"
15:40:59 <miker> heh
15:41:12 <csharp> wowsers - 73 commits so far in the ang6 branch
15:41:19 <gmcharlt> ok, so moving on
15:41:22 <gmcharlt> #topic Hatch update
15:41:24 <rhamby> gmcharlt: I'll see what we can do :)
15:41:44 <gmcharlt> rhamby++
15:42:15 <berick> Hatch will be affected by the Feedback agenda item below
15:42:32 <berick> i'm not aware of any major Hatch changes since the last meeting though
15:42:42 <berick> IIRC, the Dymo issue is still pending
15:42:42 <gmcharlt> any news on the Firefox addon?
15:42:47 <JBoyer> Firefox support was kind of a hassle...
15:42:59 <JBoyer> Did I not pullrequest it? It's done.
15:43:05 <gmcharlt> ah, cool
15:43:14 <berick> JBoyer: oh, cool, i missed that
15:43:15 * csharp still hasn't arranged a good environment to test JBoyer's branch on Windows
15:43:41 <gmcharlt> #info the Firefox add-on for Hatch is available
15:43:42 <JBoyer> Not merged and not updated, but I've seen the printer list in both browsers simultaneously.
15:43:54 <JBoyer> updated -> uploaded.
15:44:19 <csharp> JBoyer: I have credentials to the FF addons site, FYI
15:44:57 <JBoyer> I thought you could upload the updated version once you're satisfied it's working, unless you'd rather I do it.
15:45:06 <csharp> JBoyer: can do
15:45:27 <gmcharlt> what's the relevant bug for that change?
15:45:48 <csharp> bug 1731922
15:45:49 <pinesol_green> Launchpad bug 1731922 in Evergreen "Firefox add-on for Hatch" [Wishlist,Confirmed] https://launchpad.net/bugs/1731922
15:46:02 <JBoyer> csharp++
15:46:22 <gmcharlt> #action csharp will upload an update for the Hatch FF add-on
15:46:34 <gmcharlt> so, moving on
15:46:44 <gmcharlt> I think we discuss the Angular migratio plan sufficiently?
15:46:49 <gmcharlt> so...
15:47:01 <gmcharlt> #topic New business - What form will XUL deprecation take in 3.2? Are we removing the code?
15:47:14 <berick> another one I added
15:47:19 <berick> just want to get sense of the scope
15:47:38 <JBoyer> I was under the impression that deprecation started at 3.0 and 3.2 was the drop dead date.
15:47:42 <berick> and if we need a XUL Removal Tzar
15:47:44 <JBoyer> re, release.
15:47:55 <gmcharlt> I think we should plan on removing it entirely
15:48:10 <dbwells> +1 to gutting it
15:48:11 <gmcharlt> or at least go through the effort of ensuring that it works without it
15:48:30 <gmcharlt> and unless somebody else wants to start it, I'm happy to start a XUL removal branch
15:48:49 <berick> gmcharlt++
15:49:07 <JBoyer> gmcharlt++
15:49:14 <miker> note: there are some things that live under xul/server/ that are used in the web staff client, IIRC ... because they're actually html
15:49:26 <gmcharlt> miker: indeed - exactly the sort of issue to flush out
15:49:28 <berick> gmcharlt: one word of caution, and this plays nicely with the Angular / admin UI stuff -- there's a smattering of html UI's in the XUL directory ...
15:49:32 <csharp> our catalogers are still on XUL and we'll need things like the omnibus bug done before our folks will even consider moving off it
15:49:33 <berick> jinx
15:49:35 <miker> do we risk moving those, or just leave out xulrunner
15:50:16 <gmcharlt> miker: I think a full removal should be the goal, with removing just the bits that build the XUL client as a fallback
15:50:25 <miker> if the latter, it would be possible, in theory, for PINES to keep using the xul client with appropriate symlinks
15:50:26 <Bmagic_> Anyone know anything about AstCall.pm, specifically RPC::XML::Client and UDP? It looks like the Astericks server on the other end is configured for UDP and from what I can gather, the Evergreen server is talking on TCP.
15:50:34 <miker> ok
15:50:40 <Bmagic_> Ooops, meeting
15:51:03 <berick> if the number of mixed-in UI's is low enough, we could make those the UI's that should be ported first to Angular
15:51:11 <kmlussier_> +1 to full removal being the goal
15:51:21 <JBoyer> That's a good plan
15:51:23 <kmlussier> also, comcast--
15:52:02 <gmcharlt> csharp: and I think we can meet in the middle - i.e., if we fail to make it w/o webstaff blockers, I'll aim to design the XUL removal so that it can be readily reverted
15:52:15 <csharp> gmcharlt: works for me
15:52:43 <gmcharlt> but in any event, given general support (and funding) for fixing those blockers, I'm fairly optimistic that those bugs will be squashed in time for 3.2
15:52:51 <Dyrcona> Should we remove it if there are still webstaff blockers, though?
15:52:52 <gmcharlt> and that many of those fixes will make it to 3.1.x
15:53:07 <kmlussier> I don't think we should release 3.2 with the webstaff blockers.
15:53:09 <csharp> terran and I were just discussing yesterday that we'd like to have a webstaff-only upgrade in January with the XUL client quietly in reserve just in case
15:53:36 <gmcharlt> Dyrcona: I think we should be living on a master with XUL removed sooner rather than later, at least during the dev runup to 3.2
15:54:17 <csharp> btw, despite my concerns about timing and being able to revert, I'm totally on board with full removal as soon as possible
15:54:29 <Dyrcona> Well, that's an incentive to fix the bugs. :)
15:54:39 <berick> burn the ships :)
15:55:05 <Dyrcona> Actually, if you leave the files in /openils/var/web/xul. There's not thing stopping a site from continuing to use XUL.
15:55:38 <terran> My concern is that until our catalogers are able to get past this first set of webstaff blockers and use the web client fully, we won't know if there are other blockers we haven't discovered yet.
15:55:44 <gmcharlt> berick: just call me Hector ;)
15:56:04 <terran> But yes, I'm also eager to get everyone moved over to the web client
15:56:39 <berick> re: using old XUL files..  there's also the concern that webstaff code could break XUL functionality -- just having the files is not a guarantee XUL will work completely
15:57:33 <berick> we've avoided that through 3.1
15:57:34 <JBoyer> That's already started. there's a bug someone here needs to file to that very effect. copy alert matrix unhappiness with the xul quick item add...
15:57:47 <berick> but I think the gloves are off now
15:57:48 <JBoyer> (Il'l write it up later)
15:57:58 <berick> ah
15:58:38 <rjackson_isl> JBoyer: https://bugs.launchpad.net/evergreen/+bug/1775240
15:58:39 <pinesol_green> Launchpad bug 1775240 in Evergreen "Fast Item Add Fails from Legacy Staff Client after Latest Upgrade " [Undecided,New]
15:58:48 <Dyrcona> My understanding is that new copy alerts are not supposed to work in xul, but yeah.
15:58:50 <JBoyer> Hey, look at me forgetting.
15:58:54 <JBoyer> rjackson_isl++
15:59:09 * Dyrcona rushes off to set it Won't Fix. :P
15:59:20 <JBoyer> Maybe read it first, ;p
15:59:36 <Dyrcona> TL;DR.
15:59:43 <kmlussier> But it shouldn't prevent you from adding a copy in xul.
15:59:57 <berick> in <= 3.1 anyway
16:00:18 <gmcharlt> anyway, need to move on in the agenda
16:00:20 * csharp has to jet but will read scrollback
16:00:34 <gmcharlt> #topic Bug #1750894
16:00:34 <pinesol_green> Launchpad bug 1750894 in Evergreen "Wishlist: Store web staff workstation settings on the server" [Wishlist,New] https://launchpad.net/bugs/1750894
16:00:55 <berick> big-ish change, hoping to merge sooner than later.  it also impacts the Angular stuff pretty heavily
16:00:55 <miker> I'll put some eyeball time on the server-settings branch
16:01:10 <berick> thanks miker
16:02:00 <gmcharlt> ok
16:02:02 <gmcharlt> finally
16:02:06 <gmcharlt> #topic Next meeting
16:02:25 <gmcharlt> the auto-schedule for the next dev meeting puts it on a US holiday, 4 July
16:02:30 <gmcharlt> shall we move it to 11 July?
16:02:42 <miker> +1
16:02:43 <berick> +1
16:02:48 <JBoyer> +1
16:02:49 <Dyrcona> +1
16:03:05 <Bmagic> +1
16:03:13 <kmlussier> +1
16:04:03 <gmcharlt> #agreed Next dev meeting will be held on 11 July
16:04:06 <gmcharlt> thanks, folks!
16:04:08 <gmcharlt> #endmeeting