15:01:25 <gmcharlt> #startmeeting Evergreen Development Meeting, 7 February 2018
15:01:25 <pinesol_green> Meeting started Wed Feb  7 15:01:25 2018 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:25 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:25 <pinesol_green> The meeting name has been set to 'evergreen_development_meeting__7_february_2018'
15:01:40 <gmcharlt> #link Agenda is (*cough*) https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-02-06
15:01:45 <gmcharlt> #topic Introductions
15:01:52 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
15:02:05 <berick> #info berick Bill Erickson, KCLS
15:02:12 <phasefx> #info phasefx = Jason Etheridge, Equinox
15:02:18 <miker> #info miker = Mike Rylander, EOLI
15:02:25 <phasefx> had to be different ;)
15:02:59 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:03:03 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Coop (Sitka)
15:03:04 <dbs> #info dbs = Dan Scott, Laurentian University
15:03:25 <abneiman> #info abneiman = Andrea Buntz Neiman, Equinox OLI
15:03:28 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:03:30 <rhamby> #info rhamby = Rogan Hamby, EOLI
15:05:18 <gmcharlt> #topic Action items
15:05:38 <JBoyer> #info JBoyer = Jason Boyer, IN State Library
15:05:45 <gmcharlt> a couple just carry over, again :/
15:05:50 <gmcharlt> #action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF
15:06:06 <gmcharlt> #action gmcharlt will work on patches destined for a release of OpenSRF 3.0.1 in Feburary
15:06:27 <gmcharlt> dbwells: did you have a chance to tweak the downloads page to make Hatch more visible?
15:06:54 <dbwells> no, sorry :(
15:07:04 <gmcharlt> #action dbwells will tweak the Evergreen downloads page to unbury the Hatch download link
15:08:03 <gmcharlt> though speaking of Hatch, I've updated the downloads page just now to reflect 0.15
15:08:13 <gmcharlt> er, 0.1.5
15:08:14 <berick> thanks gmcharlt
15:08:15 <JBoyer> gmcharlt++
15:08:24 <gmcharlt> so moving on in topics
15:08:31 <gmcharlt> not much to say about OpenSRF
15:08:32 <gmcharlt> so
15:08:38 <gmcharlt> #topic Evergreen release update
15:08:42 <gmcharlt> dbwells, you ahve the floor
15:09:18 <dbwells> Well, the most important thing to note is the deadline this Friday for "feature slush".
15:09:41 <miker> dbwells: does that mean "no more targeting of features"?
15:09:49 <dbwells> Realistically, folks have until Monday if they wish to keep pushing on something.
15:09:54 <miker> or "no more  merging unless you're called dbwells"
15:10:36 <dbwells> Closer to the first, definitely.
15:10:44 <miker> kk
15:11:28 <dbwells> to quote: "at this point, all significant features should either have been merged or at least have LP bugs and pullrequests"
15:12:39 <dbwells> As part of my email from 1/25, I sent out a first go at trying to organize improvement to code comments.  I really didn't (and still don't) know whether it is or will be helpful or not.
15:12:51 <dbwells> Response has been, shall we say, underwhelming :)
15:13:44 <dbwells> I'm hopeful still for movement before this release is in the books.
15:14:26 <jeffdavis> dbwells: I wasn't sure whether to volunteer to review EbookAPI code since I wrote pretty much all of it?
15:14:46 <jeffdavis> happy to do so if that isn't an issue though
15:15:07 <dbwells> I'll be sending another update to the list with various notes in the next few days.
15:15:22 <dbwells> jeffdavis: If it needs it (not looking), you are the perfect person for the job!
15:15:37 <jeffdavis> ok will do
15:16:13 <dbwells> I think that is all for now, unless there are questions.
15:16:56 <gmcharlt> just noting that I'm tidying up a few follow-ups for bug 1676608 this afternoon
15:16:56 <pinesol_green> Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New] https://launchpad.net/bugs/1676608
15:18:14 <gmcharlt> moving
15:18:17 <gmcharlt> #topic Hatch update
15:18:22 <gmcharlt> #info Hatch 0.1.5 released
15:18:42 <gmcharlt> #info Version number bumps are requested to be included as a separate commit
15:18:54 <gmcharlt> berick: JBoyer: anything else?
15:19:05 <JBoyer> +1 to separate version bumps,
15:19:17 <berick> nothing else from me.  just thanks for all the fixes
15:19:23 <JBoyer> Other than trying and completely failing to get FF to even see it I don't have anything else.
15:20:33 <gmcharlt> OK, then moving on
15:20:46 <gmcharlt> #topic Discussion on mixed use of voids / account adjustments
15:20:56 <gmcharlt> #link https://bugs.launchpad.net/evergreen/+bug/1671856
15:20:57 <pinesol_green> Launchpad bug 1671856 in Evergreen "Mixed use of Account Adjustment payments creates inconsistency" [Undecided,New]
15:23:13 <gmcharlt> so... any discussion? are we closer to a decision?
15:23:21 <JBoyer> A thought since discussion isn't loud and immediate: What if anything that used to void billings continued to do so and if any balance goes negative as a result a new billing is added to offset and even out the transaction?
15:24:56 <kmlussier> At this point, I'm in favor of berick's approach to help out the people who never want to use account adjustments.
15:24:57 <JBoyer> (Forgive me if that's been shot down already, I know that's not happening in the 3.1 timeframe)
15:25:11 <kmlussier> But I'm still highly interested in the proposed UI changes from dbwells.
15:25:24 <berick> i'm also interestd in the UI changes
15:27:47 <gmcharlt> then it sounds like we're basically continuing the discussion then... although not necessarily during this meeting?
15:28:45 <kmlussier> Well, if the UI changes aren't forthcoming shortly, is there any reason we can't move forward with berick's patch?
15:28:53 <dbwells> I've said a lot on the bug, and expect to have a branch to show for the Friday/Monday deadline.  It seems best to have something to react to rather than just my attempts to explain things conceptually.
15:29:10 <kmlussier> dbwells: Ooh! That's exciting.
15:29:44 <gmcharlt> ok, then that sounds like it will turn into a binary decision, at least for the short-term purposes of 3.1
15:30:04 * JBoyer will try to contribute less noise if he doesn't have a firm grasp on the issue at hand..
15:30:08 <gmcharlt> i.e., go with berick's or dbwells' patches by the time feature freeze rolls around
15:30:24 <gmcharlt> does that sound like a fair summary?
15:30:56 <kmlussier> +1
15:31:36 <gmcharlt> so moving on
15:31:39 <gmcharlt> #topic Discussion on iOS support for web client
15:31:45 <gmcharlt> #link http://georgialibraries.markmail.org/thread/rijxfn7s2fjo4mf7%7D
15:31:53 <gmcharlt> #link https://bugs.launchpad.net/evergreen/+bug/1746020
15:31:54 <pinesol_green> Launchpad bug 1746020 in Evergreen "Unable to log into web client on iOS" [Medium,Fix committed]
15:32:11 <gmcharlt> er, rather
15:32:13 <gmcharlt> #link http://georgialibraries.markmail.org/thread/rijxfn7s2fjo4mf7
15:32:37 <gmcharlt> so, of course, what is not explicitly blocked users will do anyway ;)
15:33:18 <gmcharlt> but in the short term, folks have been loading the web client in iOS in the wild
15:33:58 <gmcharlt> and although it's not officially supported, it worked well enough for folks to log on, broke,  and is getting unbroken for 3.0.4
15:33:58 <dbs> I guess the least we can do is document things we know won't / can't work (offline support, whatever Hatch does, ...)
15:34:36 <gmcharlt> yeah
15:35:23 <gmcharlt> and going further, is there any appetite to take it a bit further to put in guards against access the stuff known not to work? and interest in cycles on the part of anybody to do testing against iOS/Safari?
15:35:30 <JBoyer> I don't imagine that many iOS users are interested in printing receipts (Hatch's primary use case). The idea of taking whatever tablet you have on hand into the stacks to capture holds live and without printing anything is something that comes up on occasion when discussing the web client.
15:35:39 <kmlussier> From our perspective, when we decided early on that Chrome and Firefox would be supported browsers, we didn't think it would preclude use on iOS devices since those browsers can be used there.
15:36:30 <kmlussier> I could see a use case for using offline circ on an iPad, but I think if we make it clear that it won't work on iOS, that's a good start.
15:37:02 <gmcharlt> yeah, at the moment anybody who badly wants offline circ on an ipad probably needs to consider writing a native app
15:37:21 <JBoyer> I don't like telling anyone that they can't use a currently supported modern browser when the current breakage is small to unnoticeable. That said I don't know that I'd want to spend a lot of time getting Edge to work.
15:37:29 <kmlussier> gmcharlt: I can't commit to testing against iOS/Safari, but I might be able to find people who can.
15:38:16 <gmcharlt> yeah, blocking service-worker-based offline in iOS would be doable
15:38:42 <gmcharlt> but one thing I'm wondering is what other uses, if any, we want to apply service workers to
15:39:25 <miker> in the long run, they could streamline a lot of things. but it's not just service workers, it's broadcast channels between tabs on the same domain
15:39:35 <miker> that's the actual current breakage, IIUC
15:39:41 <berick> yeah
15:39:48 <JBoyer> I don't personally see any point aside from offline circ in a staff client. You're not going to que up searches to do later when the connection comes back as you might prep emails to send while offline.
15:40:05 <dbs> Normally they're a progressive enhancement (speed etc) but offline support is obviously a different matter :)
15:40:12 <miker> JBoyer: but lots of folks want to have tabs sync on updates
15:40:36 <gmcharlt> on the other hand, multi-tab might be less of a concern for mobile devices
15:40:37 <miker> that's a very common request, and broadcast channels make that nearly trival
15:40:45 <gmcharlt> (although not for Safari on the desktop)
15:40:57 <miker> well, not in the way we use tabs today, really
15:41:14 <miker> we open a new tab instead of using huge modals
15:41:44 <miker> because there's just not enough screen space on even a huge modal for most complex UIs
15:41:51 <JBoyer> I'm not against using broadcasts channels or SWs, I'm against requiring them outright. Having to if (exists...) before every call would be irritating, but putting those calls somewhere in the right service would allow progressive enhancement like dbs mentioned
15:41:55 <miker> copy editor for instance
15:42:03 <gmcharlt> hmm, MessageChannel /does/ have broader support, and it looks like there's at least one BroadcastChannel polyfill that could use it
15:43:33 <berick> i'm less concerned about a specific technology than I am about having to include another browser (possibly on multiple platforms) throghout the dev cycle.  not saying it can't be done, but there is a definite cost.
15:43:58 <miker> edge and ie claim messagechannel support, per caniuse.com
15:44:14 <berick> i'm all for documenting issues, moving in that direction, but outright saying we support it is.. a bit more.
15:44:29 <gmcharlt> berick: yeah, I think it in part depends on identifying folks/institutions willing to commit to it
15:44:36 <jeffdavis> fwiw the Co-op is not in a position to support iOS in dev/testing, much as I'd like iOS to be supported
15:44:45 <miker> berick: I agree with best-effort, until/unless there's a maintainer
15:45:24 * berick nods
15:46:00 <kmlussier> I understand the toll it takes, but mobile use was one of the selling points to get our libraries excited about moving to the web client.
15:46:40 <miker> if we restrict our broadcast use to simple messages (and don't start depending on them in workers) then... the polyfill looks like it might be usable
15:46:44 <kmlussier> And it's difficult to say it can do mobile if it can't run on iOS. So many of our libraries are using iPads and are excited about using them with the web client.
15:47:54 <dbs> It's too bad there was that misunderstanding, we could have cleared that up very quickly last year even
15:49:36 <jeffdavis> it's not an unreasonable expectation though, and taking steps to minimize breakage seems like good dev policy
15:50:01 <JBoyer> That wasn't only a selling point in Massachusetts. Anyone that noticed that Bootstrap and / or Angular allowed fairly dynamic resizing (it's not perfect, obviously) immediately made the jump to "I can use this on an ...!"
15:51:25 <kmlussier> My recollection was that mobile use was one of the initial investigation areas when the first protype was created.
15:52:08 <gmcharlt> yeah; of course, part of the problem is that it's very much a contigent technical decision on Apple's part not to let non-Safari browsers on iOS uses their own engines
15:52:53 <miker> aside from letting all the tabs know that you've logged out, and being able to do offline (that's apple's fault for forcing the safari engine on ios chrome/ff), master works now on mobile, right?
15:53:05 <kmlussier> Yeah, well, that is annoying. But, unfortunately, Apple has a large share of that market.
15:53:05 <miker> heh. what gmcharlt said
15:53:11 <Dyrcona> Yeah, but the user don't care whose fault it is. They just want it to work.
15:53:56 <JBoyer> I've used it here and there on my phone when a question has come up away from a computer, it works fine aside from trying to edit things (a bit small.)
15:54:06 <kmlussier> miker: I've heard that people can log in now. And the only issues I've heard otherwise were responsive design issues, not iOS issues.
15:54:17 <miker> right
15:54:47 <miker> and using it on a phone is ... a questionable decision, IMO. but an ipad? sure, let's try to allow in situ circ!
15:55:14 <JBoyer> I don't recommend it to people, just noting it works. :p
15:55:40 <gmcharlt> so, since we've got five minutes left, I'd like to move to the final agenda item
15:55:49 <gmcharlt> so...
15:55:52 <dbs> I mean, berick did hold up his phone during a session last year saying he had done something with webby so... :)
15:56:00 <gmcharlt> #topic Improvements for QA tester
15:56:03 <phasefx> so, there's really a larger topic here than what I put on the wiki :-/
15:56:06 <berick> dbs: i also said lots of other things..
15:56:54 <phasefx> I was disappointed in us (myself included) for letting the qatester languish in a fail state for a long period a short while back; and I also noticed that we've had only one working buildslave for buildbot since 2016
15:57:18 <phasefx> I'm willing to improve/fix/wrangle the tech side of things, but I'm not sure about culture/process
15:58:07 <phasefx> some suggestions.. positive reinforcement from the tools instead of just negative feedback (winning streaks, etc.)
15:58:23 <phasefx> putting QA reports on the agenda for every dev meeting
15:59:00 <phasefx> I don't know what else... what do you guys think?
15:59:12 <gmcharlt> the last in particular sounds like a useful, quickly implemented step
15:59:31 <gmcharlt> maybe combined with a copy easy-to-calculate metrics of work done since the previous meeting
15:59:35 <gmcharlt> e.g., commits added
15:59:42 <phasefx> tests added
15:59:48 <phasefx> tests fixed, tests removed
16:00:37 <JBoyer> Dev meeting reports are a good idea, especially if it can keep most of the stats going so you don't have to do a lot behind the scenes. And I agree with not wanting only negative feedback.
16:01:36 <phasefx> and of course, I still want what I put on the agenda, tech/feature suggestions :)
16:01:59 <JBoyer> That said, one common piece of negative feedback is "you broke the build!" notifications. I don't think we want to have a stoplight board like some projects I've seen (What did JBoyer do now?) But a gentle nudge to the author of a commit that broke things may be helpful.
16:02:46 <gmcharlt> do I remember correctly that the the tests are run once or twice a day, not triggered when stuff is pushed to master?
16:02:49 <JBoyer> IF it can / should run often enough to be able to pick that out. False positives in that case (1 + n commits go in, the break is attributed to the wrong one) would be frustrating.
16:02:55 <phasefx> gmcharlt: right, twice a day
16:03:00 <phasefx> buildbot may be different
16:03:19 <phasefx> were it working for anything other than OpenSRF
16:03:22 <JBoyer> If changing that would be a significant undertaking in resources it may not be worth it.
16:04:05 <phasefx> it could maybe run more often if we go with berick's smaller dataset notion
16:04:30 <phasefx> right now it's designed with the notion that side effects might not be well contained and/or reversible
16:04:50 <phasefx> thus, complete vm wipes to a known state between runs
16:05:49 <phasefx> we could also farm out the test machines with some infrastructure improvements, let it mimic (or run off of) buildbot in that regard
16:06:02 <phasefx> and get more time of day coverage that way
16:06:47 <gmcharlt> well, we're past the hour, but somethign that warrants further discussion on open-ils-dev (and tuits donations)
16:07:09 <gmcharlt> any other (very quick) items or annoucements?
16:08:26 <gmcharlt> ok, sounds like not
16:08:28 <gmcharlt> thanks, folks!
16:08:30 <gmcharlt> #endmeeting