| Time |
Nick |
Message |
| 00:39 |
|
jvwoolf joined #evergreen |
| 00:39 |
|
Jillianne joined #evergreen |
| 00:55 |
|
Jillianne2 joined #evergreen |
| 03:24 |
|
Jillianne joined #evergreen |
| 05:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 06:15 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: Release notes for 2.11.7 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c4d9cb3> |
| 06:15 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.12.4 Release Notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d83dc5e> |
| 07:18 |
|
rjackson_isl joined #evergreen |
| 08:15 |
|
collum joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:47 |
|
kmlussier joined #evergreen |
| 09:00 |
|
_adb joined #evergreen |
| 09:02 |
kmlussier |
Bmagic / dbwells: I'm going to be on vacation during the next maintenance release day in August. I can have release notes done the previous Friday if you want to continue with that day. Or we can reschedule it for a week later. |
| 09:04 |
|
mmorgan1 joined #evergreen |
| 09:19 |
Bmagic |
kmlussier: Vacations are so important |
| 09:20 |
kmlussier |
Bmagic: Yes, they are! I'm looking forward to it. I'll be visiting colleges with my son on our regularly-scheduled release day. :) |
| 09:21 |
Bmagic |
That sounds like fun! As far as the release schedule, I don't think a week later would hurt anything |
| 09:22 |
Bmagic |
I wouldn't rush the release notes, but it's up to you |
| 09:25 |
kmlussier |
Bmagic: If you and dbwells are available to cut the release on August 23, then it might be better, especially since this month's release was a week later than usual. |
| 09:26 |
kmlussier |
If not, we would just need to make sure there is somebody available to 1) update the release notes for anything merged earlier in the week and 2) make an announcement. |
| 09:26 |
kmlussier |
I could probably find somebody to do the former. |
| 09:27 |
Bmagic |
yep, it looks clear |
| 09:27 |
dbwells |
kmlussier: August 23 sounds fine to me. |
| 09:28 |
kmlussier |
OK, I'll update the calendar then. Bmagic++ dbwells++ |
| 09:33 |
|
Dyrcona joined #evergreen |
| 09:37 |
Dyrcona |
So, is the hack-a-way November 7-9? I can't find any announcement of the actual dates in my email. |
| 09:40 |
|
mmorgan joined #evergreen |
| 09:41 |
|
jvwoolf joined #evergreen |
| 09:50 |
|
maryj joined #evergreen |
| 09:50 |
|
maryj_ joined #evergreen |
| 09:54 |
Bmagic |
Dyrcona: I'm not certain it's been firmed up |
| 09:54 |
Bmagic |
rhamby: ? |
| 09:55 |
rhamby |
still working with EG Indiana on it, I'll get an update and send it out though. They've had some wrenches thrown in the gears but they've been working to resolve them diligantly. |
| 09:59 |
rhamby |
I should have some information out on 2018 soon too. I have a little prodding to do on it still. |
| 10:09 |
|
maryj joined #evergreen |
| 10:42 |
Dyrcona |
Thanks, rhamby. |
| 11:02 |
|
collum joined #evergreen |
| 11:03 |
Bmagic |
Anyone know where the spine label code pulls the %publisher% data from? 260c? 008? |
| 11:14 |
Dyrcona |
Bmagic: If you want one, it's probably the other. ;) |
| 11:14 |
Bmagic |
I tried both |
| 11:15 |
Dyrcona |
Is there a date in the 240? |
| 11:15 |
Dyrcona |
@marc 240 |
| 11:15 |
pinesol_green |
Dyrcona: The uniform title for an item when the bibliographic description is entered under a main entry field that contains a personal (field 100), corporate (110), or meeting (111) name. [a,d,f,g,h,k,l,m,n,o,p,r,s,6,8] |
| 11:15 |
Dyrcona |
No.... I'm thinking of the 260.... |
| 11:15 |
Dyrcona |
:) |
| 11:16 |
bshum |
It's probably coming off the reporter view |
| 11:16 |
bshum |
Which should grab from 260 or 264 (if it's RDA), but /shrug, maybe not |
| 11:17 |
Dyrcona |
Yeah, I've never been very familiar with the template/macro code. |
| 11:26 |
|
Christineb joined #evergreen |
| 11:28 |
|
mmorgan1 joined #evergreen |
| 11:31 |
kmlussier |
Does anyone know if the permission check mentioned here was filed as a new bug in LP? https://bugs.launchpad.net/evergreen/+bug/1671596/comments/6 |
| 11:31 |
pinesol_green |
Launchpad bug 1671596 in Evergreen "Web client: Adjust to zero option is missing from web client" [Medium,Fix committed] |
| 11:31 |
* kmlussier |
doesn't see anything, but wanted to check before filing one. |
| 11:35 |
Bmagic |
Dyrcona: I am looking for the name of the publisher. Like "New York" |
| 11:37 |
Bmagic |
Got it, After changing the MARC, you have to reload the spine label interface |
| 11:47 |
|
mmorgan joined #evergreen |
| 11:57 |
|
remingtron joined #evergreen |
| 12:23 |
|
jihpringle joined #evergreen |
| 12:53 |
kmlussier |
miker: Do you have any thoughts on where we can dig further to try to diagnose the problem we see in bug 1704396? |
| 12:53 |
pinesol_green |
Launchpad bug 1704396 in Evergreen "Slowness for metecord and one-hit searches in 2.12" [High,New] https://launchpad.net/bugs/1704396 |
| 13:01 |
|
mmorgan1 joined #evergreen |
| 13:12 |
* miker |
looks |
| 13:21 |
|
mmorgan joined #evergreen |
| 13:23 |
|
mmorgan2 joined #evergreen |
| 13:27 |
miker |
kmlussier: so, it "sticks" for 70s, but, after that time, are the results properly rendered? |
| 13:29 |
kmlussier |
miker: For the group formats and editions example, the one result that caused the problem is missing the record id from the link. For the one-hit search example, usually, the record appears after the slowdown. |
| 13:29 |
miker |
(btw, it's def started with https://bugs.launchpad.net/evergreen/+bug/1629108 |
| 13:29 |
pinesol_green |
Launchpad bug 1629108 in Evergreen "Metarecord constituents search result page should use standard search code" [Wishlist,Fix released] |
| 13:29 |
kmlussier |
Sometimes, they get an Internal Server error, but that's rare. |
| 13:39 |
miker |
not that that commit caused it, per se, but that's when it surfaced for the metabib stuff |
| 13:45 |
kmlussier |
miker: Yes, that had been one place I was looking. |
| 13:47 |
kmlussier |
One reason we started to link the two problems (if they are indeed linked) is because mmorgan was also noticing in the logs for the one-hit problems that it seemed to be running through mr routines even though they weren't mr searches. |
| 13:48 |
miker |
yeah, that's strange ... looking for the one-hit entry now |
| 13:48 |
* kmlussier |
runs out for a bit to grab lunch. |
| 13:57 |
miker |
hrm ... the timelog on the LP ticket does not seem to match what's actually in the rel_2_12 codebase... the strings are different |
| 14:10 |
miker |
scratch that... the log is from the record loading page, not the search loading page |
| 14:11 |
miker |
slowdown seems to happen in open-ils.search.multi_home.bib_ids.by_barcode |
| 14:12 |
miker |
which, in this case, makes to cstore calls: one to look up the copy by barcode, and a followup to retrieve the peer bibs for the copy |
| 14:18 |
miker |
if, for some reason, there was an error in the first cstore call (say, no barcode passed because of a failure in a preceding call, returning an error or "0" instead of a list of copies) I could see something like this happening |
| 14:18 |
* miker |
looks at mk_copy_query |
| 14:34 |
|
Jillianne joined #evergreen |
| 14:37 |
miker |
kmlussier: btw, the reason the bottom of the timelog on the test has the unapi.mmr stuff is for linking to other constituent records |
| 14:42 |
kmlussier |
miker: That makes sense. I'm beginning the think they may be different issues after all. |
| 14:43 |
miker |
well... we don't have a log for the metarecord 1-hit issue, but I bet it's essentially the same. and all signs in that timelog point to open-ils.search.multi_home.bib_ids.by_barcode |
| 14:47 |
* kmlussier |
could easily supply a log for that issue if it's helpful. |
| 14:47 |
kmlussier |
I find that issue is easier to re-create. |
| 14:47 |
miker |
kmlussier: for you generally, or on a particular server? |
| 14:48 |
miker |
and if we can get more timelogs for that actually happening, that would be perfect. |
| 14:48 |
miker |
because it may not be that method, but, say, cstore or search backend starvation |
| 14:49 |
miker |
(you're not seeing any "no children" errors, right? |
| 14:49 |
kmlussier |
I've been able to easily replicate it on a few servers. But I only have access to the logs on one. |
| 14:49 |
kmlussier |
Possibly two. |
| 14:50 |
miker |
LP bug updated with a couple requests |
| 14:53 |
miker |
(and one more request for log checking added) |
| 14:54 |
kmlussier |
miker++ #Thanks for taking the time to look at it! |
| 14:59 |
mmorgan2 |
miker++ |
| 15:03 |
|
mmorgan1 joined #evergreen |
| 15:04 |
miker |
happy to :) |
| 16:42 |
|
mmorgan joined #evergreen |
| 17:01 |
pinesol_green |
News from qatests: Test Success <http://testing.evergreen-ils.org/~live> |
| 17:04 |
|
mmorgan left #evergreen |
| 17:18 |
|
jvwoolf left #evergreen |
| 17:23 |
pinesol_green |
[evergreen|Dan Wells] Forward port 2.11.7 upgrade script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=df5b68d> |
| 18:40 |
|
sallyf joined #evergreen |
| 18:40 |
|
drigney joined #evergreen |
| 18:40 |
|
abneiman_ joined #evergreen |
| 18:40 |
|
gsams_ joined #evergreen |
| 18:40 |
|
fbeaudry_ joined #evergreen |
| 19:31 |
|
jvwoolf joined #evergreen |
| 19:32 |
|
jvwoolf left #evergreen |
| 21:53 |
|
jvwoolf joined #evergreen |
