| Time |
Nick |
Message |
| 00:33 |
|
krvmga joined #evergreen |
| 05:39 |
|
dkyle joined #evergreen |
| 05:42 |
|
64MAAZQJI joined #evergreen |
| 05:42 |
|
64MAAZQJI left #evergreen |
| 06:19 |
chreeus |
a5d2ba32 |
| 06:19 |
chreeus |
pinesol_green? |
| 06:19 |
chreeus |
@dunno |
| 06:19 |
pinesol_green |
chreeus: I see nothing, I know nothing! |
| 06:19 |
chreeus |
pinesol_green: obviously |
| 06:19 |
pinesol_green |
chreeus: Sorry, we can't do that because, you know, SOFTWARE. |
| 06:19 |
pinesol_green |
Factoid 'obviously' not found |
| 06:35 |
jeff |
commit a5d2ba32 |
| 06:36 |
jeff |
maybe a working repo commit? i don't recall if pinesol_green reacts to those. |
| 06:40 |
|
rlefaive joined #evergreen |
| 06:44 |
kmlussier |
hmmmm |
| 06:46 |
kmlussier |
chreeus: On bug 1541801, we noticed the same issue in the web client when we were testing Z39.50. |
| 06:46 |
pinesol_green |
Launchpad bug 1541801 in Evergreen "search fields in z39.50 sort in random order" [Undecided,New] https://launchpad.net/bugs/1541801 |
| 06:47 |
kmlussier |
chreeus: I wonder if work on the web client caused the change in the xul client interface |
| 07:02 |
chreeus |
kmlussier: that's our theory |
| 07:03 |
bshum |
chreeus, jeff: right pinesol doesn't track working |
| 07:04 |
bshum |
I think it was mostly a matter of avoiding double reporting since it would likely spit back master changes in both repos |
| 07:05 |
bshum |
Never quite tested beyond that. |
| 07:06 |
kmlussier |
Using working to look up commits would be useful. Getting an announcment every time somebody pushes a branch to working? Not so much. |
| 07:06 |
bshum |
Hmm |
| 07:10 |
bshum |
kmlussier: Well what would happen is that it would only announce master changes |
| 07:11 |
bshum |
Which is not helpful cause it would do so for the main repo too |
| 07:11 |
bshum |
So we'd have like double announcing every commit |
| 07:11 |
bshum |
Once from origin and once from working |
| 07:11 |
chreeus |
a5d2ba32 |
| 07:11 |
chreeus |
nope - that's in master |
| 07:11 |
chreeus |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a5d2ba3273d03300e7d9137a1a0317fef730839d |
| 07:11 |
bshum |
@git repolist |
| 07:11 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 07:11 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 07:11 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
| 07:12 |
kmlussier |
bshum: gotcha |
| 07:12 |
chreeus |
5dd2ae5ac |
| 07:12 |
pinesol_green |
[evergreen|Thomas Berezansky] Rip modal_xulG_stack out, replace with openDialog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5dd2ae5> |
| 07:13 |
chreeus |
hmm |
| 07:13 |
chreeus |
randomly chosen hash |
| 07:13 |
bshum |
I just initiated a rehash (aka, repull) |
| 07:13 |
chreeus |
ah |
| 07:13 |
bshum |
Give it a sec, maybe it'll catch up |
| 07:13 |
bshum |
I think lupin got confused with the webstaff merge |
| 07:13 |
chreeus |
well, it's not a new commit |
| 07:14 |
bshum |
a5d2ba3273d03300e7d9137a1a0317fef730839d |
| 07:14 |
pinesol_green |
[evergreen|Dan Pearl] LP#827442 Z39.50 will split the total cap between locations when multiple locations selected - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a5d2ba3> |
| 07:14 |
bshum |
a5d2ba327 |
| 07:14 |
pinesol_green |
[evergreen|Dan Pearl] LP#827442 Z39.50 will split the total cap between locations when multiple locations selected - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a5d2ba3> |
| 07:14 |
bshum |
Need more chars |
| 07:14 |
chreeus |
7 is usually enough, right? |
| 07:14 |
bshum |
Weird |
| 07:14 |
bshum |
a5d2ba3 |
| 07:14 |
pinesol_green |
[evergreen|Dan Pearl] LP#827442 Z39.50 will split the total cap between locations when multiple locations selected - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a5d2ba3> |
| 07:14 |
bshum |
Less is enough usually |
| 07:14 |
bshum |
Cause it's the short string too |
| 07:14 |
chreeus |
I'm usually able to copy from git blame and see the commit |
| 07:14 |
kmlussier |
chreeus: there have been a couple of times when I've had to go higher than 7. |
| 07:14 |
bshum |
Maybe the rehash helped |
| 07:15 |
chreeus |
bshum++ |
| 07:15 |
* bshum |
blames poor lupin's lack of mem |
| 07:15 |
chreeus |
bshum: we can totally fix that |
| 07:15 |
kmlussier |
bshum++ |
| 07:15 |
chreeus |
we will soon have a new mundungus with much more in the way of host resources |
| 07:15 |
kmlussier |
chreeus: So maybe not related to the web client work after all. |
| 07:16 |
chreeus |
kmlussier: well, that commit was in 2.7.2, so I think we can rule it out |
| 07:17 |
bshum |
@unload git |
| 07:17 |
pinesol_green |
bshum: The operation succeeded. |
| 07:17 |
bshum |
@load git |
| 07:17 |
chreeus |
I was just looking at the most recent changes to see if anything jumped out |
| 07:17 |
bshum |
Hmm |
| 07:17 |
* chreeus |
has to run take his son to school |
| 07:17 |
bshum |
Uh oh :) |
| 07:17 |
pinesol_green |
bshum: The operation succeeded. |
| 07:17 |
chreeus |
whew |
| 07:18 |
bshum |
@git repolist |
| 07:18 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 07:18 |
pinesol_green |
bshum: evg-working (Evergreen-Working, branch: master) |
| 07:18 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 07:18 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
| 07:18 |
bshum |
I'm going to test an idea |
| 07:18 |
bshum |
and try asking it to track another branch for announce |
| 07:18 |
bshum |
if it works anyways |
| 07:19 |
bshum |
@git repolist |
| 07:19 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 07:19 |
pinesol_green |
bshum: evg-working (Evergreen-Working, branch: master) |
| 07:19 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 07:19 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
| 07:19 |
bshum |
Darn |
| 07:19 |
* bshum |
undos and ponders that some more before he heads to work |
| 07:20 |
bshum |
@unload Git |
| 07:20 |
pinesol_green |
bshum: The operation succeeded. |
| 07:20 |
bshum |
@load Git |
| 07:20 |
pinesol_green |
bshum: The operation succeeded. |
| 07:20 |
bshum |
@git repolist |
| 07:20 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 07:20 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 07:20 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
| 07:23 |
bshum |
@git reload |
| 07:23 |
pinesol_green |
bshum: Have you confirmed your ISBN SPIDs with your service provider? |
| 07:23 |
bshum |
@reload Git |
| 07:23 |
pinesol_green |
bshum: The operation succeeded. |
| 07:23 |
bshum |
@git repolist |
| 07:23 |
pinesol_green |
bshum: evergreen (Evergreen, branch: master) |
| 07:23 |
pinesol_green |
bshum: evergreen-working (Evergreen-Working, branch: welcome-kmlussier) |
| 07:23 |
pinesol_green |
bshum: opensrf (OpenSRF, branch: master) |
| 07:24 |
pinesol_green |
bshum: sipserver (SIPServer, branch: master) |
| 07:24 |
bshum |
86acb601a1f38ec762b419f6e69f3ba4605f6b6b |
| 07:24 |
bshum |
Well, darn |
| 07:27 |
chreeus |
5dd2ae5ac |
| 07:27 |
pinesol_green |
[evergreen|Thomas Berezansky] Rip modal_xulG_stack out, replace with openDialog - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=5dd2ae5> |
| 07:32 |
bshum |
86acb601a1f38ec762b419f6e69f3ba4605f6b6b |
| 07:32 |
bshum |
Well that is most odd |
| 07:32 |
bshum |
it should have picked up on the changes for working. Oh well. |
| 07:32 |
bshum |
Have to experiment further later |
| 07:38 |
|
JBoyer joined #evergreen |
| 07:52 |
|
phasefx__ joined #evergreen |
| 08:02 |
|
Stompro joined #evergreen |
| 08:04 |
|
ericar joined #evergreen |
| 08:31 |
|
mrpeters joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:39 |
|
mmorgan joined #evergreen |
| 08:51 |
Dyrcona |
Don't even know why I still have an office phone. |
| 08:51 |
Dyrcona |
All I get are scam calls. |
| 08:52 |
Dyrcona |
I get maybe one legitimate call every two weeks. |
| 08:53 |
jeff |
send all unknown callers to voicemail? :-) |
| 08:53 |
jeff |
(unknown as in, "not on my list of approved or internal callers") |
| 08:54 |
Dyrcona |
I don't answer. |
| 08:54 |
Dyrcona |
I received a voice mail about making $10,000/week after hours last night. That's what prompted the comment. |
| 08:54 |
jeff |
ah. |
| 08:55 |
Dyrcona |
We have VOIP and there's some interface on the web where I can block numbers. |
| 08:55 |
Dyrcona |
They never call more than twice from the same number, so that seems pointless. |
| 08:56 |
Dyrcona |
In general, I don't answer unless I know the number/caller id or it looks reasonably local. |
| 08:57 |
Dyrcona |
Why is it we humans manage to ruin everything? |
| 08:58 |
Dyrcona |
Ok. I'll stop before I depress myself. :) |
| 09:00 |
* Dyrcona |
gets to spend most of his day in meetings. |
| 09:01 |
* jeff |
waits for Dyrcona's next line to be a repeatof "Why is it we humans manage to ruin everything?" |
| 09:01 |
Dyrcona |
:) |
| 09:02 |
|
jwoodard joined #evergreen |
| 09:03 |
chreeus |
humans ruining everything: https://youtu.be/XvuM3DjvYf0?t=58s |
| 09:06 |
Dyrcona |
chreeus++ classic! |
| 09:07 |
chreeus |
oh, I forgot... SPOILERS |
| 09:13 |
Dyrcona |
Hah! |
| 09:15 |
kmlussier |
Heh...we just watched this movie a couple of weeks ago. The look on my daughter's face when we got to that scene was priceless. |
| 09:33 |
|
yboston joined #evergreen |
| 09:35 |
|
maryj joined #evergreen |
| 09:44 |
JBoyer |
Dyrcona++ |
| 09:45 |
JBoyer |
Thanks for the help yesterday re: deadlocks, we were able to load 100K+ records in an hour or so in our test, migrations here are going to look at a lot different in the future. |
| 09:45 |
JBoyer |
look a lot. I try not to look directly into the operational end of a migration in progress.. |
| 09:46 |
jeff |
JBoyer: ``Do not look into laser with remaining good eye.'' |
| 09:47 |
JBoyer |
I feel like I should know that, but it's not coming to me. |
| 09:52 |
jeff |
no specific reference, just an oft repeated humorous warning in some circles. |
| 09:52 |
jeff |
sci.electronics.repair FAQ says ``A popular graveyard joke in the laser industry is: "Do not stare into the beam with your remaining good eye". Another one is: "How many times can I look into a laser beam?". Answer: "Twice, once left, once right".'' |
| 09:53 |
Dyrcona |
jeff++ |
| 09:53 |
chreeus |
jeff++ |
| 09:53 |
* Dyrcona |
has a smile, now. |
| 09:58 |
* Dyrcona |
enters the first meeting for the day. |
| 09:59 |
miker |
JBoyer: what was your final combination of settings and processing steps for the import? |
| 10:02 |
JBoyer |
miker: 3 internal flags are to true (Not a fan of negative logic...) ingest.metarecord_mapping.skip_on_insert, ingest.disable_authority_linking, and ingest.assume_inserts_only. |
| 10:03 |
JBoyer |
then we split up the bib data that's normally \copy'd in into sets of ~100 rows and fire off 15 simultaneous processes each \copy-ing different files in. |
| 10:04 |
Dyrcona |
JBoyer: Sounds reasonable. |
| 10:04 |
JBoyer |
Then the settings are put back to normal, and the fast_metarecord_mapping.sql script and the authority_control_fields.pl is run for just the new records. |
| 10:04 |
JBoyer |
(and the BRE sequence is updated at some point so new records will work as expected) |
| 10:05 |
Dyrcona |
When I did our migration, I did 7 simultaneous batches of 10,000 records each. |
| 10:05 |
miker |
JBoyer: cool. matches our basic process as well, fwiw |
| 10:05 |
JBoyer |
Good to hear that we're not treading new ground, sometimes there be monsters. |
| 10:06 |
|
Christineb joined #evergreen |
| 10:06 |
JBoyer |
I'm worried what this will do to slony though, it'll be a hell of a catchup. |
| 10:07 |
JBoyer |
As long as it doesn't cause some kind of corruption to the slony tables I assume it will do it's thing given enough time. |
| 10:15 |
chreeus |
JBoyer: you will love the simplicity and reliability of streaming replication when you finally get there (it's even better in 9.4) |
| 10:15 |
* chreeus |
was happy to leave slony behind |
| 10:16 |
JBoyer |
Oh, I remember how nice it was for about a week, until it was unable to keep up over a 100Mb connection and my 3rd db threw a shoe. :) Once everything is in a single datacenter, or all 3 dbs share a similar level of oomph I'll try again. |
| 10:24 |
JBoyer |
chreeus: I had just made some notes for myself this time on the best way to get slony going (for the last 2-3 upgrades it |
| 10:25 |
JBoyer |
's been "TIME TO MAKE THE DOUGHNUTS, HOW TO DO?" every time I needed to set it back up...) |
| 10:25 |
JBoyer |
Completely unrelated news: This morning I tracked down the application guide for a temp/humidity sensor I've been looking for and I haven't been this excited to play around with code since I was playing with OpenGL in my college dorm room. |
| 10:32 |
|
collum joined #evergreen |
| 11:28 |
|
sandbergja joined #evergreen |
| 11:30 |
pinesol_green |
[opensrf|Mike Rylander] LP#1494486: Limit damage caused by dropped drone XMPP sockets - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=5580724> |
| 11:36 |
pinesol_green |
[opensrf|Jason Etheridge] LP#1474507: fix interval_to_seconds for weeks and seconds - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=69cbe80> |
| 11:36 |
pinesol_green |
[opensrf|Jason Etheridge] LP#1474507: tests for interval_to_seconds - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=7a714ae> |
| 11:40 |
|
mllewellyn joined #evergreen |
| 11:59 |
|
bmills joined #evergreen |
| 12:01 |
kmlussier |
@coffee |
| 12:01 |
* pinesol_green |
brews and pours a cup of Kenya AA Gachatha, and sends it sliding down the bar to kmlussier |
| 12:02 |
gmcharlt |
tossing this out here - I've been working on OpenSRF pull requests for cutting a 2.4.2 later this month |
| 12:02 |
* berick |
was just reading the bug emails |
| 12:02 |
berick |
gmcharlt++ |
| 12:02 |
gmcharlt |
and I think bug 1485371 will be worth also starting a 2.5 branch and a 2.5.0 milestone |
| 12:02 |
pinesol_green |
Launchpad bug 1485371 in OpenSRF "Use client TZ when supplied to the server" [Wishlist,New] https://launchpad.net/bugs/1485371 |
| 12:03 |
gmcharlt |
with the idea that if bug 1485374 gets finalized in time for 2.10 (which is seeming more likely), that OpenSRF 2.5.0 would be a dependency for EG 2.10 |
| 12:03 |
pinesol_green |
Launchpad bug 1485374 in Evergreen "Use client TZ in the database when supplied to the server" [Wishlist,New] https://launchpad.net/bugs/1485374 |
| 12:03 |
gmcharlt |
thoughts? |
| 12:05 |
jeff |
sounds reasonable. |
| 12:05 |
JBoyer |
+1 from me on OSRF 2.5 for the TZ change and EG 2.10 dependency. |
| 12:07 |
berick |
+1 |
| 12:07 |
|
jihpringle joined #evergreen |
| 12:14 |
gsams |
JBoyer++ #for CollectionHQ stuff |
| 12:14 |
gsams |
was easy to implement, I appreciate it |
| 12:15 |
jeff |
JBoyer: did they ever get back to you on in-house use counts? |
| 12:15 |
JBoyer |
I only made minor changes, unless you're ++ing the fact that the changes merge cleanly into ESI's contrib repo. :) |
| 12:15 |
jeff |
JBoyer: i'd rather we all use similar format than have them just tweak ours and tweak yours and tweak someone else's... |
| 12:16 |
JBoyer |
jeff: I can't remember anymore. I can't remember if the code even looks at them. |
| 12:16 |
jeff |
thanks. i'll review later. |
| 12:17 |
JBoyer |
I know I'm not currently waiting to hear from them, so things must have resolved themselves, in a manner of speaking. ;) |
| 12:17 |
jeff |
noted. |
| 12:30 |
JBoyer |
jeff: remind me what the question was on that front, whether or not to include them, or where? |
| 12:30 |
JBoyer |
(it doesn't look at them, though it does count aged and legacy circs) |
| 12:35 |
|
jvwoolf joined #evergreen |
| 12:36 |
Dyrcona |
+1 on OpenSRF 2.5 |
| 12:36 |
jeff |
we were planning to add support to include them, and we expected to include them as an additional field. i think their plan was to fold them into the circ numbers. |
| 12:40 |
|
mllewellyn joined #evergreen |
| 12:40 |
|
Bmagic joined #evergreen |
| 12:51 |
JBoyer |
Ah, makes sense. |
| 13:12 |
pinesol_green |
[opensrf|Galen Charlton] LP#1350457: add test case for perl2JSONObject change - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=b6cf3eb> |
| 13:12 |
pinesol_green |
[opensrf|Mike Rylander] LP#1350457: Pass caller's session to subrequests called via method_lookup - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=e1581d4> |
| 13:36 |
* chreeus |
wonders if the addition of UPC to the fields in commit 2038e93a caused weird sorting in bug 1541801 |
| 13:36 |
pinesol_green |
Launchpad bug 1541801 in Evergreen "search fields in z39.50 sort in random order" [Medium,Confirmed] https://launchpad.net/bugs/1541801 |
| 13:36 |
pinesol_green |
[evergreen|Josh Stompro] LP#1519925 - Allow MARC Federated Search to search UPC index of local catalog. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2038e93> |
| 13:38 |
Dyrcona |
I didn't notice anything strange, but you could revert that commit and see what happens. |
| 13:44 |
Dyrcona |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blobdiff;f=Open-ILS/src/perlmods/lib/OpenILS/Application/Search/Z3950.pm;h=cff8c6ffe3760bf99093394603f81728a3dd3fe8;hp=a5a4f6c9c47ee46ca601693993e86edf87fedcfe;hb=2038e93;hpb=d3dd07c63e90a79be88213a540a35861e939d524 |
| 13:44 |
pinesol_green |
[evergreen|Josh Stompro] LP#1519925 - Allow MARC Federated Search to search UPC index of local catalog. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2038e93> |
| 13:44 |
pinesol_green |
[evergreen|Ben Shum] Docs: fix typo for version upgrade 2.8.4-2.9.0 in server upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d3dd07c> |
| 13:45 |
Dyrcona |
That *might* have done it. Adding a member to the hash could affect the ordering of the keys. |
| 13:45 |
Dyrcona |
I would expect it to always be the same, though. |
| 13:45 |
Dyrcona |
Not changing randomly. |
| 13:53 |
yboston |
heads up, the DIG monthly meeting will be starting at 2 PM EST |
| 13:58 |
jeff |
chreeus: is there a perl version difference between your 2.7.2 and 2.9.1 servers? |
| 13:59 |
jeff |
(but yes, as Dyrcona mentioned you could try reverting the suspect commit) |
| 14:00 |
yboston |
#startmeeting DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting |
| 14:00 |
pinesol_green |
Meeting started Thu Feb 4 14:00:41 2016 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 14:00 |
pinesol_green |
The meeting name has been set to 'dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting' |
| 14:00 |
yboston |
The agenda can be found here http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:dig_meeting_20160204-agenda |
| 14:01 |
yboston |
#topic Introductions |
| 14:01 |
Christineb |
#info ChristineB is Christine Burns BC Libraries Cooperative / Sitka |
| 14:01 |
yboston |
Please feel free to start introducing yourselves... |
| 14:01 |
yboston |
#info yboston is Yamil Suarez @ Berklee College of Music - DIG meeting facilitator |
| 14:01 |
jihpringle |
#info jihpringle is Jennifer Pringle, BC Libraries Cooperative (Sitka) |
| 14:01 |
sandbergja |
#info sandbergja is Jane Sandberg, Linn-Benton Community College |
| 14:01 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 14:02 |
yboston |
let's begin |
| 14:02 |
|
jlundgren joined #evergreen |
| 14:03 |
remingtron |
yboston: FYI, I just added an item under New Business to the wiki agenda |
| 14:03 |
remingtron |
(sorry for late addition!) |
| 14:03 |
yboston |
#topic past meeting action items |
| 14:03 |
yboston |
(no worries) |
| 14:03 |
yboston |
#info jihpringle will research the state of missing RDA content |
| 14:03 |
yboston |
any updates or should I defer? |
| 14:04 |
jihpringle |
please defer |
| 14:04 |
yboston |
no problem |
| 14:04 |
yboston |
#action jihpringle will research the state of missing RDA content |
| 14:04 |
|
mmorgan1 joined #evergreen |
| 14:04 |
yboston |
#action yboston will move the undocumented content of the 2.8 new feature “TPAC Discoverability Enhancements” to its own section in the docs |
| 14:04 |
yboston |
I am deffering this again |
| 14:04 |
yboston |
:( |
| 14:04 |
yboston |
#info kmlussier will document the general workflow for being DIG release coordinator |
| 14:05 |
yboston |
in case she is around, but if not I will defer |
| 14:05 |
yboston |
#action kmlussier will document the general workflow for being DIG release coordinator |
| 14:05 |
yboston |
#action alynn26 will write to the DIG list to start discussion on DIG priorities before the next release in March |
| 14:06 |
yboston |
I am deferring Lynn action too since she is not here or on IRC |
| 14:06 |
|
dluch joined #evergreen |
| 14:06 |
yboston |
#info kmlussier will update the wiki page for web client docs |
| 14:06 |
yboston |
this was done, kmlussier++ |
| 14:06 |
yboston |
#info yboston will add agenda item fro discussing docs re-org tied to web cleint docs |
| 14:06 |
yboston |
this was done |
| 14:06 |
yboston |
#info sandbergja_ will create a doodle poll to pick a time in february to discuss docs re-org on both the DIG and general list |
| 14:06 |
yboston |
done |
| 14:07 |
yboston |
#info sandbergja_ will update the reorg wiki page with a list of project requirements & goals |
| 14:07 |
sandbergja |
Yes! It's Feb. 10th |
| 14:07 |
yboston |
I beleive this was done? |
| 14:07 |
yboston |
sandbergja++ |
| 14:07 |
sandbergja |
Yes, you can find it at http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:reorg_2014:requirements#requirements |
| 14:07 |
yboston |
#link https://evergreen-ils.org/communicate/calendar/ |
| 14:08 |
yboston |
#link http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:reorg_2014:requirements#requirements |
| 14:08 |
sandbergja |
I have to say, I was excited by the number of new folks who answered the doodle poll |
| 14:08 |
yboston |
that is the last action item from the previous meeting |
| 14:08 |
dluch |
#info dluch is Debbie Luchenbill, MOBIUS (late again, sorry) |
| 14:08 |
remingtron |
welcome Debbie! |
| 14:09 |
dluch |
Thanks! :-) |
| 14:09 |
yboston |
¡hola! |
| 14:10 |
yboston |
let's move to new items |
| 14:10 |
yboston |
#topic new business |
| 14:10 |
yboston |
#info discuss docs re-org and web client docs to see how they can influence the other |
| 14:11 |
yboston |
this topic I beleive came about a discussion on IRC about using new web client docs in the re-organized version of the docs |
| 14:11 |
yboston |
does this ring a bell to anyone? |
| 14:12 |
sandbergja |
I think it'd be a great idea, but am not quite sure how we'd go about it |
| 14:12 |
sandbergja |
especially since we haven't officially agreed on a new structure for the docs |
| 14:13 |
remingtron |
I vote to keep the same structure as the current staff client docs, to help staff who are transitioning from that to the web client |
| 14:13 |
yboston |
this is more of a long term thing or to be used as sample text |
| 14:13 |
remingtron |
(at least at first) |
| 14:13 |
dluch |
Oh, yeah, the discussion is starting to come to mind |
| 14:13 |
yboston |
for the re-org |
| 14:14 |
yboston |
my very rough idea is that when we do decide where to put "copy buckets" in the re-org docs, that we use the web client docs |
| 14:14 |
yboston |
since by that time it might be officailly released |
| 14:14 |
yboston |
OR |
| 14:14 |
yboston |
if we are creating a sample version of the re-org docs to get feedback, that we may want to try out web client docs too by using that content |
| 14:15 |
yboston |
this might be more trouble than it is worth |
| 14:15 |
yboston |
again, we can shelve this crazy idea for now |
| 14:15 |
yboston |
though I still wanted to keep putting the web docs in the special section we are suign now, I would not change that |
| 14:16 |
jihpringle |
if we're going to have to touch all of the documentation while updating it for the web client (at least screenshots) it makes sense to me to re-arrange it at the same time |
| 14:16 |
dluch |
agreed. |
| 14:16 |
remingtron |
jihpringle: I think that would complicate the updating process a lot |
| 14:17 |
remingtron |
maybe it's a good time, though, to be asking "Which re-org book does this section belong in?" |
| 14:18 |
remingtron |
that would give us a rough outline for the re-org project |
| 14:18 |
dluch |
the "web client" book would be my thought |
| 14:18 |
sandbergja |
remingtron: I agree. Perhaps we can start tagging specific bits of documentation with a possible audience? |
| 14:18 |
jihpringle |
I was thinking we would add the re-documented sections to the new books as we updated them and then release the new books at the same time as the official web client release (when we drop the staff client) |
| 14:19 |
yboston |
I think doing the re-org might be hard enough to pull off without adding the web client element, though it was my goofy idea inthe first place |
| 14:20 |
yboston |
at keast in the very short term for the sake of making progress witht he re-org |
| 14:20 |
yboston |
though I am glad that my idea made a bit of sense |
| 14:21 |
yboston |
we can shelve this for now anf bring it up at the re-org meeting |
| 14:21 |
yboston |
or we can keep talking about it too |
| 14:22 |
sandbergja |
Is there a way we could choose a middle road? |
| 14:23 |
yboston |
I bet we could find something |
| 14:23 |
yboston |
it might be more obvious after we have made more progress flshing out the plan for the re-org |
| 14:23 |
sandbergja |
e.g. for new Web Client documentation, we request that folks add a [NOTE] saying "For Local Sysadmins" or something? |
| 14:23 |
yboston |
as well as how far along the web client is |
| 14:23 |
sandbergja |
and then we can grep for those when we actually do reorganizing work? |
| 14:24 |
yboston |
that sounds like a good idea. Off the top of my head, I would use the double slash (//) which are comments in AsciiDoc |
| 14:24 |
remingtron |
I think the current docs make it pretty easy to separate the staff client sections into re-org books |
| 14:25 |
remingtron |
see this link for a basic outline: |
| 14:25 |
remingtron |
#link http://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:reorg_2014:audience_focused_layout |
| 14:25 |
sandbergja |
remingtron: that is a good point; my idea might be more trouble than it is worth. |
| 14:26 |
remingtron |
sandbergja: still a cool idea :) |
| 14:28 |
yboston |
do we want to move on to remingtron other "new" topic, or stay on this topic? |
| 14:28 |
sandbergja |
I'm happy to move on |
| 14:29 |
yboston |
besides remingtron's topic, which is short, we can go back to the web clients or the re-org |
| 14:29 |
yboston |
since they are the other makor topics outstanding, besides preparing for the next release |
| 14:29 |
sandbergja |
I have some re-org questions for after remingtron's topic |
| 14:29 |
yboston |
good |
| 14:29 |
yboston |
#info Who will create the 2.10 Docs Needs page? |
| 14:30 |
yboston |
remingtron: I don;t expect this to be too |
| 14:30 |
yboston |
hard |
| 14:30 |
yboston |
I may be able to do it |
| 14:30 |
yboston |
unles someone wants to get some wiki editing practice and want to colaborate with me |
| 14:30 |
remingtron |
I think kmlussier has created these pages in the past |
| 14:30 |
jihpringle |
I'd be happy to help |
| 14:30 |
yboston |
oops, I thought it was you |
| 14:31 |
yboston |
remingtron: there is a page that you often update? am I crazy? |
| 14:31 |
jihpringle |
we're about to start looking at 2.10 for our next upgrade and so will be going through our docs to update them for 2.10 |
| 14:31 |
yboston |
(don't answer) |
| 14:32 |
kmlussier |
I'm happy to hand over that task to somebody else. I usually wait until the beta release, at which time we should know all of the features that made it into the release. |
| 14:32 |
yboston |
jihpringle: would you like some help from me? |
| 14:32 |
jihpringle |
sounds good |
| 14:33 |
yboston |
for the record, the beta release is listed as Thursday, February 25 as of now |
| 14:33 |
yboston |
but that could change |
| 14:33 |
jihpringle |
I'll aim to create the page at the end of February, but will watch for a date change for the beta release |
| 14:34 |
yboston |
jihpringle: to be clear, should I assign it to just you? |
| 14:34 |
jihpringle |
yes |
| 14:34 |
yboston |
excellent (did not think you needed help, just wanted to be sure) |
| 14:34 |
remingtron |
One priority we should have is to provide good web client docs for anything that's "production ready" in 2.10 |
| 14:35 |
remingtron |
which at least includes the Circ Desk interfaces |
| 14:35 |
sandbergja |
jihpringle++ |
| 14:35 |
yboston |
#action jihpringle will create the 2.10 Docs Needs page |
| 14:35 |
remingtron |
according to this link: |
| 14:35 |
remingtron |
#link http://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:2.10 |
| 14:35 |
yboston |
shoudl we make it an action item to have a DIG member check with the devs about what is productionr eady for 2.10? |
| 14:36 |
remingtron |
I can't remember what gmcharlt (the release manager) said his goals were |
| 14:36 |
remingtron |
but I think it was only circ desk use. |
| 14:36 |
jihpringle |
will there be a web client test server for 2.10? We're not planning to release the web client to our libraries until we make the final switch so it won't be part of our test server |
| 14:36 |
jihpringle |
^^ community web client test server for 2.10 |
| 14:38 |
remingtron |
Here's gmcharlt's "plan for 2.10": |
| 14:38 |
remingtron |
#link http://georgialibraries.markmail.org/thread/wlnvqe53umjjevae |
| 14:38 |
yboston |
we can hope that the "webby" server would get updated for us to use |
| 14:38 |
remingtron |
which brings us back to yboston's question about checking with the devs |
| 14:39 |
yboston |
I can volunteer to check in with the devs around the time of the beta release |
| 14:39 |
remingtron |
I think yes, someone should probably ask gmcharlt or whomever has power over webby |
| 14:39 |
remingtron |
yboston++ |
| 14:40 |
jihpringle |
yboston++ |
| 14:40 |
gmcharlt |
well, it won't be webby, which is primarily for testing by the funding partners for the web staff client sprints, but we can update the ESI-hosted demo server to 2.10 closer in |
| 14:40 |
yboston |
#action yboston will check in with 2.10 release manager (gmcharlt ) about havign Webby ready for us to use and confirmation of what is produciton ready in the web client |
| 14:41 |
gmcharlt |
strike that action item, please, per my statement above |
| 14:41 |
yboston |
damm I typed too slow |
| 14:41 |
gmcharlt |
heh |
| 14:41 |
yboston |
gmcharlt: do you know how? |
| 14:41 |
gmcharlt |
just an #info, I guess at this point |
| 14:41 |
yboston |
OK |
| 14:42 |
yboston |
#info webby wil not be used for 2.10 DIG work, the ESI-hosted demo server can be updated to 2.10 |
| 14:42 |
yboston |
gmcharlt: what is the URL for that server or its nickname? |
| 14:43 |
yboston |
anyway, any other commetns or questiosn on this topic? |
| 14:43 |
gmcharlt |
see http://wiki.evergreen-ils.org/doku.php?id=community_servers&s[]=demo |
| 14:43 |
yboston |
#link http://wiki.evergreen-ils.org/doku.php?id=community_servers&s[]=demo |
| 14:43 |
yboston |
gmcharlt: thanks |
| 14:44 |
yboston |
#link http://demo.evergreencatalog.com/ |
| 14:44 |
yboston |
OK, we have about 15 minutes left |
| 14:44 |
remingtron |
yboston: so, a main requirement of the DIG 2.10 needs page is documenting Circ web client stuff, right? |
| 14:45 |
yboston |
good question |
| 14:45 |
yboston |
I think under the assumption that circ... |
| 14:45 |
yboston |
will be productionr eady, then the circ parts of the web client would need to be documented |
| 14:47 |
remingtron |
okay, just trying to summarize all of this in my brain |
| 14:47 |
sandbergja |
One question about DIG 2.10 needs: gmcharlt mentioned in his plan that 2.10 would "document ways to use SIP2 more securely" |
| 14:48 |
sandbergja |
is that something DIG should create? |
| 14:48 |
gmcharlt |
sandbergja: that's on my todo list to write a draft of |
| 14:48 |
yboston |
excellent queston, I noticed that too |
| 14:48 |
sandbergja |
gmcharlt++ |
| 14:50 |
yboston |
anything else on this topic or another one? |
| 14:50 |
sandbergja |
Planning for docs re-org meeting on Wednesday |
| 14:50 |
yboston |
yes |
| 14:50 |
yboston |
we shoudl probably send out a reminder for the meeting |
| 14:50 |
yboston |
with IRC tips |
| 14:50 |
sandbergja |
IRC_tips++ |
| 14:51 |
sandbergja |
I can send a reminder |
| 14:51 |
sandbergja |
Also, I'm happy to facilitate that (unless yboston or remingtron would like to), but would have to learn a little bit more about MeetBot |
| 14:51 |
krvmga |
sandbergja++ |
| 14:51 |
yboston |
#action sandbergja wil send out a reminder about the re-org meeting to the main list and DIG list |
| 14:52 |
yboston |
sandbergja: would you like to co-lead so you can get some practice? |
| 14:52 |
sandbergja |
yboston: that sounds great! |
| 14:52 |
yboston |
I can train you beforehand in case you want to lead it yourself |
| 14:53 |
sandbergja |
either way! |
| 14:53 |
sandbergja |
I would definitely appreciate your guidance either way, yboston. :-) |
| 14:53 |
remingtron |
I probably can't attend that meeting, but I'll read the meetbot log and related emails, etc. |
| 14:53 |
yboston |
to be safe lets just co-lead, but reach out to me next week so we can talk about what you normally do when facilitating. the more people that learnt he better |
| 14:54 |
yboston |
one action Item I woudl add, which I can take on |
| 14:54 |
yboston |
is to reach out to Robert, to see what he can start on to prepare us to have a brand new configuration on the docs server to try out the re-org |
| 14:55 |
yboston |
or somethign along those lines |
| 14:55 |
yboston |
thoughts? |
| 14:55 |
sandbergja |
Sounds good to me |
| 14:55 |
remingtron |
yboston: do we already have a test DIG server? |
| 14:55 |
krvmga |
good idea. |
| 14:55 |
yboston |
remingtron: it is not set up |
| 14:55 |
gmcharlt |
indeed, that's available |
| 14:55 |
yboston |
I mean, not sure if all the tool chain is installed |
| 14:56 |
gmcharlt |
and setting it up to host the reorg would be a possibility |
| 14:56 |
yboston |
gmcharlt++ |
| 14:56 |
yboston |
gmcharlt: when could I reach out to look into this? |
| 14:57 |
yboston |
gmcharlt: I wouldliek to get Robert involved, just to make sure we move over all of the right configs/templates |
| 14:58 |
yboston |
anyway, we are done to a couple of meetings? |
| 14:58 |
yboston |
any last thoughts or questions? |
| 14:58 |
yboston |
*minutes |
| 14:58 |
gmcharlt |
yboston: let's catch up next week |
| 14:58 |
yboston |
OK |
| 14:58 |
yboston |
gmcharlt++ |
| 14:58 |
yboston |
last words? |
| 14:58 |
remingtron |
nope, thanks yboston |
| 14:59 |
remingtron |
yboston++ |
| 14:59 |
krvmga |
famous last words? |
| 14:59 |
sandbergja |
yboston++ |
| 14:59 |
krvmga |
yboston++ |
| 14:59 |
yboston |
adios |
| 14:59 |
yboston |
#endmeeting |
| 14:59 |
pinesol_green |
Meeting ended Thu Feb 4 14:59:22 2016 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 14:59 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-02-04-14.00.html |
| 14:59 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-02-04-14.00.txt |
| 14:59 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2016/evergreen.2016-02-04-14.00.log.html |
| 14:59 |
dluch |
yboston++ |
| 14:59 |
jihpringle |
yboston++ |
| 15:00 |
Christineb |
yboston++ |
| 15:00 |
chreeus |
dbs: I'm creating a PG 9.3 test VM to test your implicit sorting theory - it sounds like it would explain everything |
| 15:05 |
kmlussier |
yboston++ |
| 15:06 |
Stompro |
Stompro |
| 15:06 |
* Stompro |
oops |
| 15:11 |
kmlussier |
tsbere: What version of Postgres is used on the MassLNC VMs? That's where I saw the z39.50 sorting issue. |
| 15:13 |
|
mmorgan joined #evergreen |
| 15:14 |
|
_bott_1 joined #evergreen |
| 15:15 |
|
dkyle1 joined #evergreen |
| 15:16 |
kmlussier |
nm I found it |
| 15:16 |
chreeus |
kmlussier: is it 9.4? |
| 15:16 |
jeff |
ah, see... i went with differing perl versions, didn't think about differing postgres versions. :-) |
| 15:17 |
kmlussier |
chreeus; Nope 9.3.10 |
| 15:17 |
chreeus |
hmm |
| 15:17 |
chreeus |
my non-random-sorting server is PG 9.3 |
| 15:18 |
chreeus |
9.3.10 |
| 15:18 |
chreeus |
argh |
| 15:20 |
|
bshum joined #evergreen |
| 15:22 |
|
bshum joined #evergreen |
| 15:23 |
chreeus |
ok - gonna build a precise VM with PG 9.4 to test the perl version issu |
| 15:23 |
chreeus |
e |
| 15:25 |
|
bshum joined #evergreen |
| 15:27 |
jeff |
chreeus: what are the perl versions in question? |
| 15:27 |
jeff |
oh, i see you provided that elsewhere. |
| 15:28 |
kmlussier |
chreeus: I'm updating the bug, but I was on 5.18.2 as well |
| 15:28 |
|
jvwoolf joined #evergreen |
| 15:29 |
jeff |
Perl 5.18 introduced major changes in hashes, including changes that affect order. |
| 15:29 |
jeff |
and randomization. |
| 15:29 |
jeff |
see http://perldoc.perl.org/perl5180delta.html |
| 15:30 |
jeff |
under "Hash overhaul" |
| 15:30 |
|
jlitrell joined #evergreen |
| 15:30 |
jeff |
iirc, we hit those changes with some tests, which needed to be adjusted slightly. |
| 15:32 |
kmlussier |
I've updated the bug and now try remembering exactly what it was I was working on today. |
| 15:32 |
|
dkyle1 left #evergreen |
| 15:33 |
jlitrell |
An excellent time to interrupt you with exclusion checkboxes. :-D |
| 15:33 |
jeff |
for me, that's automation, some new reports, a vendor security issue, and teaching our Twilio notifications to place note on a patron account when the patron has blocked us from texting them... :-) |
| 15:33 |
kmlussier |
jlitrell: Yes, indeed! |
| 15:36 |
miker |
jeff: shall we just set PERL_PERTURB_KEYS=0 then? ;) |
| 15:36 |
* miker |
ducks |
| 15:39 |
Dyrcona |
I'm using Perl 5.14 on the training server where the screenshots came from. |
| 15:39 |
|
jcamins__ joined #evergreen |
| 15:43 |
kmlussier |
@blame perl |
| 15:43 |
pinesol_green |
kmlussier: perl is NOT CONNECTED TO THE NETWORK!!! |
| 15:45 |
Dyrcona |
I'm not sure it is exclusively Perl. |
| 15:45 |
Dyrcona |
My production is still 2.7.2, but runs on trusty with Perl 5.18 and I see similar results to what I see in Training with Perl 5.14. |
| 15:45 |
|
_bott_ joined #evergreen |
| 15:46 |
Dyrcona |
I get a different order depending on which remote I select first, but always the same order with the same remote. |
| 15:46 |
Dyrcona |
I didn't actually try the backend call via srfsh. |
| 15:47 |
kmlussier |
In my case, I selected OCLC every time. |
| 15:49 |
Dyrcona |
Ok. I see it changing with OCLC. |
| 15:49 |
|
Bmagic joined #evergreen |
| 15:49 |
|
Christineb_away joined #evergreen |
| 15:50 |
|
Bmagic joined #evergreen |
| 16:04 |
JBoyer |
Dyrcona: I think what you're seeing is an older bug, where the fields available on the first remote you choose somehow mess with the order of subsequent fields added when you add/change remote servers. Not certain of it's launchpad-ness. |
| 16:08 |
Dyrcona |
Well, with OCLC, I just opened two tabs, opened z39.50 search in each, and checked OCLC on both. |
| 16:08 |
Dyrcona |
Got different field order with Perl 5.18. |
| 16:23 |
JBoyer |
I mean what you were seeing on the 5.14 install. It's not as annoying if you only use a single remote or select multiple in the same order, so it's not as big a deal. |
| 16:29 |
jihpringle |
does anyone know if you can add cover art to a check out receipt? (it's possible for the self check but that's done through action triggers) |
| 16:30 |
kmlussier |
Ooh! I like that idea. |
| 16:37 |
miker |
jeff and _bott_ may have ideas ... I think they (or one of them) added images |
| 16:38 |
jeff |
my gut reaction to the idea is rather curmudgeonly. |
| 16:39 |
jeff |
it might be possible, moreso now with the ability to fetch jackets by record id. i don't know if the receipt templates have been prevented from pulling remote images now or not. |
| 16:46 |
jeff |
jihpringle: are you doing this in the self checkout interface with success? |
| 16:46 |
jihpringle |
I just had a library tell me that they print out on the self check items out receipt |
| 16:46 |
jihpringle |
I need to test myself to double check |
| 16:48 |
jeff |
i'm curious if they're printing in greyscale on a receipt printer, or printing to a letter sized sheet on a laser/inkjet, black and white or color, etc. |
| 16:52 |
jihpringle |
I'll do some testing and find out more details from the library |
| 17:00 |
|
jvwoolf left #evergreen |
| 17:05 |
|
mmorgan left #evergreen |
| 17:12 |
kmlussier |
Good night #evergreen! |
| 17:23 |
|
bmills joined #evergreen |
| 17:54 |
Bmagic |
gn |
| 18:04 |
|
dbwells joined #evergreen |
| 18:30 |
|
mrpeters left #evergreen |
| 18:31 |
chreeus |
hmm - the perl hash randomization change may also explain a complaint I got from UMS about data file fields being suddenly in a different order |
| 18:37 |
jeff |
the batch collections update file, or something else? |
| 19:36 |
chreeus |
jeff: yeah - the weekly batch collections file field order changed |
| 19:37 |
chreeus |
must not be totally random though, since they were apparently able to code around it |
| 20:44 |
|
bmills joined #evergreen |
| 20:49 |
jeff |
chreeus: how many weeks in a row since they made the adjustment? ;-) |
| 21:30 |
chreeus |
well, uh - one |
| 21:34 |
jeff |
best wishes for next week. :-) |
| 23:08 |
|
dcook joined #evergreen |
| 23:31 |
|
bmills joined #evergreen |
