| Time |
Nick |
Message |
| 02:18 |
|
dbwells_ joined #evergreen |
| 04:46 |
|
gsams joined #evergreen |
| 04:55 |
|
gsams joined #evergreen |
| 05:02 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:53 |
|
agoben joined #evergreen |
| 07:12 |
|
rjackson_isl joined #evergreen |
| 08:01 |
|
Dyrcona joined #evergreen |
| 08:20 |
|
kmlussier joined #evergreen |
| 08:40 |
|
mmorgan joined #evergreen |
| 08:49 |
|
bos20k joined #evergreen |
| 08:49 |
* kmlussier |
wonders when we should change the 2.next milestone to 3.next. :D |
| 08:56 |
Dyrcona |
Or just "next?" |
| 08:56 |
kmlussier |
Speaking of 3.0, /me fills out Doodle poll at http://doodle.com/poll/dhsdx4vdr3qw2r2z |
| 08:56 |
JBoyer |
3.boom |
| 08:56 |
Dyrcona |
2.13 could be fun. :) |
| 08:57 |
gmcharlt |
We shall release it on a Friday, and its code name shall be Black Cat Under Ladder |
| 08:59 |
Dyrcona |
JBoyer: We're going to put your branch from Lp 1611818 in production on Monday. |
| 08:59 |
pinesol_green |
Launchpad bug 1611818 in NCIPServer "Return a Barcode in RequestItemResponse if a copy is targeted" [Low,New] https://launchpad.net/bugs/1611818 |
| 09:00 |
JBoyer |
Dyrcona, good to hear, I hope its helpful. (Given how SHAREit works, it's mostly eliminated the need for anyone to enter barcodes into requests.) |
| 09:00 |
Dyrcona |
Yeah, that's what I expect it to do. I'll push it to master in a week or two if there aren't any issues. |
| 09:02 |
JBoyer |
++ |
| 09:04 |
* mmorgan |
's ears perk up. |
| 09:04 |
gmcharlt |
now cutting OpenSRF 2.5.0 |
| 09:04 |
kmlussier |
gmcharlt++ |
| 09:04 |
Dyrcona |
Maybe at the hackfest, I'll do a README for NCIPServer. |
| 09:05 |
mmorgan |
Dyrcona: JBoyer: So that magically put the item barcode in the SHAREit request instead of a record number? |
| 09:06 |
Dyrcona |
mmorgan: Yes. |
| 09:06 |
Dyrcona |
It pulls the barcode from the copy targeted at the hold if any. |
| 09:06 |
Dyrcona |
If not, then you get the record number. |
| 09:07 |
Dyrcona |
gmcharlt++ |
| 09:09 |
mmorgan |
So if a different copy is captured and sent, the barcode would need to be changed? |
| 09:10 |
Dyrcona |
Yes, I think so. |
| 09:11 |
mmorgan |
Ok, thanks. Sounds like a great improvement overall. |
| 09:11 |
mmorgan |
JBoyer++ |
| 09:11 |
Dyrcona |
JBoyer++ |
| 09:11 |
mmorgan |
Dyrcona++ |
| 09:16 |
kmlussier |
Thinking more on a release 2.13, if we delay the next release for a month, there is a Friday the 13th in October. |
| 09:19 |
Dyrcona |
Well, I was thinking 3.0 would be the one where xul is removed, but if the consensus lies elsewhere, I'm OK with that. |
| 09:20 |
gmcharlt |
yeah, my joking aside, I'm in favor of 3.0 as marking production support for web client |
| 09:20 |
gmcharlt |
(which, by the way, I think means a _deprecation_ of XUL but not yet a removal in 3.0, although obviously that's up for discussion) |
| 09:27 |
kmlussier |
My recollection from the hack-a-way was that the consensus was to have a deprecated XUL for two releases. Of course, it's always a good idea to reaffirm that decision. |
| 09:38 |
pinesol_green |
[opensrf|Ben Shum] LP#1672926: Disable/remove default nginx config in REAMDE steps - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=47bafe1> |
| 09:40 |
Dyrcona |
Yeah, I was just hoping for a definitive break in 3.0, rather than waiting for 3.2, but whatevs.... :) |
| 09:40 |
Dyrcona |
It would likely mean two more 2.x releases. |
| 09:49 |
bshum |
gmcharlt++ # opensrf 2.5.0 goodies |
| 09:50 |
pinesol_green |
[evergreen|Bill Erickson] LP#1670512 Apply focus/select model udpates via timeout - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=014fc6a> |
| 09:55 |
gmcharlt |
https://evergreen-ils.org/opensrf-2-5-0-released/ |
| 09:57 |
kmlussier |
gmcharlt++ |
| 09:58 |
csharp |
@band add BlackCat UnderLadder |
| 09:58 |
pinesol_green |
csharp: Evergreen Command Center http://apod.nasa.gov/apod/image/1204/EndeavourFlightDeck_cooper_1050.jpg |
| 10:00 |
Dyrcona |
Hmm... Black Cat Under A Ladder would make a nice album cover image. |
| 10:00 |
Dyrcona |
And don't "title" the album, just use the artwork for the name. |
| 10:01 |
Dyrcona |
csharp: We should get into the music business while there's still one left. ;) |
| 10:02 |
* csharp |
hooks USB mic to workstation and uses audacity to record album |
| 10:02 |
Dyrcona |
Well, I didn't necessarily mean as performers. ;) |
| 10:23 |
berick |
hey, chuck, you know that sound you been lookin for... *blasts ukulele through usb mic through audacity* |
| 10:24 |
Dyrcona |
heh. |
| 10:25 |
berick |
and +1 to (permanently) renaming 2.next -- or dropping it. having a pullrequest and no target kind of implies 'next' |
| 10:26 |
Dyrcona |
Well, some of us (not necessarily me) have been managing bugs by target. |
| 10:26 |
Dyrcona |
So having no target may make some bugs "disappear." |
| 10:27 |
berick |
Dyrcona: interesting. aren't you missing a lot of bugs that way? |
| 10:27 |
berick |
or do you mean just those w/ pullrequests? |
| 10:27 |
Dyrcona |
I'm not doing it so much, but I know one or two others are, and targets help when you're RM. |
| 10:28 |
Dyrcona |
And, yeah, its mainly for bug with pullrequests. |
| 10:28 |
Dyrcona |
bugs.... |
| 10:28 |
* berick |
certainly doesn't want to make the RM's job more difficult |
| 10:30 |
kmlussier |
In general, if I'm looking at bugs for the next release, I'm looking at ones with the 2.12 target rather than the 2.next target. But I guess the 2.next target serves as a placeholder until the new target is available? |
| 10:30 |
Dyrcona |
Yes. |
| 10:31 |
Dyrcona |
Even after, because not all bugs get updated with the new target right away. |
| 10:31 |
kmlussier |
Now that I think about it, I asked people to assign the 2.next target to bugs if they wanted them to be considered for the release. But I would be up to reconsidering processes if we wanted to get rid of the .next target. |
| 10:31 |
Dyrcona |
I had scripts for that but they stopped working a couple of years ago. |
| 10:32 |
Dyrcona |
I never got around to figuring out why. Something to do with launchpadlib and Python. |
| 10:32 |
kmlussier |
I generally don't update a bug to the target with the real release number unless I'm somewhat certain it's being considered for that release. Because the 2.next target does save a lot of churn for bug wranglers. |
| 10:32 |
Dyrcona |
Well, these scripts were mainly for moving bugs around at release time. |
| 10:33 |
kmlussier |
If you update it to 2.12, it the target then needs to be removed if it doesn't make it into the release. And then it needs to be re-added when the new target is available. With the .next target, it can just sit in the target until the code is merged. |
| 10:34 |
Dyrcona |
They were always kind of clunky and seemed like Lp had some limits on how many you could move at once.... |
| 10:35 |
Dyrcona |
The point is that I think the .next target serves a useful purpose, but that can always be revisited. |
| 10:35 |
berick |
Dyrcona: well then you've answered my question |
| 10:36 |
kmlussier |
If we do keep it, though, I agree with Dyrcona that we might want to name it .next so that we don't need to rename it every time we make a big jump in release numbers. |
| 10:36 |
berick |
i guess the rule is when you add a pullrequest for a wishlist/feature bug, you have to set a milestone of 'next' or it will likley be ignored ? |
| 10:36 |
berick |
yes, definitely needs renaming |
| 10:38 |
kmlussier |
berick: I've always followed that rule when submitting my own code because I was told it would be more likely to get attention if it was targeted. In general, when looking for code to test, I usually just look for the pullrequest tag. |
| 10:39 |
bshum |
One of the old ideas was to rename 2.next into 2.actualnumber-alpha but that got tiresome to keep reshuffling bugs away from the actual milestones. So we ended up leaving 2.next as is as a general placeholder to target future dev |
| 10:40 |
bshum |
I'd prefer to keep a target around for next dev just cause I do find that untargeted bugs can easily get lost in the mire of open tickets depending on how you set your search scopes |
| 10:40 |
berick |
kmlussier: same here, i just look for the tag |
| 10:42 |
kmlussier |
Overall, I think it would be good practice to try to go through all those bugs with pullrequest tags, merge the ones that are ready, and actively remove the pullrequest tags, possibly adding a needsrepatch tag, for ones that aren't ready. |
| 10:42 |
kmlussier |
But now I'm living in the land of dreams. |
| 10:43 |
kmlussier |
I do find that many of the bugs that sit without a pullrequest tag are there because we're reluctant to remove the pullrequest if it's not ready or needs a test. |
| 10:43 |
kmlussier |
OK, now I'm just talking gibberish. /s/without/with |
| 10:45 |
berick |
that's consistent w/ my lp-world view |
| 10:46 |
berick |
pullrequest means merge me as soon as possible, if I don't have a milestone, put me in master. |
| 10:46 |
* berick |
is not pushing for anything, just like knowing how people work |
| 10:47 |
bshum |
I think the other reason I like doing a milestone is just that it's not so easy to filter for bugs without one specifically. Easier to say, with milestone X instead of without any milestone whatsoever vs. the ones with it |
| 10:48 |
bshum |
I just like manageable segments I guess. Looking at the 1300+ open bugs makes me sad |
| 10:49 |
berick |
bshum: tag=pullrequest status!=fix-released ? |
| 10:50 |
bshum |
berick: Right... but how do you only focus on the ones with no milestone currently assigned? |
| 10:50 |
bshum |
Vs. ones that are attached to existing ones? |
| 10:50 |
bshum |
Maybe I only want to find the stragglers |
| 10:50 |
mmorgan |
Seems to me like removing pullrequests as kmlussier suggests would make it easier to filter without considering milestones. |
| 10:50 |
bshum |
Just being devil's advocate |
| 10:51 |
bshum |
Bug triaging hasn't always been awesome in LP land |
| 10:51 |
Dyrcona |
No, it kind of stinks. |
| 10:51 |
gmcharlt |
csharp: bshum: do eiher of you have cycles to look at bug 1669868 today? |
| 10:51 |
pinesol_green |
Launchpad bug 1669868 in Evergreen ""make check" failure" [High,Confirmed] https://launchpad.net/bugs/1669868 |
| 10:51 |
Dyrcona |
That's why I wrote the scripts in the first place. |
| 10:54 |
berick |
bshum: i see.. so there's just no easy way in the UI to search for un-targeted? |
| 10:54 |
|
maryj joined #evergreen |
| 10:55 |
kmlussier |
What is the use case for finding pullrequest bugs that are untargeted? |
| 10:55 |
bshum |
berick: Not that I can find yet |
| 10:56 |
bshum |
kmlussier: Orphaned bugs that need love, basically. |
| 10:56 |
mmorgan |
Not everyone who can add a pullrequest can set a target? |
| 10:56 |
berick |
mmorgan: exactly |
| 10:56 |
kmlussier |
mmorgan: Yeah, that's a problem. |
| 10:56 |
bshum |
mmorgan: Which is also a problem, yeah |
| 10:57 |
mmorgan |
Let's just fix them all, that'll solve it. ;-) |
| 10:57 |
bshum |
This is one of the reasons why we used to mark every bug that was "new" with a status of "confirmed" or "triaged" by a bug team member and assign an initial review target, etc. But that also hasn't been a great maintainable workflow too. |
| 10:57 |
kmlussier |
If I do a search for bugs with a pullrequest tag with a status of new, confirmed, triaged, in progress or incomplete (LP defaults with Fix Committed removed), I get 70. |
| 10:58 |
kmlussier |
I keep thinking that if each core committer took 2 of those bugs per month to review, and either merge or remove the pullrequest tag, we could get through those in short order. |
| 10:58 |
berick |
so in other words if you don't have access to set a target, your bug is by default less likely to get attention. that don't seem right. |
| 11:00 |
kmlussier |
I also think a lot of developers submitting code don't think they're in a position where they should be asking for that access. They're under the impressions that you need to be special to be upgraded to bug wrangler and bug driver status. |
| 11:01 |
Dyrcona |
You only need to be on the wrangler team to set targets, IIRC. |
| 11:01 |
Dyrcona |
And, a few of us can add people. I generally add anyone who requests whose name I recognize from the community. |
| 11:01 |
kmlussier |
But you need to be a driver to add a series. As a wrangler, you can only nominate a bug for a series. |
| 11:02 |
kmlussier |
So if somebody wants to be able to assign backport targets, they really need to be a driver. |
| 11:03 |
kmlussier |
bshum: Another method for finding orphaned bugs is to sort by oldest first. |
| 11:03 |
Dyrcona |
I basically don't have time to spend much of it on Launchpad, I'm afraid. |
| 11:03 |
Dyrcona |
I think the situation is the same the majority of core committters. |
| 11:04 |
bshum |
kmlussier: So the proposal is to not assign any bug targets initially then? And widen our searches to include only bugs tagged pullrequest, and remove pullrequest and add needsrepatch to bugs that need more work? |
| 11:04 |
kmlussier |
bshum: I'm not proposing anything. I'm just participating in discussion. :) |
| 11:04 |
bshum |
kmlussier: Right, I'm just trying to summarize |
| 11:04 |
kmlussier |
But I do think we should remove pullrequests and replace with needsrepatch when warranted. |
| 11:04 |
berick |
bshum: that's essentially what I was proposing |
| 11:04 |
bshum |
The new direction |
| 11:05 |
* bshum |
shrugs, works either way I guess |
| 11:05 |
berick |
bshum: ... to avoid having 2 classes of untargeted pullrequests, those w/ no target, and those w/ a virtual target. |
| 11:05 |
berick |
as to me they are the same thing |
| 11:05 |
bshum |
As long as bugs get worked on, I think that's the key goal :D |
| 11:06 |
berick |
very diplomatic ;) |
| 11:06 |
bshum |
gmcharlt: Speaking of, sorry I saw your question... but got distracted, lol. So uh, my answer is maybe |
| 11:06 |
bshum |
gmcharlt: I didn't get to play with it directly myself yet |
| 11:06 |
bshum |
But I'm always happy to test and merge stuff that people push my way |
| 11:07 |
kmlussier |
Yeah, if I were proposing anything, it's probably that bugs get worked on. :) I know core committers are busy, but one or two bugs a month seems reasonable to me. |
| 11:30 |
csharp |
gmcharlt: I'll take a look |
| 11:33 |
gmcharlt |
csharp: great! |
| 11:41 |
pinesol_green |
[evergreen|Kathy Lussier] LP#1673891: Fix untranslatable strings in metarecord sibling links - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=943f2e8> |
| 11:49 |
|
khuckins__ joined #evergreen |
| 12:06 |
|
Bmagic joined #evergreen |
| 12:09 |
berick |
dbwells++ |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:13 |
|
sandbergja joined #evergreen |
| 12:14 |
csharp |
gmcharlt: https://bugs.launchpad.net/evergreen/+bug/1669868/comments/3 |
| 12:14 |
pinesol_green |
Launchpad bug 1669868 in Evergreen ""make check" failure" [High,Confirmed] |
| 12:29 |
kmlussier |
csharp++ |
| 12:30 |
* dbs |
wanders in, wonders if migrating launchpad processes to a more laissez-faire github-or-similar system might be an option to avoid the whole targeting etc mess |
| 12:30 |
dbs |
but really just a drive-by thought |
| 12:34 |
|
jvwoolf1 joined #evergreen |
| 12:34 |
* kmlussier |
thinks dbs just volunteered for something. ;) |
| 12:36 |
dbs |
heh let's discuss it during the Reds game |
| 12:38 |
* dbs |
bookmarks https://github.com/johnf/github-issue-importer |
| 12:42 |
Dyrcona |
moving to github would make use more visible. |
| 12:42 |
Dyrcona |
s/use/us/ |
| 12:43 |
Dyrcona |
If I could stop making typos, I'd actually get something done. ;) |
| 12:44 |
csharp |
ugh - so adding an LDFLAG to fix 'make check' on 16.04 breaks it on 14.04 |
| 12:45 |
kmlussier |
:( |
| 12:45 |
csharp |
/usr/bin/ld: cannot find -lsubunit |
| 12:46 |
csharp |
it's possible adding these flags also breaks make check on jessie |
| 12:49 |
csharp |
okay - time for a new deb dependency :-) |
| 12:51 |
Dyrcona |
csharp: I was thinking of looking at that while I wait on a db dump to copy. Any particular distro? |
| 12:51 |
Dyrcona |
I have vms for jessie, wheezy, trusty, and xenial ready. |
| 12:53 |
csharp |
Dyrcona: jessie and wheezy (if we're still keeping wheezy alive) |
| 12:53 |
Dyrcona |
csharp: We are keeping wheezy alive for now. |
| 12:54 |
csharp |
I just updated the branch with a new dependency for ubuntu-trusty - probably necessary in wheezy too, but I don't know |
| 12:54 |
bshum |
He's more machine now than man. |
| 12:54 |
Dyrcona |
OK. Should I try without the branch and then with? |
| 12:55 |
* Dyrcona |
checks if he has enough free ram to start a vm locally. |
| 12:55 |
Dyrcona |
I forget, now...does everything have to be configured for make check? |
| 12:56 |
Dyrcona |
Wheezy is fresh, I don't even have a git clone on it. |
| 12:57 |
|
tspindler joined #evergreen |
| 13:01 |
csharp |
bshum++ |
| 13:01 |
csharp |
Dyrcona: I've been doing configure, make, then make check |
| 13:02 |
csharp |
(with 'make clean's as root in between runs) |
| 13:03 |
Dyrcona |
csharp: OK. |
| 13:16 |
kmlussier |
If anyone on the web team has tuits available, I've noticed that Jetpack is no longer publishing new blog posts to the Evergreen Google+ page. I looked at it a couple of weeks ago, but nothing obvious jumped out at me. |
| 13:23 |
Dyrcona |
FYI: make check for OpenSRF succeeds. |
| 13:34 |
Dyrcona |
csharp: Evergreen make check just works on Wheezy without the patch. I'll try with the patch. |
| 13:34 |
csharp |
Dyrcona: excellent |
| 13:35 |
miker |
berick: you have some time to talk about some aspects of offline+hatch? |
| 13:37 |
Dyrcona |
csharp: with the branch I get: /usr/bin/ld: cannot find -lsubunit |
| 13:37 |
Dyrcona |
Which makes sense, since subunit-dev is only installed on trusty. |
| 13:37 |
|
tspindler left #evergreen |
| 13:39 |
berick |
miker: i do |
| 13:39 |
* dbs |
hums "service workers + IndexedDB (https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers)" |
| 13:40 |
miker |
berick: sweet. topic for today: offline block list |
| 13:41 |
miker |
jumping right into the deep end, I think it's a bad idea for the browser itself to download the block list if hatch is available |
| 13:42 |
miker |
and, the access pattern for the block list in the offline interface won't match the {get|set}Item pattern that exists today |
| 13:43 |
miker |
so, I'd like hatch to grow 2 new things: 1) an API to be told to download the block list for itself (seem simple enough? just "GET /whatever") and 2) a fast access mechanism for "is this barcode blocked, and how?" ... SQLite? |
| 13:44 |
csharp |
Dyrcona: that's with jessie? |
| 13:44 |
Dyrcona |
Wheezy. |
| 13:45 |
Dyrcona |
I reverted the two two commits and make check works with just the additional flags, or without. |
| 13:45 |
Dyrcona |
I am going to comment on the bug. |
| 13:45 |
csharp |
good |
| 13:46 |
Dyrcona |
Well, I think we're going to need distro-specific changes for make check. |
| 13:46 |
berick |
miker: wading a little slower into the deep end, is the assumption that offline use requires hatch? or that hatch will improve the process? |
| 13:46 |
miker |
btw, I am planning to make use of the append() API to store offline xacts ... and, ideally, hatch would learn how to upload them itself and move them out of the way after doing so |
| 13:46 |
miker |
berick: well, I'm starting with a hatch-first mentality, because we have IndexedDB (as dbs mentioned :) ) for the block list in the worst case |
| 13:48 |
dbs |
Why not just let service workers do their job of syncing up once online access is restored? |
| 13:49 |
miker |
though offline file upload without hatch is looking ... unfriendly, at least in terms of unmediated upload (without some server rewriting) |
| 13:49 |
berick |
dbs: i was thinking about that too - offload the process by letting service workers do it in the background |
| 13:49 |
miker |
dbs: because in chrome, having a local network connection is the same as being "online" |
| 13:49 |
* berick |
can't comment on indexeddb yet -- need to read more |
| 13:50 |
miker |
"evergreen server down" is not "offline" to the browser, IOW |
| 13:51 |
berick |
i'm talking about service workers for fetching the offline file, not for uploading |
| 13:51 |
miker |
that's an option, sure |
| 13:53 |
miker |
in that case, hatch would still need some new API to insert new entries read by the browser into some searchable structure |
| 13:53 |
berick |
yeah, agreed there |
| 13:54 |
miker |
that would be a good abstraction for hatch/indexeddb |
| 13:54 |
berick |
yeah |
| 13:57 |
dbs |
miker: uh, the service worker intercepts network requests; and if a given request fails, then it can do something different (like store that request) |
| 13:57 |
dbs |
It has nothing to do with being online or offline |
| 13:57 |
dbs |
(other than when you're offline, your network requests are pretty much guaranteed to fail) |
| 13:58 |
berick |
miker: for append-able data, we probably need a way to tell hatch that a set of data (a given key, for example) should be treated as a stream / collection instead of a single JSON thing |
| 13:59 |
miker |
dbs: are you suggesting using a manifest to make everything that exists now offline-ready? that's not where I'm planning to go today |
| 14:00 |
miker |
berick: right, we could use a map keyed by barcode, or an sqlite table, or something similar. hidden behind a set of new message types |
| 14:01 |
* berick |
nods |
| 14:01 |
miker |
my thought with having hatch to the heavy lifting was to encapsulate everything there, only shove the block list into local storage if hatch wasn't available |
| 14:02 |
dbs |
miker: while it would be great to make everything offline-ready (and thus not having to have a separate offline interface at all), that's a pretty huge undertaking |
| 14:02 |
miker |
dbs: 'zackly :) |
| 14:03 |
dbs |
but if an offline-specific interface stored its requests in IndexedDB until such time as the service worker was successful in uploading them to the server, that would sense to me |
| 14:04 |
kmlussier |
rhamby: Do you think we could make the GPLS and GRPL jobs on our jobs board expired? http://evergreen-ils.org/jobs/ |
| 14:04 |
berick |
dbs: uploading them to the server is (with the current offline code) requries more coordination than just pushing the files, though. |
| 14:04 |
miker |
well, there's benefit in having a human involved, especially for multi-site libraries |
| 14:04 |
rhamby |
kmlussier: probably, let me look real quick |
| 14:05 |
berick |
i'm not worried about the uploading. i expect that will be pretty similar to how it works now. |
| 14:05 |
miker |
/especially/ especially for multi-day offline use (migrations, etc) |
| 14:06 |
berick |
dbs: does indexeddb require special permissions? is it available to any site? |
| 14:07 |
dbs |
berick: service workers require https |
| 14:07 |
miker |
berick: are you imagining creation of a blob and $http.post()? |
| 14:08 |
berick |
miker: yeah, somethign like that. hadn't gotten that far, I just assumed it would be do-able without to much fuss. |
| 14:08 |
rhamby |
kmlussier: done. I expired the GA PINES one for today but I think someone else deleted the other two. |
| 14:08 |
kmlussier |
Two? |
| 14:09 |
berick |
dbs: but it doesn't require an extension, app, configuration, etc. you just write some js and plop it into a service worker? |
| 14:09 |
berick |
and have the service worker relay data to the page script via dom messaging? |
| 14:10 |
dbs |
berick: pretty much |
| 14:10 |
dbs |
http://caniuse.com/#feat=indexeddb |
| 14:11 |
berick |
50M limit on chrome |
| 14:12 |
berick |
ditto firefox |
| 14:12 |
berick |
wonder how resilient the data is |
| 14:13 |
dbs |
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria |
| 14:14 |
dbs |
https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/offline-for-pwa for Chrome deets |
| 14:15 |
dbs |
""Persistent" storage is not automatically cleared when storage is low. The user needs to manually clear this storage (via browser settings). Chrome has been experimenting with support for Persistent Storage under an origin trial, and the latest news suggests it will be shipping in Chrome 55." (guess we'll see what happened now that we're at Chrome 56) |
| 14:16 |
berick |
and when it clears, it uses least-recently-used, so don't leave offline data in the db for weeks, i guess |
| 14:16 |
dbs |
Yeah, hook that bookmobile up once in a while |
| 14:17 |
jeff |
chrome's experimentation required that you have no fewer than 5 sites bookmarked, and the site wanting to use persistent storage had to be one of them... |
| 14:18 |
jeff |
with Chrome 55, the permission is denied unless the site is bookmarked (and the user has 5 or fewer bookmarks); the site has "high site engagement"; the site has been added to the home screen; or the site has push notifications enabled. |
| 14:18 |
jeff |
last one is probably the most reliable / sane. |
| 14:19 |
jeff |
https://developers.google.com/web/updates/2016/06/persistent-storage has more detail. |
| 14:20 |
jeff |
some discussion from last year on this subject: http://irc.evergreen-ils.org/evergreen/2016-11-03#i_274645 |
| 14:21 |
berick |
miker: as i've said before, my default will always be to avoid using hatch when reasonable to do so. if using indexeddb is a sane way to handle non-hatch sites, my preference would be to start there, then add hatch support as needed. |
| 14:21 |
berick |
as always, though, if we need hatch, we need it |
| 14:22 |
berick |
just looking at our offline block list, it's 7.2M today |
| 14:22 |
miker |
well, we need it for printing at the circ desk (nominally), right? |
| 14:22 |
berick |
that's a decent chunk of the 50M limit |
| 14:22 |
berick |
miker: if you only need 1 printer, not necessarily |
| 14:22 |
berick |
you can configure the browser to auto print and set it up how you want |
| 14:22 |
miker |
without headers/footers or popups? |
| 14:23 |
berick |
can those things not be controlled with the browser's print configuration? |
| 14:23 |
miker |
I don't see a "without the user intervening" option |
| 14:24 |
miker |
I may just not know how to make that happen, though |
| 14:24 |
miker |
looks like you have to start chrome with a couple flags |
| 14:25 |
miker |
it's unclear if you can do it without also being in kiosk mode (fullscreen) |
| 14:26 |
miker |
ok, looks like you might be able to, with --kiosk-printing |
| 14:27 |
miker |
so, maybe set up headers/footers by printing once, then add --kiosk-printing to the shortcut |
| 14:28 |
miker |
but, if you need to print to a receipt printer and also a full printer, you have to use the dialog, or hatch |
| 14:28 |
berick |
right |
| 14:29 |
berick |
arg, i have to step away for a bit. will return. |
| 14:29 |
pinesol_green |
[evergreen|Jillianne Presley] Docs: replacing XUL booking module screenshots with browser client ones - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c67fd7e> |
| 14:40 |
|
alynn26 joined #evergreen |
| 14:56 |
|
Christineb joined #evergreen |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:03 |
berick |
it's raining RM's! gmcharlt++ |
| 15:06 |
csharp |
gmcharlt++ |
| 15:07 |
csharp |
dbwells++ # I'm reading reverse chronologically :-) |
| 15:07 |
jeffdavis |
dbwells++ gmcharlt++ rings_with_hats_in_them++ |
| 15:08 |
berick |
booting_up_the_thunderdome++ |
| 15:09 |
berick |
(it runs on windows 98) |
| 15:09 |
csharp |
https://www.youtube.com/watch?v=tajDxBaPBBM |
| 15:09 |
berick |
you've got mail! |
| 15:10 |
|
kmlussier joined #evergreen |
| 15:11 |
berick |
miker: another thought, assuming a non-hatch version of offline is viable, starting there lowers the barrier to entry for broader testing. |
| 15:12 |
miker |
it does, certainly. (sans printing stuff above) |
| 15:36 |
|
hbrennan joined #evergreen |
| 15:39 |
|
Jillianne joined #evergreen |
| 15:40 |
Dyrcona |
gmcharlt | csharp: https://bugs.launchpad.net/evergreen/+bug/1669868/comments/9 |
| 15:40 |
pinesol_green |
Launchpad bug 1669868 in Evergreen ""make check" failure" [High,Confirmed] |
| 15:40 |
Dyrcona |
I developed that on Ubuntu 16.04. I'll test on wheezy, jessie, and trusty next. |
| 15:41 |
gmcharlt |
Dyrcona: thanks |
| 15:48 |
Dyrcona |
Works for me on jessie. |
| 15:51 |
Dyrcona |
Works on wheezy. |
| 15:52 |
Dyrcona |
Really? that only took 3 minutes? |
| 15:53 |
Dyrcona |
trusty will take longer. I have to install prereqs and OpenSRF. |
| 16:01 |
|
khuckins_ joined #evergreen |
| 16:08 |
Dyrcona |
It would probably go a bit faster if cpan hadn't decided to use a mirror in Indonesia. |
| 16:14 |
bshum |
Dyrcona: Your fix worked for me on Xenial and Trusty |
| 16:15 |
Dyrcona |
Thanks for checking. You could signoff if you feel so inclined. :) |
| 16:15 |
bshum |
I could sign off and push it, sure |
| 16:16 |
Dyrcona |
Well, I think gmcharlt wants to look at it, maybe. I know the release is tomorrow and he's building it. |
| 16:16 |
bshum |
Gotcha |
| 16:16 |
bshum |
I'll just sign it then :) |
| 16:16 |
gmcharlt |
yeah, I glanced at the patch but will push it tomorrow |
| 16:17 |
Dyrcona |
I think it's the right thing. Basically a copy and paste from OpenSRF's configure.ac. |
| 16:17 |
|
sandbergja joined #evergreen |
| 16:26 |
|
bshum joined #evergreen |
| 16:27 |
|
mmorgan joined #evergreen |
| 16:52 |
bshum |
Taco time :) See you guys later... |
| 17:00 |
Dyrcona |
I ..am.. outta here! |
| 17:00 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:09 |
|
mmorgan left #evergreen |
| 17:10 |
|
khuckins joined #evergreen |
| 17:11 |
* kmlussier |
heads out to get pizza. |
| 17:12 |
csharp |
Dyrcona++ |
| 18:07 |
|
gsams joined #evergreen |
| 20:12 |
pinesol_green |
[evergreen|Ben Shum] Docs: README to include Debian for changing ownership of /var/lock/apache2 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=81a57b2> |
| 21:36 |
bshum |
Hmm |
| 21:36 |
bshum |
Random thoughts |
| 21:36 |
bshum |
1) in responsive design, there's no filter for changing locales |
| 21:36 |
bshum |
It's hidden |
| 21:37 |
bshum |
So that needs to get added somewhere, somehow, someday |
| 21:37 |
bshum |
Well, it'd be nice |
| 21:39 |
bshum |
2) might need something to handle the adv_filter_results_group direction for RTL vs. LTR to organize the content accordingly to the direction the text flows. |
| 21:39 |
bshum |
As is, it always presents filter type and content as LTR |
| 21:41 |
bshum |
3) after doing an advanced search in one locale and then clicking a locale swap, we get a bad ARRAY(xxxxx) search that results in zero hits, instead of just swapping languages |
| 21:41 |
bshum |
And you lose your original parameters, of course |
| 21:41 |
bshum |
I'll type some of this stuff up into relevant LP |
| 21:51 |
bshum |
Ah, yup, locale_picker_form is set to display: none; in mobile CSS. Hmm, guess we'll have to think of somewhere good to put that. |
| 21:58 |
bshum |
I think I'm really starting to enjoy the nginx proxy :) |
| 23:56 |
|
bshum joined #evergreen |
