15:00:30 <gmcharlt> #startmeeting Evergreen Development meeting, 2 August 2017
15:00:30 <pinesol_green> Meeting started Wed Aug  2 15:00:30 2017 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:30 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:30 <pinesol_green> The meeting name has been set to 'evergreen_development_meeting__2_august_2017'
15:00:38 <gmcharlt> #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2017-08-02
15:00:42 <gmcharlt> #topic Introductions
15:00:46 <gmcharlt> please introduce yourselves
15:00:50 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:00:53 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox, RM
15:01:01 <DPearl> #info DPearl = Dan Pearl, C/W MARS Inc.
15:01:04 <phasefx> #info phasefx = Jason Etheridge, Equinox
15:01:20 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin Collge)
15:01:31 <JBoyer> #info JBoyer = Jason Boyer, IN State Library
15:01:35 <Dyrcona> #info Dyrcona = Jason Stephenson, C/W MARS Inc.
15:02:14 <jeffdavis> #info jeffdavis = Jeff Davis, Sitka
15:02:19 <abowling> #info abowling = Adam Bowling, Emerald Data Networks
15:02:22 <berick> #info berick Bill Erickson, KCLS
15:02:32 <cesardv> #info cesardv = Cesar Velez, Equinox
15:02:59 <rhamby> #info, rhamby = Rogan Hamby, Equinox Open Library Initiative
15:03:46 <gmcharlt> so, moving
15:03:50 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
15:03:54 <gmcharlt> #topic Past action items
15:04:32 <gmcharlt> JBoyer: from the last meeting you had an item to write up the open-ils.search backends disapearing issue
15:05:00 <gmcharlt> and at least one part of it was identified as being due to the misspelled signal name
15:05:32 <JBoyer> Let me find the LP number, but I believe most of it was actually running out of file descriptors for ejabberd.
15:05:34 <gmcharlt> but a general question - is there more to it?
15:06:24 <JBoyer> ah, it was bug 1697029
15:06:24 <pinesol_green> Launchpad bug 1697029 in OpenSRF "Service Listeners Crash when Using an Undefined Value for Syscalls" [High,New] https://launchpad.net/bugs/1697029
15:06:55 <Dyrcona> Oh, yeah a failure to fork, right?
15:08:13 <gmcharlt> ok, then it sounds like it's worth split that bug up a bit
15:08:13 <JBoyer> No, children would fork but then be gone as they were pulled from the idle list to take requests. It turned out ejabberd was ignoring their attempts to login and sometimes their giving up and dying was hitting just between being chosen to recieve a message and actually sending it.
15:08:19 <abowling> wasn't that a movie with matthew mcconaughey and sarah jessica parker?
15:08:26 <gmcharlt> - SIGARLM
15:08:37 <gmcharlt> - documenting file descriptor limits during installation
15:08:56 <gmcharlt> - documenting removing shapers during installation
15:09:12 <gmcharlt> have I got it?
15:09:19 <JBoyer> Yeah; my SIGALRM patch was only to silence log entries related to retrieving facets.
15:10:06 <jeffdavis> Bill's patch also prevents the service from dying when the issue arises.
15:10:27 <JBoyer> I would consider 2 and 3 to go hand-in-hand (these are all of the things you should do to ejabberd...) so that is all that likely needs to be addressed further since the SIGALRM patch has already gone in.
15:11:01 <jeffdavis> So we might want to consider pushing that patch to master. Not a separate issue per se but wouldn't want to lose track of that.
15:11:29 <gmcharlt> berick: so, would you take an action item to clean up that patch for submission?
15:11:51 <gmcharlt> I can deal with the documentation issues (and this is all leading on the the next topic in the agenda, it looks like)
15:11:59 <berick> gmcharlt: yep.  pushing back to same bug?
15:12:11 <gmcharlt> berick: yeah
15:12:14 <berick> k
15:12:31 <gmcharlt> #action berick will tidy up his patch for bug 1697029 and mark it for submission
15:12:31 <pinesol_green> Launchpad bug 1697029 in OpenSRF "Service Listeners Crash when Using an Undefined Value for Syscalls" [High,New] https://launchpad.net/bugs/1697029
15:12:36 <JBoyer> berick++
15:12:50 <gmcharlt> #action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF
15:13:02 <gmcharlt> so, rolling into the next topic
15:13:06 <gmcharlt> #topic OpenSRF release
15:13:54 <gmcharlt> so, in addition to what we just discussed, bug 1702978 strikes me as another good thing to merge in for 2.5.1
15:13:54 <pinesol_green> Launchpad bug 1702978 in OpenSRF "memcache keys containing % fail" [High,Confirmed] https://launchpad.net/bugs/1702978
15:14:18 <gmcharlt> any other high priorities for that maintenance release?
15:14:35 <gmcharlt> also, I wanted to raise something I mentioned in the comments for that bug
15:15:02 <gmcharlt> namely, I'd like to propose a convention that minor releases of OpenSRF will never change the C ABI
15:15:20 <gmcharlt> (unless absolutely necessary to deal with a security issue)
15:15:42 <Dyrcona> Question: What a minor relase? x.y or x.y.z?
15:15:48 <miker> #info miker = Mike Rylander, EOLI (doh!)
15:16:19 <gmcharlt> that would mean that for minor upgrades, it would be sufficient to recompile and reinstall OpenSRF and restart services, but dependent software (like Evergreen) wouldn't need to be recompiled
15:16:24 <gmcharlt> Dyrcona: I'm thinking x.y.z
15:17:00 <Dyrcona> OK. Thanks.
15:18:55 <miker> gmcharlt: fwiw, +1 to your proposal as a rule
15:19:10 <Dyrcona> Yes, I agree. +1
15:19:27 <gmcharlt> cool; I'll also raise it on open-ils-dev
15:19:44 <berick> +1
15:19:54 <gmcharlt> so, moving on
15:19:59 <gmcharlt> #topic Evergreen releases
15:20:18 <gmcharlt> #info Evergreen 2.11.7 and 2.12.4 released on 28 July
15:20:20 <gmcharlt> kmlussier+
15:20:22 <gmcharlt> kmlussier++
15:20:24 <gmcharlt> dbwells++
15:20:28 <gmcharlt> Bmagic++
15:20:49 <gmcharlt> #info Second feedback fest will run from 7 to 11 August
15:21:08 <gmcharlt> #action gmcharlt will send out the list of pull requests (for recordkeeping purposes) on Friday
15:21:27 <gmcharlt> also, if folks have suggestions for improving the feedback fest process, please speak up
15:22:13 <gmcharlt> #info Reminder - feature slush is 18 August. Slush means that major enhancements should at least have a plausible pull request in place by that date
15:22:25 <kmlussier> I'm having trouble remembering the process, but I think it went well last time.
15:23:05 <gmcharlt> #nfo Reminder - feature freeze and string slush is 1 September
15:23:25 <miker> kmlussier: I think of it as a bug squashing week for new features (wishlist bugs on LP)
15:23:44 <gmcharlt> and anything that has a pull request, really
15:24:35 <gmcharlt> there are already a set of big pull requests pending - eliminated staged search, webstaff offline circulation, patron batch edit
15:24:52 <gmcharlt> and a couple more coming down the pike this week, including the web staff serials branch
15:25:14 <gmcharlt> I think, generally speaking, master can be expected to be more than usually unstsable this month
15:26:13 <JBoyer> Exciting.
15:26:16 <gmcharlt> any other questions/comments regarding Evergreen releases?
15:26:28 <kmlussier> yes, I have a question about hatch in 3.0.
15:27:24 <kmlussier> Will users still need to do the current installation method for hatch in 3.0? Or are we planning to make it an official Chrome plug-in at some point.
15:27:59 <gmcharlt> kmlussier: good question! I'm hoping that we can get it into the Chrome app store by October
15:28:29 <kmlussier> Great! Thanks gmcharlt!
15:28:47 <gmcharlt> also, one of the things that's been in the back of my mind is putting out a proposal to, this month, add a service to Evergreen that can store workstation settings server-side
15:29:03 <JBoyer> It's still a 2-step process though, correct? The Chrome plugin and the native binary? Otr is there a way to bundle them together?
15:29:28 <gmcharlt> which would mean that the only function that would be relegated to Hatch is helping to mediate printing, at least in cases where browser printing simply won't work
15:30:00 <berick> JBoyer: still 2-step.  chrome store would make one of those steps much simpler.
15:30:08 <JBoyer> ++
15:30:25 <kmlussier> I like the idea of storing it all server side.
15:30:46 <berick> +1 from me too on server-side WS settings
15:30:48 <abneiman> +1 to server-side storage (from the peanut gallery)
15:30:59 <JBoyer> This is where I come in asking about how to determine what is a workstation setting vs a user setting.
15:30:59 <phasefx> +1
15:31:10 <JBoyer> (Also +1 to gmcharlt's idea)
15:31:36 <gmcharlt> JBoyer: that is an excellent question... that my proposal will TOTALLY SIDESTEP for now :)
15:31:46 <berick> can we pretty please call it cloud storage?
15:31:53 <JBoyer> Because cat templates as a workstation setting won't fly here, and I'm not up enough on Angular to get user settings to work in the web copy editor...
15:31:53 <gmcharlt> berick: no
15:32:01 <gmcharlt> berick: clouds cannot support ducks
15:32:10 <gmcharlt> ;)
15:32:18 <berick> :)
15:32:19 <JBoyer> HAh, berick++
15:32:56 <gmcharlt> JBoyer: specifically, what I'll propose will treat nearly everything that is currently stored in localStorage and/or Hatch associated with the workstation
15:33:07 <JBoyer> I'll throw out the strictest definition here and others can argue it later: If it isn't dependant on hardware, it's not dependant on the workstation. (i.e. printing is about it. Maybe sound,)
15:33:11 <gmcharlt> for the sake of getting something done quickly
15:33:34 <gmcharlt> but I'd agree that there are some things that are more about staff members preferences
15:33:44 <JBoyer> +1 to that, I'm just hoping that once they're moved over things can still be moved around.
15:33:55 <phasefx> and yet staff may want different work environments for different things
15:33:57 <gmcharlt> (but then you also get into the realm where some preferences a library might want to make enforceable policies)
15:34:16 <kmlussier> Yes, what phasefx just said.
15:34:34 <berick> gmcharlt: indeed.. column settings comes to mind
15:34:44 <JBoyer> This new service needn't be limited solely to workstation prefs then...
15:35:02 <gmcharlt> JBoyer: in the medium term, correct
15:35:19 <JBoyer> it could be a simplified API to workstation and user prefs, allowing us to stop using PCRUD for some of it.
15:35:52 <gmcharlt> yep, so that will make for a lively email thread, perhaps
15:35:54 <gmcharlt> but moving on...
15:36:00 <JBoyer> agreed, sorry.
15:36:11 <gmcharlt> #topic Project to investigate alternatives to Launchpad and Gitolite
15:37:48 <gmcharlt> not sure there's much to say at the moment
15:37:59 <Dyrcona> Gitlab seems like it would be a workable replacement for gitweb and gitolite.
15:38:06 <gmcharlt> but strikes me as something where we might have more breathing room to do it after 3.0 comes out?
15:38:17 * gmcharlt is also leaning towards GitLab
15:38:20 <Dyrcona> It would mean changes to repo structure.
15:39:35 <miker> Dyrcona: are those changes written down somewhere?
15:39:48 <miker> sorry if so and I missed it
15:40:07 <Dyrcona> miker: Not yet, but I think the big thing would be favoring user repos over user branches in a single, working repo.
15:40:34 <miker> Dyrcona: does it make "collab" branches harder, or just different?
15:41:06 <miker> like, do I have to give gmcharlt full perms to allow him to push to a branch of mine?
15:41:15 <miker> (SCARY!) ;)
15:41:20 <gmcharlt> BOO
15:41:41 <Dyrcona> You an do that with "group" or individual repos.
15:42:13 <cesardv> https://github.com/gitlabhq/gitlabhq/pull/3597 Fork Pull Requests work in Gitlab
15:42:26 <Bmagic> hey! I am here now
15:42:33 <Dyrcona> I don't think the user has much control over permissions on branches, but you can grant write access to repos.
15:42:34 <miker> would someone that's done some looking be willing to write (or at least seed) a doc on "how things would change"?
15:42:44 <Dyrcona> I can do that.
15:42:53 <miker> Dyrcona++
15:43:01 <Dyrcona> There are a few more things I want to look at anyway.
15:43:13 <gmcharlt> #action Dyrcona will write some doc on how workflows might change with a switch to GitLab
15:43:40 * csharp stumbles into the meeting
15:44:11 <gmcharlt> so, moving on to new business
15:44:31 <gmcharlt> #topic XUL client bug and backporting policy
15:44:51 <miker> gmcharlt: proposal: NOPE
15:44:53 <miker> :)
15:45:07 <gmcharlt> heh
15:45:29 * JBoyer would counter with "Nah"
15:45:51 <kmlussier> I added that topic because there have been a handful of fixes lately that only apply to the xul client. I want clear guidance on when we stop merging them.
15:45:58 <gmcharlt> or to qualify that a bit, my suggestion is that starting with the release of 3.0, XUL bugs will not get fixed unless (a) the problem is a security issue or (b) the problem is a clear data-destruction bug
15:45:59 <kmlussier> I think there's still one out the with a pullrequest.
15:46:37 <csharp> gmcharlt: +1 to your suggestion
15:46:39 <JBoyer> Business as usual until the official 3.0 release is a good idea.
15:46:39 <kmlussier> +1
15:46:50 <JBoyer> +a
15:46:55 <JBoyer> uh, +1
15:46:59 <miker> +1
15:47:01 <kmlussier> :)
15:47:12 <Dyrcona> +1
15:47:13 <remingtron> +1
15:47:14 <csharp> "oh, so we're doing letters now?"
15:47:21 <rhamby> +1
15:47:30 <gmcharlt> csharp: digits are just too... new
15:47:33 <Dyrcona> That's hex. JBoyer was trying to vote ten times. :)
15:47:36 <JBoyer> it's 1vant gard.
15:47:53 <cesardv> +1
15:47:55 <berick> to be clear, is that the same as no XUL merges allowed that don't meet a) and b) ?
15:48:11 <kmlussier> a or b
15:48:18 <berick> kmlussier: yes, thanks
15:48:54 <gmcharlt> berick: I am tempted to say yes, essentially for the sake of making it clear that we REALLY MEAN IT when we say that the XUL client is deprecated
15:49:38 <jeffdavis> I'm a bit hesitant about that change.
15:49:40 <miker> gmcharlt: how about, "a NEW security issue"
15:49:45 <JBoyer> It would also allow some older bugs to age out with an official WontFix status rather than a defacto one.
15:50:15 <jeffdavis> Just because we've been testing the web client and finding things that are showstoppers for us in 2.12ish. So making 3.0 the cutoff seems a bit short.
15:50:28 <berick> miker: heh, good point, "xul is old, needs update" ;)
15:50:47 <Dyrcona> "Xul's dead."
15:50:47 <gmcharlt> jeffdavis: yeah, those are things that need to be addressed, hopefully in time for 3.0.0
15:50:48 <miker> jeffdavis: have you been LP-ing them with a high priority?
15:51:19 <gmcharlt> and it's not like the 3.0.x XUL client will be intentionally borken
15:51:30 <miker> right
15:51:37 <kmlussier> Yeah, I was continue working on those web client issues, it would be good to identify those that are real showstoppers for folks so that we priortize them.
15:51:38 <miker> nor the 3.1
15:51:59 <kmlussier> Sorry, I can't do English today.
15:52:37 <jeffdavis> I can at least commit to ensuring that we report 'em and prioritize accordingly.
15:52:54 <miker> jeffdavis++
15:52:57 <gmcharlt> jeffdavis: that's very appreciated!
15:53:12 <miker> *cough*timezones*cough* ;)
15:53:18 <jeffdavis> ha :)
15:53:24 <kmlussier> I have a few I could see being set to high priority too.
15:54:09 <berick> so that's another question about xul getting broken.. some webstaff changes could potentially break XUL interfaces.  changes to embedded UI's being the main culprit.  at what point do we stop caring about those?
15:54:32 <miker> after 3.1, I think
15:54:46 <kmlussier> I was thinking 3.2, when we totally remove the xul client.
15:54:58 <berick> so do we add that as c) to gmcharlt's xul merge list requirements?
15:55:14 <miker> kmlussier: right, that's what I mean. don't break xul in 3.0 or 3.1
15:55:19 <gmcharlt> berick:  yes
15:55:39 <gmcharlt> #action gmcharlt will send a proposed XUL patch policy to open-ils-dev for feedback
15:55:40 <kmlussier> miker: Ah, ok. I'm in total agreement with you then.
15:56:10 <gmcharlt> moving on
15:56:25 <gmcharlt> #topic Core Infrastructure Initiative Badge Program
15:57:22 <gmcharlt> kmlussier: you're up
15:57:22 <kmlussier> Very briefly, I would like to see if Evergreen has a shot at earning this badge. I have a volunteer from the community to help with going through the criteria, but was also looking for  a volunteer to help with the more technical bits.
15:57:31 <kmlussier> #link https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md
15:58:33 <kmlussier> I figured we could divide it up according to see if Evergreen meets specific criteria and to find out which areas need more work.
15:58:43 <gmcharlt> kmlussier: if nobody else volunteers... I'm interested, but not before October
15:58:56 <gmcharlt> however, this strikes me as something that might be doable via open-ils-dev
15:59:10 <gmcharlt> as some of the introspection might be better done out in the open
15:59:20 <miker> and possilbly even on -general
15:59:34 <miker> as not everything is code-related (thankfully)
16:00:00 <miker> well... I take that back
16:00:05 <miker> it's like 90% code
16:00:08 <kmlussier> :)
16:00:10 <gmcharlt> :)
16:01:11 <gmcharlt> so, something for folks to think about
16:01:25 <gmcharlt> we have reached the hour, but have two items for dev feedback
16:01:29 <kmlussier> Yes, I was planning to share our progress on the list, whichever one it is. But it still requires people to take the initial look and see where there are questions.
16:02:00 <Dyrcona> kmlussier: You could always ask for technical help on the dev list.
16:02:36 <berick> i like the idea.  taken as a whole it seems daunting.  in smaller pieces on the dev list i'm sure we could suss it out.
16:03:06 <JBoyer> The list is also a good way to see who has claimed what parts rather than searching IRC logs.
16:03:37 <berick> gmcharlt: and i have a 3rd (small) dev request for feedback
16:03:53 <gmcharlt> so, if kmlussier takes up the idea, are folks willing to commit to responding on open-ils-dev?
16:04:21 <miker> I can certainly respond to specific questions, indeed
16:04:24 <gmcharlt> also are folks willing to send up to 15 minutes on the dev review items (5 minutes apiece), or shall we close the meeting now?
16:04:38 <kmlussier> yes
16:04:43 <miker> I'm willing, but biased :)
16:04:44 * berick will stick around
16:04:57 <JBoyer> +1 the clock is still running.
16:05:08 <gmcharlt> tick-tock
16:05:12 <Dyrcona> I can stay.
16:05:14 <gmcharlt> miker: so, speaking of time...
16:05:20 <miker> prepare for a short monolog to start:
16:05:28 <miker> some EG sites span timezones (see: sitka), and other could, easily.
16:05:35 <miker> we added client timezone passing to opensrf, and use it in evergreen, as of opensrf 2.5 and eg 2.12
16:05:42 <miker> better timezone support would be really good, especially for due dates which are shifted to the end of the day
16:05:49 <miker> there are several bugs for that... 1074195, 1703020 among them
16:05:57 <miker> but, angular does not do "real" timezones on its date filter. only offsets: https://code.angularjs.org/1.6.5/docs/api/ng/filter/date
16:06:12 <miker> in order to support proper time zones, we need something better. that better thing is the moment.js timezone module: http://momentjs.com/timezone/
16:06:25 <miker> (so sayeth the google and stack exchange)
16:06:32 <miker> and the integration for that is in the branch on https://bugs.launchpad.net/evergreen/+bug/1705524
16:06:32 <pinesol_green> Launchpad bug 1705524 in Evergreen "Honor timezone of the acting library where appropriate" [Wishlist,New]
16:06:40 <miker> that branch contains a mapping layer to translate between angular and moment "locale-aware" time formats such as "short" and "shortDate" on the angular side
16:06:47 <miker> but there are minor mismatches, and the angular version is less close to the ISO standard for locale formatting
16:06:56 <miker> so, I would like to override the built-in date filter in angular with a moment-based one
16:07:00 <miker> ... objections?
16:07:31 <JBoyer> How far is less close?
16:07:34 <miker> (pros: better support, more consistent UIs; cons: more JS to download)
16:07:41 <JBoyer> (for those of us only now seeing it)
16:07:45 <Dyrcona> No. I assume you're also looking for willing victims...er test subjects.
16:07:48 <miker> JBoyer: zero-padding differences
16:08:00 <miker> mainly
16:08:11 <JBoyer> Hmm.
16:08:15 <miker> and a huge lack of standard locale-aware formats in angular
16:08:23 <miker> moment.js just supports everything
16:08:30 <miker> angular sorta tries to
16:08:47 <Dyrcona> Is the standards conformance better in later versions of Angular?
16:08:48 <miker> so, I gues my mainly was misplaced ;)
16:08:57 <miker> Dyrcona: nopers :(
16:09:03 <JBoyer> Oh, if you mean that moment.js is closer to ISO that's not how I read it.
16:09:11 <miker> Dyrcona: and it still doesn't undertand real timezones, just offsets
16:09:23 <miker> JBoyer: that is what I meant, sorry
16:09:45 <miker> basically, moment.js + moment-timezone = iso standard (as best as JS can manage)
16:09:55 <JBoyer> Ah.
16:10:36 <Dyrcona> Well, +1 from me for moment.js
16:10:39 <miker> so, we /have/ to use moment sometimes (for any DST-aware timestamps)
16:10:50 <miker> but I want to use it everywhere for consistency
16:11:41 <JBoyer> Definitely +1 for all or nothing. As soon as you have to decide whether or not you can get away with using X or if you have to use Y things need to be rethought.
16:12:22 <miker> right, same thought here. but, I'll be transparently replacing angular's date filter with a moment-based implementation
16:12:33 <miker> so, figured best to ask around ;)
16:12:54 <gmcharlt> ok - so five minutes are up for that discussion
16:12:58 <gmcharlt> moving on to berick
16:13:05 <miker> we could do it non-transparently, but that would mean touching tons of code, and likely reintroducing problems later
16:13:08 <miker> gmcharlt: kk
16:13:32 <JBoyer> Considering that my alternative is to only store UTC in the DB, treat :59:59 as magic, and do all offset math client side, this is as +1 an alternative as there can be. ;)
16:13:37 <berick> this should be simple, do we want to wait until after 3.0 to update from angular 1.5 to 1.6 (bug #1680140) ?
16:13:37 <pinesol_green> Launchpad bug 1680140 in Evergreen "Update staff JS dependencies for Angular 1.6" [Wishlist,Confirmed] https://launchpad.net/bugs/1680140
16:14:29 <gmcharlt> berick: I'm inclined to defer that decision to the week of 28 August
16:14:31 <berick> i ask becuase any time we muck about in the js, espeically the deps it means re-testing, rebasing, etc.
16:14:39 <Dyrcona> Given your comments from today, I'd say wait.
16:14:46 <gmcharlt> i.e., give a try before the beta gets cut
16:15:40 <gmcharlt> not that I'm particuarly opposed to waiting until after 3.0... but given our experience with Dojo, I think there's a strong argument to be made that we should get used to biting the version treadmill bullet
16:15:51 <gmcharlt> (to thoroughly mix metaphors)
16:16:04 <berick> gmcharlt: ok, works for me.  i can help clean it up, just want to do it at the best time (i.e when the effort won't be wasted)
16:16:13 <csharp> gmcharlt++
16:16:23 <berick> i'll add a note to the bug about revisiting
16:16:34 <gmcharlt> ok
16:16:43 <gmcharlt> so then, finally, back to miker about offline
16:17:15 <miker> Really, I just want to get input on the serviceworker setup in use, and ask for testing
16:17:19 <csharp> @band add The Version Treadmill Bullet
16:17:19 <pinesol_green> csharp: Band 'The Version Treadmill Bullet' added to list
16:17:50 <miker> we're using UpUp currently
16:18:10 <miker> https://www.talater.com/upup/
16:18:26 <miker> which does the bare minimum to supply offline functionality
16:18:34 <miker> rather than a whole serviceworker framework
16:18:58 <miker> I see that as a plus -- list assets needed, it keeps them current
16:19:05 <miker> if the network can't serve them, it will
16:19:37 <miker> the branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/miker/lp-1706107-offline-mode
16:19:52 <miker> LP at https://bugs.launchpad.net/evergreen/+bug/1706107
16:19:52 <pinesol_green> Launchpad bug 1706107 in Evergreen "Offline mode for the Web Client" [Undecided,New]
16:20:19 <kmlussier> I've already done a fair amount of testing and could probably add a signoff sometime soon. I probably would want to load it on a local test server just to make sure it still works as I remember.
16:20:40 <JBoyer> I'm +1 to using the simplest thing that will work, though I've not been able to test that branch yet.
16:20:50 <kmlussier> miker: Are we losing anything by not using the whole serviceworker framework?
16:20:59 <miker> kmlussier: complication? ;)
16:21:07 <miker> seriously, not that I can see
16:21:28 <miker> we just need something that can intercept network calls and serve content locally
16:21:40 <miker> that is /all/ upup tries to do
16:21:57 <miker> and, now that it's all set up, it seems to do well
16:22:03 <berick> ditto JBoyer
16:22:57 <miker> kmlussier: when testing the new separate branch (was embedded in serials before) we'll need to watch for new 404s during offline mode
16:23:38 <miker> one key thing is that upup has to know about (and cache) every single resource that the offline interface references, either directly or indirectily, via css include or xhr also
16:24:29 <miker> for instance, I had to install the woff2 version of the bootstrap font because, even though we don't use it, it's requested by the css
16:24:54 <miker> and causes a load failure in the offline UI if it can't be cached by the service worker
16:26:17 <miker> to sum up: this is a call for testing, and secondarily, a call for critique of the implementation
16:26:22 <kmlussier> ok, I'll try to carve time out for testing it. I think I know what to look for and how to break it if there are issues. :)
16:26:44 <gmcharlt> ok, and with that, we've reached the end
16:26:45 <miker> kmlussier: if anyone does ... ;)
16:26:46 <miker> thanks all
16:26:49 <gmcharlt> thanks everybody!
16:26:52 <gmcharlt> #endmeeting