Evergreen ILS Website

IRC log for #evergreen, 2018-02-07

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
06:31 pinesol_green News from qatests: Failed Log Output: osrfsys.log - Expected 3 errors but encountered 6. <http://testing.evergreen-ils.org/~live>
07:30 rjackson_isl joined #evergreen
07:46 agoben joined #evergreen
08:41 rlefaive joined #evergreen
08:46 Dyrcona joined #evergreen
09:02 rlefaive joined #evergreen
09:10 rlefaive joined #evergreen
09:11 kmlussier joined #evergreen
09:15 rlefaive joined #evergreen
09:26 rlefaive joined #evergreen
09:27 yboston joined #evergreen
09:35 rlefaive joined #evergreen
09:57 littlet joined #evergreen
10:10 terran joined #evergreen
10:12 mmorgan joined #evergreen
10:17 terran mmorgan++ and Dyrcona++ for attempting to help me with Novelist. Apparently they have customized our code to filter suggestions based on the value of locg in the URL and when locg isn't there, it breaks
10:17 terran So that should hopefully be an easy fix on their end
10:18 terran I notice that it works either way in NOBLE's catalog
10:19 mmorgan Yay! terran's hair is saved!
10:19 Dyrcona terran: Glad you were able to figure it out.
10:19 terran Now on to Syndetics :D
10:21 kmlussier terran: That's awesome!
10:21 * kmlussier hopes for a quick Syndetics solution. That would truly be a good day for terran.
10:23 terran Between berick++ fixing the bill payment receipt problem on Monday and then me figuring out Novelist yesterday, this week is shaping up nicely so far!
10:23 terran * terran waits for the other shoe to drop...
10:35 Bmagic I have something interesting. We have a library that has a policy which requires that Juvenile patrons to "reregister" when they become adults. Basically, sign the document, then the staff will remove the juvenile flag.
10:36 Bmagic In order to prevent the flag from being removed automatically, we changed their library setting for juveniles to 1000 years
10:36 Dyrcona It's a stupid policy. Tell them to change it.
10:36 Bmagic Everything is fine, because they want to manually remove the flag. But now that we are using the Web based staff client, they cannot clear the juvenile flag! There is javascript on the page doing the date math
10:37 berick Bmagic: it's not that interesting, it's just a bug ;)
10:37 kmlussier Sounds like a bug that should be filed.
10:37 kmlussier berick beat me to it. :)
10:37 Bmagic really? It sounds like it's a feature
10:38 Dyrcona Well, one person's bug is another's feature.
10:38 berick Bmagic: it is a feature, but staff should be able to override
10:38 Bmagic Someone had to write more code to make it do that
10:38 Dyrcona It's still a stupid policy.
10:38 berick the intent of the code IIRC is to set a default, not to force a value
10:38 Bmagic Dyrcona: agreed
10:39 kmlussier Well, I'm sure there are other instances where staff want to manually remove the juvenile flag, regardless of that particular policy.
10:39 miker Bmagic: it is a feature if you use the "de-juvenile-ifier" ... except for emancipated minors. doh!
10:39 miker (IMO, I should add)
10:39 Dyrcona Yes, I agree the behavior of the staff client is a bug.
10:39 Bmagic well, if we all agree that it's a bug, then I suppose that is the path forward. I was thinking we would use a stat cat for them
10:57 Bmagic Debbie has a question about the conference. Who is facilitating the Hackfest at the conference?
10:58 terran I'm not sure that anyone has volunteered yet
11:02 Dyrcona Someone usually steps up that morning, typically gmcharlt.
11:18 mdriscoll joined #evergreen
11:33 gmcharlt I'm willing to volunteer
11:36 terran gmcharlt++
11:39 rlefaive joined #evergreen
11:47 berick gmcharlt++
11:49 mmorgan1 joined #evergreen
11:51 khuckins joined #evergreen
11:51 mmorgan2 joined #evergreen
11:56 Christineb joined #evergreen
12:02 rlefaive_ joined #evergreen
12:03 jihpringle joined #evergreen
12:12 jihpringle joined #evergreen
12:18 rlefaive joined #evergreen
12:20 pinesol_green [evergreen|Cesar Velez] LP#1739669 - add PaymentType and persistkey bill payment hist grid - <http://git.evergreen-ils.org/?p=​Evergreen.git;a=commit;h=2a9d6c6>
12:37 rlefaive joined #evergreen
12:43 phasefx stock concerto data, Staff has the VIEW_BILLING_TYPE permission at depth 1.  Would you expect for them to be able to create bills with the stock Misc billing type, owned by the Consortium?
12:44 phasefx if nothing else, there's a difference in behavior here between webby (using pcrud) and xul (using open-ils.circ.billing_type.ranged.retrieve.all)
12:44 * phasefx will bug it
12:48 Dyrcona What's the difference? Staff can use Misc in XUL and not in webby?
12:51 kmlussier phasefx: Yes, I would expect them to be able to use the stock Misc billing type.
12:52 Dyrcona So, would I.
12:53 rlefaive joined #evergreen
12:53 * Dyrcona probably should have paid more attention to Lp 1167541.
12:53 pinesol_green Launchpad bug 1167541 in Evergreen 2.11 "Pickup library defaults to Home OU of staff, instead of patron when placing holds" [Medium,Fix released] https://launchpad.net/bugs/1167541
12:57 kmlussier Dyrcona: Yeah, I feel the same way. For some reason, when it went in, I had been thinking it was using the staff workstation.
12:58 Dyrcona My latest remarks not withstanding, I guess a setting is the only way out of it, now. Particularly in light of who signed off on the commit. :)
12:59 Dyrcona A setting complicates things further.
13:04 jeff Hrm.
13:04 JBoyer I'll admit I came in complaining a little late in the game, but my reasoning is that the only thing worse than making a patron preference not apply at all is making it apply "sometimes."
13:04 Dyrcona Well, I stated my thoughts on the new bug, so I won't repeat them here.
13:05 JBoyer Explaining any of this to a patron who has complained that sometimes their items go here and sometimes there will at best result in a glassy eyed stare.
13:05 mllewellyn joined #evergreen
13:05 Dyrcona I'll add this: I think we sometimes put too much on the software. The human user should take some responsibility for what's going on.
13:07 miker phasefx: yeah, looks like we should just use the existing API rather than pcrud
13:08 Dyrcona miker: One person's bug is another's feature. :)
13:08 Dyrcona And that's twice I've said that today. :)
13:10 collum joined #evergreen
13:10 mmorgan2 I think a change in behavior of the software brings a lot of things to light. If staff are used to it working one way, and it changes, they need to adjust their interaction with the patron.
13:11 miker Dyrcona: re billing types?
13:11 Dyrcona No, re hold pickup location for staff-mediated holds.
13:12 kmlussier I also wonder if there is a difference in expectation in places that tend to have large county and multi-branch systems as opposed to consortia mostly made up of standalone libraries.
13:13 Dyrcona That could be part of it.
13:13 miker oh, sure. and I don't disagree with you about making it simpler and just using ws ou.  that at least has the benefit of perfectly predictable defaults. but I agree a little more with JBoyer that honoring the user setting is everywhere is good...
13:15 mmorgan If we're doing an ou setting, it should be flexibile enough to allow libraries that want to default to staff workstation over user setting for staff placed holds to do that.
13:16 rlefaive joined #evergreen
13:16 miker mmorgan: that's my proposal
13:17 miker but not my preference ;)
13:17 * Dyrcona now prefers not defaulting and making staff choose something. That forces them to ask the patron.
13:18 Dyrcona But that'll go over like a lead zeppelin....
13:20 Dyrcona So, I imagine it does make sense in a county system with many branches.
13:21 Dyrcona You call the main branch to place the hold, but you pick it up in the local branch.
13:21 Dyrcona Here, where we don't have county systems, it makes much less sense to do it that way.
13:22 Dyrcona I wouldn't call Andover Public Library to place a hold for me for pickup in Amesbury, for instance.
13:23 miker the pines crowd could set the pref for all users that don't have it at upgrade time...
13:23 miker pines-like
13:24 Dyrcona I think I like use the patron setting, if set, otherwise using workstation ou, or nothing at all.
13:25 kmlussier But do we know that this is just an issue for pines? I seem to recall that rhamby was also advocating for patron home library back in his SC LENDS days when the bug was first filed.
13:25 rhamby kmlussier: scrolling up to read
13:25 kmlussier Not that I'm trying to convince people to go back in that direction. :)
13:26 Dyrcona So, maybe the setting should just be use workstation ou or patron home ou, and use the patron preference in either case.
13:26 rhamby yes, I remember that bug well, and yes, it would be a welcome change for most larger resource sharing consortia I think
13:27 kmlussier rhamby: The change has already come. The complaint is from all the libraries who didn't like the change. :)
13:27 Dyrcona :)
13:27 rhamby sorry, tenses are off (it's one of those days) ... is welcome
13:28 rhamby kmlussier: you just want an excuse to add more org unit settings
13:29 * abneiman noting that kmlussier DOES have that "YAOUS" mug ;-)
13:29 kmlussier abneiman: I think I'm the only one.
13:29 rhamby kmlussier: you are
13:30 kmlussier But I do like software that is flexible for the varied libraries/consortia that uses it.
13:30 rhamby that's kinda what I said
13:30 kmlussier I also like the setting mmorgan recommended in the bug.
13:31 * mmorgan just wants it to work for everyone :)
13:31 * rhamby is getting warmed up giving kmlussier grief since the outreach meeting is in 30 minutes
13:31 Dyrcona mmorgan: Good luck with that! ;)
13:33 rhamby kmlussier: which comment is mmorgan's suggestion under, I don't see it skimming the page
13:34 kmlussier rhamby: https://bugs.launchpad.net/ever​green/+bug/1699838/comments/11
13:34 pinesol_green Launchpad bug 1699838 in Evergreen "OU setting needed for default pickup location for staff placed holds" [Medium,Confirmed]
13:35 rhamby ah, I see, I was looking at the old bug listing
13:35 kmlussier Really, I think there are just three scenarios that are being suggested here. workstation all the time, patron default -> workstation, patron default -> patron home library.
13:35 kmlussier Not too difficult to make everyone happy in this one instance.
13:37 rhamby I'm fairly ambivalent.  The original behavior was undesirable in my opinion back in 2013 but I think so many people have now adjusted to it that it's the new normal so now how they would have wanted it then is now undesirable.
13:38 rhamby IOW, the desired behavior is whatever you're used to (for many)
13:43 mmorgan Folks get accustomed to the way things work, they have to. When "the way things work" changes, and it doesn't work out for some, we get the opportunity to make it work better.
13:44 Dyrcona Well, I suggested leaving the pickup ou unset, but if you blinked you missed it.
13:48 sandbergja joined #evergreen
13:51 mllewellyn left #evergreen
14:00 phasefx a long time ago I was wondering how would treat a given setting that existed in multiple places (user, org, workstation, client), and how one might weight them, and I gave up and ran away
14:10 Dyrcona phasefx: There aren't many of those are there?
14:12 phasefx no, but I was imagining some generic infrastructure that would apply to everything
14:12 phasefx we do have some warts
14:13 phasefx let's make column settings stickly..  no let's make that read-only.. and/or let's serve the defaults from a remote URL
14:13 phasefx IMO
14:13 Dyrcona Yeah, I see what you're saying.
14:14 phasefx stickly = sticky / sickly
14:15 Dyrcona heh
14:28 JBoyer We could try to follow CSS's lead, more specificity = more priority. Cons, org, workstation, user. Don't want to worry about a use case, make it a permission and don't give it to anyone. :)
14:30 phasefx might have some objects that end up being peers, not sure what is more specific
14:34 Dyrcona Well, in general, it should probably go user setting, org. setting, workstation, client, but there will be exceptions, I'm sure.
14:34 phasefx but yeah, we could define just one order of precedence
14:34 Dyrcona :)
14:34 phasefx and someone somewhere would want to change it :)
14:35 Dyrcona Of course.
14:36 Dyrcona And, that's why one ends up with 9 git customization branches. :)
14:43 Dyrcona I love how a rebase can run into issues with different commits in the branch being rebased.
14:43 Dyrcona You wouldn't think it would have a problem with your own commits, but it can.
14:45 Dyrcona Even in files that don't exist in the branch you're rebasing onto... or is it from?
14:46 Dyrcona Oh, yuck. This is why I often just delete branches and remake them over again.
14:48 JBoyer phasefx++ # bug 1747990
14:48 pinesol_green Launchpad bug 1747990 in Evergreen "list of billing types is gathered differently between XUL client and web client" [Undecided,New] https://launchpad.net/bugs/1747990
14:50 JBoyer Without climbing (too high) on my high horse, any call to pcrud.* should be a candidate to become a "real" API call.
14:52 berick JBoyer: from my perspective, if a real API already exists that solves a problem (e.g. the billing types) then we should probably use it.  I would not advicate for moving away from pcrud.  it's part of what helps speed up the browser client.
14:53 berick pcrud is our friend, except when it's not quite up to the job.
14:54 JBoyer There's no reason any other type of call needs to be significantly slower, the fact that some are currently shouldn't be caused by what service they live in.
14:55 berick if that were true, we would never have written anything in C :(
14:56 gmcharlt yeah, there is an inherent cost to Perl code and subrequest hops, though to be fair, it's not everythign that requires sub-10-millisecond latency
14:56 JBoyer I'm not doing a very good job getting out what I'm trying to say.
14:57 phasefx I always thought of pcrud as a convenience for the developer; easier to throw some perms and a controller into the IDL than writing API
14:57 miker phasefx: that's the intent, yes. when you just need an ORM, not biz logic, use pcrud
14:57 JBoyer I don't see why calling one perl function in a perl service should be significantly slower than calling a different function in another perl service (except that I realize one may be a lot thinner/thicker than the other which can slow down instatiating new children, etc.)
14:58 miker JBoyer: pcrud is C...
14:58 miker to provide numbers: perl APIs have a latency of ~10-20ms/message on average, C APIs have 2-5ms latency
14:58 JBoyer Oh, right.
14:58 JBoyer I did forget about that. (I was thinking cstore was, forgot pcrud.)
14:58 gmcharlt 2 minute meeting warning
14:59 berick i will also note not having a proliferation of apis to maintain (vs. autogenerated) is a bonus.
15:00 JBoyer Oops, I got too high up on my horse. :) Anyone who wants to hear me grouse can do so some other time when it won't interfere with a meeting.
15:00 berick JBoyer++
15:00 JBoyer berick, that's a separate thing I also have opinions about. I'll spare everyone. ;)
15:01 gmcharlt :#startmeeting Evergreen Development Meeting, 7 February 2018
15:01 gmcharlt #startmeeting Evergreen Development Meeting, 7 February 2018
15:01 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 pinesol_green Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01 pinesol_green The meeting name has been set to 'evergreen_development_meeting__7_february_2018'
15:01 gmcharlt #link Agenda is (*cough*) https://wiki.evergreen-ils.org/do​ku.php?id=dev:meetings:2018-02-06
15:01 gmcharlt #topic Introductions
15:01 gmcharlt #info gmcharlt = Galen Charlton, Equinox
15:02 berick #info berick Bill Erickson, KCLS
15:02 phasefx #info phasefx = Jason Etheridge, Equinox
15:02 miker #info miker = Mike Rylander, EOLI
15:02 phasefx had to be different ;)
15:02 kmlussier #info kmlussier is Kathy Lussier, MassLNC
15:03 jeffdavis #info jeffdavis = Jeff Davis, BC Libraries Coop (Sitka)
15:03 dbs #info dbs = Dan Scott, Laurentian University
15:03 khuckins_ joined #evergreen
15:03 abneiman #info abneiman = Andrea Buntz Neiman, Equinox OLI
15:03 dbwells #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:03 rhamby #info rhamby = Rogan Hamby, EOLI
15:05 gmcharlt #topic Action items
15:05 JBoyer #info JBoyer = Jason Boyer, IN State Library
15:05 gmcharlt a couple just carry over, again :/
15:05 gmcharlt #action gmcharlt will open and work on bugs for documentation changes for better ejabberd configuration during installation of OpenSRF
15:06 gmcharlt #action gmcharlt will work on patches destined for a release of OpenSRF 3.0.1 in Feburary
15:06 gmcharlt dbwells: did you have a chance to tweak the downloads page to make Hatch more visible?
15:06 dbwells no, sorry :(
15:07 gmcharlt #action dbwells will tweak the Evergreen downloads page to unbury the Hatch download link
15:08 gmcharlt though speaking of Hatch, I've updated the downloads page just now to reflect 0.15
15:08 gmcharlt er, 0.1.5
15:08 berick thanks gmcharlt
15:08 JBoyer gmcharlt++
15:08 gmcharlt so moving on in topics
15:08 gmcharlt not much to say about OpenSRF
15:08 gmcharlt so
15:08 gmcharlt #topic Evergreen release update
15:08 gmcharlt dbwells, you ahve the floor
15:09 dbwells Well, the most important thing to note is the deadline this Friday for "feature slush".
15:09 miker dbwells: does that mean "no more targeting of features"?
15:09 dbwells Realistically, folks have until Monday if they wish to keep pushing on something.
15:09 miker or "no more  merging unless you're called dbwells"
15:10 dbwells Closer to the first, definitely.
15:10 miker kk
15:11 dbwells to quote: "at this point, all significant features should either have been merged or at least have LP bugs and pullrequests"
15:12 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 dbwells Response has been, shall we say, underwhelming :)
15:13 dbwells I'm hopeful still for movement before this release is in the books.
15:14 jeffdavis dbwells: I wasn't sure whether to volunteer to review EbookAPI code since I wrote pretty much all of it?
15:14 jeffdavis happy to do so if that isn't an issue though
15:15 dbwells I'll be sending another update to the list with various notes in the next few days.
15:15 dbwells jeffdavis: If it needs it (not looking), you are the perfect person for the job!
15:15 jeffdavis ok will do
15:16 dbwells I think that is all for now, unless there are questions.
15:16 gmcharlt just noting that I'm tidying up a few follow-ups for bug 1676608 this afternoon
15:16 pinesol_green Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New] https://launchpad.net/bugs/1676608
15:18 gmcharlt moving
15:18 gmcharlt #topic Hatch update
15:18 gmcharlt #info Hatch 0.1.5 released
15:18 gmcharlt #info Version number bumps are requested to be included as a separate commit
15:18 gmcharlt berick: JBoyer: anything else?
15:19 JBoyer +1 to separate version bumps,
15:19 berick nothing else from me.  just thanks for all the fixes
15:19 JBoyer Other than trying and completely failing to get FF to even see it I don't have anything else.
15:20 gmcharlt OK, then moving on
15:20 gmcharlt #topic Discussion on mixed use of voids / account adjustments
15:20 gmcharlt #link https://bugs.launchpad.net/evergreen/+bug/1671856
15:20 pinesol_green Launchpad bug 1671856 in Evergreen "Mixed use of Account Adjustment payments creates inconsistency" [Undecided,New]
15:23 gmcharlt so... any discussion? are we closer to a decision?
15:23 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 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 JBoyer (Forgive me if that's been shot down already, I know that's not happening in the 3.1 timeframe)
15:25 kmlussier But I'm still highly interested in the proposed UI changes from dbwells.
15:25 berick i'm also interestd in the UI changes
15:27 gmcharlt then it sounds like we're basically continuing the discussion then... although not necessarily during this meeting?
15:28 ngf42 joined #evergreen
15:28 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 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 kmlussier dbwells: Ooh! That's exciting.
15:29 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 * JBoyer will try to contribute less noise if he doesn't have a firm grasp on the issue at hand..
15:30 gmcharlt i.e., go with berick's or dbwells' patches by the time feature freeze rolls around
15:30 gmcharlt does that sound like a fair summary?
15:30 kmlussier +1
15:31 gmcharlt so moving on
15:31 gmcharlt #topic Discussion on iOS support for web client
15:31 gmcharlt #link http://georgialibraries.markmail​.org/thread/rijxfn7s2fjo4mf7%7D
15:31 gmcharlt #link https://bugs.launchpad.net/evergreen/+bug/1746020
15:31 pinesol_green Launchpad bug 1746020 in Evergreen "Unable to log into web client on iOS" [Medium,Fix committed]
15:32 gmcharlt er, rather
15:32 gmcharlt #link http://georgialibraries.markma​il.org/thread/rijxfn7s2fjo4mf7
15:32 gmcharlt so, of course, what is not explicitly blocked users will do anyway ;)
15:33 gmcharlt but in the short term, folks have been loading the web client in iOS in the wild
15:33 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 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 gmcharlt yeah
15:35 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 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 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 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 gmcharlt yeah, at the moment anybody who badly wants offline circ on an ipad probably needs to consider writing a native app
15:37 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 kmlussier gmcharlt: I can't commit to testing against iOS/Safari, but I might be able to find people who can.
15:38 gmcharlt yeah, blocking service-worker-based offline in iOS would be doable
15:38 gmcharlt but one thing I'm wondering is what other uses, if any, we want to apply service workers to
15:39 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 miker that's the actual current breakage, IIUC
15:39 berick yeah
15:39 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 dbs Normally they're a progressive enhancement (speed etc) but offline support is obviously a different matter :)
15:40 miker JBoyer: but lots of folks want to have tabs sync on updates
15:40 gmcharlt on the other hand, multi-tab might be less of a concern for mobile devices
15:40 miker that's a very common request, and broadcast channels make that nearly trival
15:40 gmcharlt (although not for Safari on the desktop)
15:40 miker well, not in the way we use tabs today, really
15:41 miker we open a new tab instead of using huge modals
15:41 miker because there's just not enough screen space on even a huge modal for most complex UIs
15:41 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 miker copy editor for instance
15:42 gmcharlt hmm, MessageChannel /does/ have broader support, and it looks like there's at least one BroadcastChannel polyfill that could use it
15:43 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 miker edge and ie claim messagechannel support, per caniuse.com
15:44 berick i'm all for documenting issues, moving in that direction, but outright saying we support it is.. a bit more.
15:44 gmcharlt berick: yeah, I think it in part depends on identifying folks/institutions willing to commit to it
15:44 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 miker berick: I agree with best-effort, until/unless there's a maintainer
15:45 * berick nods
15:46 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 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 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 dbs It's too bad there was that misunderstanding, we could have cleared that up very quickly last year even
15:49 jeffdavis it's not an unreasonable expectation though, and taking steps to minimize breakage seems like good dev policy
15:50 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 kmlussier My recollection was that mobile use was one of the initial investigation areas when the first protype was created.
15:52 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 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 kmlussier Yeah, well, that is annoying. But, unfortunately, Apple has a large share of that market.
15:53 miker heh. what gmcharlt said
15:53 khuckins__ joined #evergreen
15:53 Dyrcona Yeah, but the user don't care whose fault it is. They just want it to work.
15:53 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 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 miker right
15:54 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 JBoyer I don't recommend it to people, just noting it works. :p
15:55 gmcharlt so, since we've got five minutes left, I'd like to move to the final agenda item
15:55 gmcharlt so...
15:55 dbs I mean, berick did hold up his phone during a session last year saying he had done something with webby so... :)
15:56 gmcharlt #topic Improvements for QA tester
15:56 phasefx so, there's really a larger topic here than what I put on the wiki :-/
15:56 berick dbs: i also said lots of other things..
15:56 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 phasefx I'm willing to improve/fix/wrangle the tech side of things, but I'm not sure about culture/process
15:58 phasefx some suggestions.. positive reinforcement from the tools instead of just negative feedback (winning streaks, etc.)
15:58 phasefx putting QA reports on the agenda for every dev meeting
15:59 phasefx I don't know what else... what do you guys think?
15:59 gmcharlt the last in particular sounds like a useful, quickly implemented step
15:59 gmcharlt maybe combined with a copy easy-to-calculate metrics of work done since the previous meeting
15:59 gmcharlt e.g., commits added
15:59 phasefx tests added
15:59 phasefx tests fixed, tests removed
16:00 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 phasefx and of course, I still want what I put on the agenda, tech/feature suggestions :)
16:01 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 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 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 phasefx gmcharlt: right, twice a day
16:03 phasefx buildbot may be different
16:03 phasefx were it working for anything other than OpenSRF
16:03 JBoyer If changing that would be a significant undertaking in resources it may not be worth it.
16:04 phasefx it could maybe run more often if we go with berick's smaller dataset notion
16:04 phasefx right now it's designed with the notion that side effects might not be well contained and/or reversible
16:04 phasefx thus, complete vm wipes to a known state between runs
16:05 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 phasefx and get more time of day coverage that way
16:06 gmcharlt well, we're past the hour, but somethign that warrants further discussion on open-ils-dev (and tuits donations)
16:07 gmcharlt any other (very quick) items or annoucements?
16:08 gmcharlt ok, sounds like not
16:08 gmcharlt thanks, folks!
16:08 gmcharlt #endmeeting
16:08 pinesol_green Meeting ended Wed Feb  7 16:08:30 2018 US/Eastern.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:08 pinesol_green Minutes:        http://evergreen-ils.org/meetings/evergr​een/2018/evergreen.2018-02-07-15.01.html
16:08 pinesol_green Minutes (text): http://evergreen-ils.org/meetings/evergr​een/2018/evergreen.2018-02-07-15.01.txt
16:08 pinesol_green Log:            http://evergreen-ils.org/meetings/evergree​n/2018/evergreen.2018-02-07-15.01.log.html
16:08 JBoyer gmcharlt++
16:08 phasefx gmcharlt++
16:08 dbs gmcharlt++
16:08 miker gmcharlt++
16:09 kmlussier gmcharlt++
16:09 dbwells gmcharlt++
16:11 berick gmcharlt++
16:15 berick to round out the mobile converstation some, the goal from day one was to use tech. that would make mobile friendly possible, not that it would be mobile friendly on day one.
16:16 berick to a large extent it is by default, because of the tools we use, but no real effort has been put into that as far as I know.
16:17 berick kmlussier: ^-- that's largely in response to your comment about the first prototype
16:20 kmlussier berick: Sure, and I think a lot of work can still be done to make it mobile friendly no matter what device you're using.
16:22 kmlussier But if we rely more and more on technologies that aren't supported by Safari, it brings it into another realm where it's not possible on iOS devices. And if you want to support mobile, iOS has to part of the equation because it's so ubiquitous.
16:23 phasefx app development has superceded mobile web development, IMO, and that's where the resources (say, Apple's) tends to go.  I expect for their browser to always languish, really
16:24 phasefx they're a walled garden, and they like it that way.  powerful browsers can take away their control
16:26 phasefx Microsoft didn't catch on in time; Apple's paying attention I think
16:26 berick my sincere hope is safari will catch up.  it's not /that/ far behind.
16:26 * phasefx is just still bitter that his Quicktime Pro got demoted into Quicktime after a MacOS upgrade
16:27 * kmlussier is still bitter about the time her high school replaced all the TRS-80s with Macs and then stopped offering programming classes.
16:27 Dyrcona :)
16:28 kmlussier I know how to hold a grudge.
16:28 * Dyrcona is bitter than since the fifth generation and the advent of ACPI, the INTEL platform is crap.
16:29 Dyrcona Oops. Did I think that out loud?
16:32 * Dyrcona has too many git branches.....
16:35 beanjammin joined #evergreen
16:52 khuckins joined #evergreen
16:53 gmcharlt dbwells: berick: Bmagic: https://bugs.launchpad.net/evergreen/+bug/1676608 now has updates and is ready for (hopefully final) review and merger
16:53 pinesol_green Launchpad bug 1676608 in Evergreen "Copy Alert Persistence and Suppression Matrix" [Wishlist,New]
16:53 gmcharlt @later tell kmlussier https://bugs.launchpad.net/evergreen/+bug/1676608 now has updates and is ready for (hopefully final) review and merger
16:53 pinesol_green gmcharlt: The operation succeeded.
16:53 Bmagic gmcharlt++
16:53 Bmagic Will load it as soon as I can
17:00 mmorgan left #evergreen
17:05 beanjammin I'm working through the instructions here Open-ILS/web/js/ui/default/staff/README.install for getting node, grunt, and bower setup and am stuck at the `bower install` step. The error returned is "ENOENT No bower.json present". Any ideas on what to try?  There is no bower.json file in Open-ILS/web/js/ui/default/staff though the README.install specifically says to run `bower install` in that directory.
17:06 berick beanjammin: those docs are outdated.  (removed in a pending branch).
17:06 berick the main install docs are what you want
17:06 beanjammin Ah......  Thanks!
17:06 beanjammin Where are the main docs?
17:07 berick https://evergreen-ils.org/docume​ntation/install/README_3_0.html
17:07 berick or more generally linked from the downloads page
17:08 beanjammin berick: Thanks
17:09 berick and as noted in the doc, if installing from a release build/tarball, the browser client dependencies are pre-built.
17:13 sandbergja joined #evergreen
17:26 _sandbergja joined #evergreen
17:37 beanjammin I'm doing some minor CSS changes for the staff client, is there a best place for those to go?
17:38 khuckins_ joined #evergreen
17:59 kmlussier joined #evergreen
18:22 yboston joined #evergreen
18:31 pinesol_green News from qatests: Testing Success <http://testing.evergreen-ils.org/~live>
18:59 sandbergja joined #evergreen
19:28 sandbergja joined #evergreen

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat