| Time |
Nick |
Message |
| 02:12 |
|
jonadab_znc joined #evergreen |
| 05:09 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:03 |
|
rlefaive joined #evergreen |
| 07:25 |
|
rlefaive joined #evergreen |
| 07:36 |
|
akilsdonk joined #evergreen |
| 07:47 |
|
mrpeters joined #evergreen |
| 08:07 |
|
rjackson_isl joined #evergreen |
| 08:09 |
|
ericar joined #evergreen |
| 08:18 |
|
ericar joined #evergreen |
| 08:28 |
|
Dyrcona joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:51 |
|
jwoodard joined #evergreen |
| 09:00 |
|
RoganH joined #evergreen |
| 09:04 |
|
akilsdonk joined #evergreen |
| 09:07 |
Dyrcona |
"Can you give me a report of checkouts by [3M] self check workstation?" |
| 09:08 |
Dyrcona |
"Erm, no. I can tell you how many were done by self checks, but I can't give you a break down by self check." |
| 09:08 |
dbs |
"sure, if each one logs into its own sip account" |
| 09:08 |
Dyrcona |
dbs: They don't. |
| 09:08 |
Dyrcona |
So I can't. |
| 09:09 |
Dyrcona |
And, really, I paraphrase.... ;) |
| 09:10 |
|
Shae joined #evergreen |
| 09:13 |
dbs |
:) |
| 09:14 |
dbs |
*sigh* |
| 09:15 |
dbs |
Time to try and dig up the "this one bib won't ingest" faq |
| 09:23 |
dbs |
Is there a "switch in-db ingest into verbose mode" switch that can easily show me where things break down, or do we still have to walk through the process step by step until we reach "aha" moment |
| 09:25 |
* csharp |
has never been aware of a verbose mode, but would welcome it warmly ;-) |
| 09:28 |
|
yboston joined #evergreen |
| 09:35 |
|
collum joined #evergreen |
| 09:36 |
bshum |
One bib won't ingest, hmm. |
| 09:37 |
bshum |
So like https://bugs.launchpad.net/evergreen/+bug/1091885 or something else? |
| 09:38 |
pinesol_green |
Launchpad bug 1091885 in Evergreen "Reingest bib needs to deal with missing metabib.record_attr entries" (affected: 5, heat: 32) [Medium,Confirmed] |
| 09:41 |
Dyrcona |
Dunno, bshum. You tell me. :) |
| 09:42 |
bshum |
Dyrcona: Oh I was just musing on dbs' musings |
| 09:42 |
Dyrcona |
Yep. |
| 09:43 |
* Dyrcona |
goes back to writing a pgtap test for jeffdavis_afk |
| 09:43 |
Dyrcona |
Well, one of his branches, anyway. |
| 09:43 |
bshum |
:P |
| 09:44 |
Dyrcona |
But, bshum's latest comment on the bug he mentioned might prove helpful to dbs if that is the problem. |
| 09:53 |
bshum |
phasefx: Starting with a simple one, I can't find a msgid "Messages" which is what I might have expected in tpac.po for the Message Center. |
| 09:53 |
bshum |
phasefx: re: eva's czech translation concerns. |
| 09:54 |
bshum |
I wonder if there's some sync step that we've missed to merge stuff back to Launchpad for i18n |
| 09:54 |
phasefx |
it's been a long while since I've messed with pots/etc. The code itself is marked up correctly? So it's just the build process? |
| 09:56 |
bshum |
phasefx: It's in Open-ILS/src/templates/opac/parts/myopac/base.tt2 |
| 09:57 |
bshum |
Looks okay to my eyes initially, but I'm still reading around |
| 09:57 |
bshum |
Line 4 of that file anyways |
| 09:58 |
bshum |
The other main links do have translation entries in the po file, and seem to match up |
| 09:58 |
bshum |
So I don't think it's a syntax problem |
| 10:00 |
* csharp |
rearchitects the entire EG database so one person doesn't have to remember to filter on "deleted" |
| 10:02 |
bshum |
csharp: Yes, *please* get right on that for them. |
| 10:03 |
csharp |
it's possible she doesn't realize that you can "hard code" deleted = false into each reports template, which allows you to effectively not think about it |
| 10:04 |
* csharp |
does that with nearly every reports template he creates |
| 10:08 |
_bott_ |
xpath is not my friend |
| 10:09 |
_bott_ |
Fighting with some author indexing. Getting a $d jammed into the $a, so I end up with a value like: Lambert, Adam1982- ...people rarely search for people named Adam1982- |
| 10:09 |
bshum |
phasefx: I think I know what happened... |
| 10:10 |
bshum |
The 2.8 translation import only happened in the rel_2_8 branch |
| 10:10 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2cde189a3629493cce7f046f7905958b7d26b220 |
| 10:10 |
pinesol_green |
[evergreen|Bill Erickson] 2.8 translation import - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2cde189> |
| 10:10 |
bshum |
But not to master |
| 10:10 |
bshum |
And since translations in LP track against master |
| 10:10 |
bshum |
Those strings never showed up for needing translation in LP. |
| 10:10 |
Dyrcona |
miker: If you want sprint2 in master before the alpha/beta release, then you'll need to clean up the upgrade scripts and provide pgtap tests. |
| 10:11 |
Dyrcona |
miker: I'm also concerned about the FIXME comment in XXXX.schema.marc-tag-tables.sql |
| 10:11 |
Dyrcona |
I get errors on line 9 and will try reordering the drop statements, but also wonder if I should even be running those drops given the comment. |
| 10:12 |
phasefx |
bshum: fun |
| 10:13 |
bshum |
phasefx: I would imagine we could still cherry-pick berick's changeset from 2.8 to master now. And then when Dyrcona does i18n dances for 2.9, we just make sure to bring in all the translations |
| 10:13 |
bshum |
But I'm not sure how we can fix 2.8. Yet. |
| 10:13 |
bshum |
Still rethinking it over. |
| 10:13 |
Dyrcona |
I should do a test release build whether there is an alpha or not. |
| 10:14 |
bshum |
Dyrcona: It's always good practice. |
| 10:15 |
Dyrcona |
Yep. Trouble is: not much time for practice. |
| 10:16 |
phasefx |
bshum++ I'm glad you're thinking about it; it's over my head at the moment. So we do something to extract strings from source files into language files, commit those somewhere, and Launchpad can then change them or let us export a new updated set of files based on its global translation effort? |
| 10:17 |
bshum |
phasefx: Right. |
| 10:17 |
bshum |
http://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:2.8 |
| 10:17 |
bshum |
On the release process wiki that we started |
| 10:17 |
bshum |
There's a spot where we pull in LP branch that dbs setup awhile back |
| 10:17 |
bshum |
Then we run a script called update_pofiles |
| 10:17 |
phasefx |
excellent; I was looking under stuff like "i18n" |
| 10:17 |
bshum |
That figures out what needs changing |
| 10:18 |
bshum |
Then there's some git magic that happens |
| 10:18 |
bshum |
To decide what all goes into the commit |
| 10:18 |
bshum |
The trick is that commit doesn't apply only to the rel_x_y branch, but to master itself. |
| 10:18 |
bshum |
I guess |
| 10:19 |
bshum |
I'm still figuring it all out again :D |
| 10:19 |
bshum |
Part of me thinks it should have been more automatic somehow |
| 10:19 |
bshum |
But... yeah. |
| 10:20 |
* bshum |
should finish exploring LP's git branch setup |
| 10:20 |
bshum |
Getting rid of bzr would be nice :) |
| 10:21 |
bshum |
I think the process is that we have to run the i18n dance twice. |
| 10:21 |
bshum |
Once at beta, to get all the strings into the main files |
| 10:21 |
bshum |
For "string freeze" |
| 10:21 |
bshum |
and then once again at RC time |
| 10:21 |
bshum |
With hopefully enough translation work happening in LP to cover the actual needed changes. |
| 10:22 |
bshum |
If I cherry-pick berick's commit from 2.8 |
| 10:22 |
bshum |
That should allow master to get the new string changes |
| 10:22 |
bshum |
And then if they start translating them |
| 10:23 |
bshum |
As long as we get the new po files from master before Dyrcona does a new i18n dance |
| 10:23 |
bshum |
No wait, that won't work |
| 10:23 |
bshum |
Shoot |
| 10:23 |
bshum |
Cause master is already drifting |
| 10:23 |
bshum |
Cause we're adding new features for 2.9 |
| 10:23 |
bshum |
I don't know if we can fix 2.8 very easily. :( |
| 10:23 |
* bshum |
wishes he had more time to devote to i18n mysteries |
| 10:24 |
csharp |
ugh - more long queries around holds stuff: http://pastie.org/10333517 |
| 10:24 |
dbs |
bshum++ |
| 10:25 |
csharp |
now it's affecting the "Clear Hold Shelf" checkin modifier, which more libraries use than I realized |
| 10:25 |
dbs |
Yeah, very probably that's the ingest problem root cause this time around. I'll see |
| 10:25 |
csharp |
because adding that modifier runs the above pasted query, it's killing the stateful session |
| 10:25 |
csharp |
resulting in "network failure" errors |
| 10:25 |
bshum |
Those are "fun" |
| 10:26 |
Dyrcona |
csharp: So, don't use that modifier. :p |
| 10:27 |
csharp |
@hate <quote>fun<unquote> |
| 10:27 |
pinesol_green |
csharp: The operation succeeded. csharp hates <quote>fun<unquote>. |
| 10:27 |
csharp |
Dyrcona: yeah, that was my answer to the first library who complained ;-) |
| 10:27 |
* Dyrcona |
sympathizes. We get that issue reported from time to time. |
| 10:27 |
bshum |
@love <quote>fun</quote> |
| 10:27 |
pinesol_green |
bshum: The operation succeeded. bshum loves <quote>fun</quote>. |
| 10:27 |
csharp |
@love actual fun |
| 10:27 |
pinesol_green |
csharp: The operation succeeded. csharp loves actual fun. |
| 10:27 |
|
Christineb joined #evergreen |
| 10:27 |
bshum |
That should go on a t-shirt |
| 10:28 |
* csharp |
copyrights it before bshum gets a chance |
| 10:30 |
Dyrcona |
Hmm... Wonder if IRC chat is copyrightable.... That would be an interesting case. |
| 10:31 |
Dyrcona |
And, I still haven't written the pgtap test, yet. |
| 10:32 |
dbs |
Your chat in IRC is an expression of an idea, thus very likely copyrightable. |
| 10:32 |
* dbs |
was just answering a question around copyright and fair dealing for our online learning folks |
| 10:32 |
RoganH |
Yep. If you create the speech you can copyright it. You're just exercising your own right to perform it in public. |
| 10:33 |
Dyrcona |
On i18n: maybe we should just keep the translations in the master branch along with the code? |
| 10:33 |
Dyrcona |
RoganH: And I hear that a court in some European country has ruled that anything on the "Internet" is public domain. |
| 10:33 |
dbs |
Dyrcona: you get to figure out the process that allows translators to translate in little bits :) |
| 10:34 |
RoganH |
Dyrcona: country by country copyright varies dramatically. Since most of us here are US/Canadian I'm mostly talking about that. The US/Canada laws have minor differences but are at least pretty close. :) |
| 10:34 |
Dyrcona |
dbs: It was just a question to discuss the pros and cons.... |
| 10:35 |
bshum |
This is why I didn't want to be i18n manager :) |
| 10:35 |
csharp |
Copyright (C) 2015 Chris Sharp. All Rights Reserved. |
| 10:35 |
* Dyrcona |
used to handle copyright paperwork for the University Press of Kentucky and knows pretty much how it works and that it varies from jurisdiction to jurisdiction. |
| 10:35 |
csharp |
now it's legal! |
| 10:35 |
bshum |
But I feel for the Czech librarians. Not those crazy French people though... |
| 10:35 |
RoganH |
International intellectual property is a nightmare for big global companies. |
| 10:36 |
Dyrcona |
Though the attorney pointed out that "Copyright law is whatever the judge in your particular case says it is." |
| 10:36 |
csharp |
miker: if you're around, would you mind peeking at my paste above? I'm not sure if it's another case of bad stats or if we need a new index. |
| 10:36 |
RoganH |
Dyrcona: that's true with law over all, but yep, judges have huge leeway |
| 10:36 |
* Dyrcona |
personally believes "intellectual property" isn't a thing, and that the law is antiquated. |
| 10:36 |
dbs |
the law is a ass, some wise man said |
| 10:37 |
csharp |
dbs++ |
| 10:37 |
Dyrcona |
dbs++ some_wise_man_said++ |
| 10:38 |
|
terran joined #evergreen |
| 10:38 |
bshum |
csharp: For fun, I ran that query and got back in 546 ms |
| 10:38 |
Dyrcona |
(C) is not valid, so in Brazil, what you just said is in the public domain, csharp. :) |
| 10:39 |
bshum |
I'm comparing our outputs now, for giggles |
| 10:39 |
Dyrcona |
In Brazil it must have the c in the circle symbol, the word copyright is not good enough by itself. (That I remember from research from a number of years ago.) |
| 10:40 |
Dyrcona |
But, anyway.... that pgtap test... |
| 10:40 |
* bshum |
makes an adjustment to the query |
| 10:40 |
bshum |
Since he realizes current_shelf_lib = 22 doesn't mean the same thing in his system |
| 10:41 |
Dyrcona |
bshum: Try my database and use current_shelf_lib = 17, pretty much guaranteed to blow up at our busiest library. :) |
| 10:41 |
bshum |
Dyrcona: That's what I'm wondering too. |
| 10:42 |
bshum |
But of course, csharp is a bigger system and has lots more hold_request rows |
| 10:42 |
Dyrcona |
We had to increase the number of available cstores at migration so that they could run a pull list. |
| 10:42 |
bshum |
I still got a return about 2533 ms |
| 10:42 |
bshum |
So 10 times faster |
| 10:42 |
bshum |
Chose our largest library |
| 10:42 |
csharp |
bshum: my current experiment is deleting (aka, "aging") most of the hold_request table on a test server - gonna see if that helps. |
| 10:43 |
bshum |
One of our busiest ILL libs, got 2977 ms |
| 10:43 |
bshum |
So yeah |
| 10:43 |
bshum |
The shape of the query is different |
| 10:43 |
bshum |
And different even for me... |
| 10:44 |
bshum |
Between my two libs, I get different explains |
| 10:44 |
Dyrcona |
Speaking of slow queries.... |
| 10:45 |
Dyrcona |
bshum and berick do you think that lp 1479953 should be backported to 2.8 and 2.7 as a bug fix? |
| 10:45 |
pinesol_green |
Launchpad bug 1479953 in Evergreen "Deleting queues containing many records is slow, can time out" (affected: 2, heat: 10) [Undecided,New] https://launchpad.net/bugs/1479953 |
| 10:46 |
Dyrcona |
That's what I'm trying to write the pgtap test for. |
| 10:46 |
bshum |
Dyrcona: Remind me what happens if you try to create an index where one already exists? |
| 10:46 |
Dyrcona |
The create index statement dies. |
| 10:47 |
Dyrcona |
But it might succeed if the names are different. |
| 10:47 |
Dyrcona |
I'd have to actually try the latter. |
| 10:47 |
* bshum |
wants PG 9.5 then where "CREATE INDEX IF NOT EXISTS ..." is coming |
| 10:47 |
bshum |
I just think that'll hamper upgrade processes. |
| 10:48 |
bshum |
If the create index gets wrapped into various version-upgrade pathways |
| 10:48 |
bshum |
It'll just be "annoying" for upgraders |
| 10:48 |
bshum |
if we do backport |
| 10:48 |
bshum |
I suppose we add those outside the main body commit |
| 10:48 |
bshum |
So that they can fail harmlessly |
| 10:48 |
bshum |
With a message or something saying, ignore these, it's okay if you already have them from a previous version |
| 10:49 |
* bshum |
could see it as a bug fix or a new feature |
| 10:49 |
bshum |
It's new and improved now! |
| 10:49 |
Dyrcona |
Well, OK, then. No backport is my vote, but you're in charge of 2.7, so, that's your call. |
| 10:50 |
* bshum |
is fine with no backport |
| 10:50 |
Dyrcona |
But yeah, I verified that if you create the index with the same name it fails. |
| 10:50 |
* bshum |
needs to carve time to show yboston some magic. |
| 10:50 |
Dyrcona |
With a different name it succeeds. |
| 10:51 |
Dyrcona |
Which makes me wonder if I shouldn't stick _idx on the end of the index names. |
| 10:55 |
Dyrcona |
Think I will, since the majority of indexes are spelled that way. |
| 11:08 |
jwoodard |
So I had jury duty this week. It was fun. The only thing I hate is the selection process. |
| 11:09 |
berick |
bshum: arg, feel bad I caused a problem I still don't understand |
| 11:15 |
bshum |
berick: It's okay, I'm not sure I will ever fully understand it. |
| 11:21 |
bshum |
berick: When I can think through everything a bit more, I'll try making some changes to that release_process wiki page on how the i18n bits happen |
| 11:22 |
Dyrcona |
Hmm. Should a commit adding a pgtap test and simply renaming indexes from the previous commit get another sign off? |
| 11:22 |
|
kbutler joined #evergreen |
| 11:22 |
berick |
bshum: k. let me know if I can help |
| 11:24 |
bshum |
berick: Looking back in the git history, I can see that changes for "po files" and "newpot" occurred as separate commits. |
| 11:24 |
bshum |
So I think there's some nuance that dbwells and I did when we did our work that isn't in the wiki |
| 11:27 |
berick |
yeah, i've done them as separate commits in the past, but eventually started squashing them into one. did not know it mattered |
| 11:27 |
berick |
was just trying to reduce noise |
| 11:28 |
bshum |
berick: I'm not sure it really matters, but I wonder if maybe we need to script in more runs of newpot at frequent intervals to get stuff to LP for translators to work on. |
| 11:28 |
bshum |
So like, at alpha/beta run newpot to make sure strings are added and generated towards master |
| 11:29 |
bshum |
And then at beta/rc/release, do the updates |
| 11:29 |
Dyrcona |
Grabbing 0922. |
| 11:29 |
berick |
bshum: hm, yeah, didn't realize LP depended on that step for translaters to have stuff to work on. |
| 11:29 |
|
bmills joined #evergreen |
| 11:30 |
berick |
in that case, i agree. newpot should be part of every major feature, give or take. |
| 11:30 |
berick |
at least run more frequently |
| 11:36 |
|
jihpringle joined #evergreen |
| 11:38 |
bshum |
Aha |
| 11:38 |
bshum |
So in translation settings for master series |
| 11:39 |
bshum |
I can see that we're pulling in the bazaar branch master, and that's getting exported back out to dbs' bazaar branch for translations-export |
| 11:39 |
bshum |
So yeah, every time we update the pot's in master, it'll setup new strings needing translation in LP |
| 11:40 |
bshum |
And then as people translate them in LP, it gets pushed to dbs' branch |
| 11:40 |
bshum |
Which we then pull back in when we run the updates_pofiles script |
| 11:46 |
pinesol_green |
[evergreen|Jeff Davis] LP#1479953: Add indexes to vqbr foreign key references - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=679578d> |
| 11:46 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1479953: Rename indexes to *_idx and add pgTAP test. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=57d756f> |
| 11:46 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1479953: Stamping Upgrade Script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=768680b> |
| 11:47 |
bshum |
jeffdavis++ Dyrcona++ |
| 11:47 |
Dyrcona |
kmlussier++ # she tested it, too. |
| 11:48 |
bshum |
berick: I'm going to forward port your 2.8 translation changes to master so that the Czechs have something to start working with. |
| 11:48 |
berick |
bshum++ |
| 11:51 |
|
bmills joined #evergreen |
| 11:52 |
Stompro |
Can someone give me a pointer to where the "move item to lost after x days" setting is at? |
| 11:53 |
kmlussier |
Stompro: It's an action trigger |
| 11:53 |
Stompro |
Awsome, thanks |
| 11:54 |
bshum |
LP is syncing now... |
| 11:54 |
bshum |
Even it has an i18n dance wait :D |
| 11:55 |
pinesol_green |
[evergreen|Bill Erickson] Forward-port 2.8 translation import - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b4ae273> |
| 11:58 |
bshum |
Hmm |
| 11:58 |
bshum |
So actually, if we don't run newpot, but do the update_pofiles first |
| 11:58 |
bshum |
We should be able to pull in new string translations for relatively 2.8-ish |
| 11:59 |
bshum |
Before we get to running newpot again for 2.9 new strings |
| 11:59 |
bshum |
But I guess it depends on how fast translations appear in LP, and how fast people translate the strings. |
| 12:03 |
dbs |
bshum: well dang, I thought I wrote up the process as part of the docs |
| 12:03 |
dbs |
http://docs.evergreen-ils.org/2.8/_updating_the_translations.html |
| 12:03 |
bshum |
dbs: It's there, yeah |
| 12:03 |
|
kitteh_ joined #evergreen |
| 12:04 |
bshum |
We're just in the process of rediscovering everything again. |
| 12:04 |
dbs |
heh |
| 12:04 |
bshum |
yeah, in my notes, I linked to the 2.3 version of that page too. |
| 12:08 |
dbs |
bshum: also, concur with the alpha/beta PO updates; that was originally how we tried to do things (and it's how most projects approach translation, with progressively stricter string change restrictions as the final release approaches), but it got lost over time |
| 12:09 |
dbs |
There's also the "we added a new Dojo interface but didn't add it to the i18n Makefile" sort of problem that I never documented |
| 12:10 |
bshum |
dbs: I think I had to deal with at least one situation like that when I was 2.7 RM |
| 12:10 |
bshum |
But I also didn't document it out properly :\ |
| 12:11 |
bshum |
Yeah I guess I did it by hand or something... |
| 12:11 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=89c70d8cd5ada95eb01d5101343171183fc378e1 |
| 12:11 |
pinesol_green |
[evergreen|Ben Shum] Update script for update_pofiles - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=89c70d8> |
| 12:12 |
bshum |
assuming that's what you mean, and not something else I'm not recognizing. |
| 12:12 |
bshum |
Hmm, I suppose we'll need to add something like "staff" someday with the web client? |
| 12:14 |
bshum |
Or hmm |
| 12:14 |
bshum |
Maybe it all just lives with tpac |
| 12:14 |
* bshum |
wonders how "tpac" is used, vs. opac or kpac, or whatever or if that's exactly what it is all tt2 things |
| 12:17 |
bshum |
Ah, I see dbs... |
| 12:17 |
bshum |
So yeah, web client isn't being translated to files yet |
| 12:17 |
bshum |
Cause we need to update the build/i18n/Makefile |
| 12:17 |
bshum |
To include a path for that |
| 12:17 |
bshum |
And generate a pot for it |
| 12:17 |
bshum |
dbs++ |
| 12:18 |
bshum |
I am starting to see some of the light |
| 12:21 |
bshum |
Or maybe I'm just getting sucked deeper into the rabbit hole |
| 12:29 |
Dyrcona |
Maybe the light at the end of the tunnel is an oncoming train.... |
| 12:38 |
|
buzzy joined #evergreen |
| 12:38 |
jboyer-isl |
Dyrcona, bshum: Relevant to your earlier indexes in upgrade scripts discussion: http://pastie.org/10333774 |
| 12:39 |
jboyer-isl |
It's our own CREATE INDEX IF NOT EXISTS, but now with more lines! |
| 12:44 |
csharp |
jboyer-isl++ |
| 12:44 |
bshum |
Heh, jboyer-isl++ # funny |
| 12:44 |
bshum |
(and no doubt helpful) |
| 12:52 |
|
ericar joined #evergreen |
| 13:09 |
dbs |
bshum++ |
| 13:21 |
Dyrcona |
So, this has started happening randomly to action trigger runner and friends: Exception: OpenSRF::EX::Session 2015-08-06T13:00:04 main /openils/bin/action_trigger_runner.pl:240 Session Error: Transport::handler(): No AppSession object returned from server_build() |
| 13:22 |
Dyrcona |
A little more information: Attempting to build a client session as a server Session ID [1438880403.2762925307.603051947], remote_id [opensrf private.thing2-utility.mvlcstaff.org/opensrf.settings_drone_at_thing2-utility.mvlcstaff.org_31356] at /usr/local/share/perl/5.18.2/OpenSRF/AppSession.pm line 127. |
| 13:24 |
Dyrcona |
Interesting. This bears looking into... |
| 13:38 |
Dyrcona |
Hmm. I think, maybe, we maxed out on opensrf.settings drones. |
| 13:42 |
Dyrcona |
No message to that effect in the logs, though. |
| 13:47 |
Dyrcona |
And, the drone it was trying to talk to is still running. |
| 13:49 |
Dyrcona |
And, the drone appears to be handling other requests just fine. |
| 14:02 |
|
rlefaive joined #evergreen |
| 14:05 |
|
jlitrell joined #evergreen |
| 14:06 |
yboston |
heads up, DIG meeting happenng at 2 PM EST |
| 14:07 |
remingtron |
yboston: you mean at 2:15? |
| 14:07 |
yboston |
sorry, yes |
| 14:07 |
yboston |
thanks for catching that |
| 14:09 |
|
jck_ joined #evergreen |
| 14:15 |
yboston |
#startmeeting DIG Monthly Meeting Evergreen Documentation Interest Group (DIG) Monthly Meeting. |
| 14:15 |
pinesol_green |
Meeting started Thu Aug 6 14:15:57 2015 US/Eastern. The chair is yboston. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:15 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:15 |
pinesol_green |
The meeting name has been set to 'dig_monthly_meeting_evergreen_documentation_interest_group__dig__monthly_meeting_' |
| 14:16 |
yboston |
The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20150806-agenda |
| 14:16 |
yboston |
#topic Introductions |
| 14:16 |
yboston |
Please feel free to start introducing yourselves... |
| 14:16 |
yboston |
#info yboston is Yamil Suarez @ Berklee College of Music - DIG meeting facilitator |
| 14:17 |
Stompro |
#info Stompro is Josh Stompro @ Lake Agassiz Regional Library MN |
| 14:17 |
remingtron |
#info remingtron is Remington Steed, Hekman Library (Calvin College) |
| 14:17 |
|
adurrence joined #evergreen |
| 14:19 |
yboston |
OK, I think I wil start now or shoudl we cancel if no one else shows up? |
| 14:19 |
kbutler |
#info kbutler is Kate Butler, Rodgers Memorial (Hudson, NH) |
| 14:19 |
remingtron |
welcome kbutler! |
| 14:20 |
yboston |
lets begin |
| 14:20 |
yboston |
not sure in kmlussier is around, so for now I will start with |
| 14:20 |
yboston |
#topic last meeting's action items |
| 14:20 |
kmlussier |
I'm here |
| 14:20 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 14:20 |
yboston |
nice |
| 14:20 |
yboston |
#info 1) Stompro will follow up with krvmga on Added Content documentation |
| 14:21 |
|
RoganH joined #evergreen |
| 14:21 |
Stompro |
I sent Jim an email and he said he didn't have any outstanding docs. |
| 14:21 |
yboston |
OK |
| 14:21 |
Stompro |
So I'll move forward with the items I took over from him. |
| 14:21 |
yboston |
excelent |
| 14:21 |
Stompro |
When I have a chance, we are getting into the mapping/library settings phase of our migration, so I have less time. |
| 14:22 |
kmlussier |
Fun! |
| 14:22 |
yboston |
shoudl I add an action item like: #action Stompro will continue working on Added Content documentation additions |
| 14:22 |
yboston |
? |
| 14:22 |
Stompro |
He did give me some Novelist Select setup instuctions that Might fit into the added content section. |
| 14:22 |
Stompro |
I don't think it needs an action item, I've got it marked off on the documentation needs page. |
| 14:23 |
yboston |
OK |
| 14:23 |
yboston |
moving on |
| 14:23 |
yboston |
#info 2) kmlussier will complete the marc stream importer work and check on the status of the RDA docs |
| 14:23 |
yboston |
I can postpone for next meeting |
| 14:24 |
kmlussier |
#info kmlussier has started the marc steam importer docs |
| 14:24 |
yboston |
kmlussier++ |
| 14:24 |
kmlussier |
Progress |
| 14:24 |
remingtron |
kmlussier++ #progress! |
| 14:24 |
kbutler |
kmlussier++ |
| 14:24 |
yboston |
should I post the sae action item? |
| 14:24 |
kmlussier |
At this rate, they might be done by 2020. :) |
| 14:24 |
kmlussier |
Yes, please do. |
| 14:24 |
yboston |
*same |
| 14:24 |
yboston |
OK |
| 14:25 |
yboston |
#action kmlussier will complete the marc stream importer work and check on the status of the RDA docs |
| 14:25 |
yboston |
#info 3) remingtron will send out an email to the Dig list anouncing that a new file extension will be used for AsciiDoc files |
| 14:25 |
remingtron |
I was made aware of a possible problem with the way git tracks history when a file name changes. So I want to test that before any more public announcements. |
| 14:25 |
yboston |
interesting |
| 14:26 |
yboston |
I understood that it usually catches name changes |
| 14:26 |
remingtron |
don't want to mess up git history too much, especially for a non-essential change |
| 14:26 |
kmlussier |
I added a release notes entry with the adoc extension yesterday. But Stompro noted that an update needs to be made to the script that generates the release notes. |
| 14:26 |
yboston |
let me know if I can help |
| 14:26 |
remingtron |
git does catch name changes, but it doesn't show history nicely |
| 14:26 |
yboston |
oh |
| 14:26 |
yboston |
good to know that now |
| 14:27 |
kmlussier |
We'll need to make sure that gets done before the release notes are generated for 2.9. Or we'll have to make sure we stick to the txt extension on those for now. |
| 14:27 |
remingtron |
kmlussier: sounds like we just need a LP bug for that? |
| 14:27 |
yboston |
any volunteers for reachign out to Robert? |
| 14:27 |
kmlussier |
Yes, +1 to LP entry |
| 14:27 |
kmlussier |
yboston: That's not a Robert thing. |
| 14:28 |
Stompro |
New docs can at least start using .adoc, even if the full conversion is spaced out. |
| 14:28 |
yboston |
sorry, misunderstoofd |
| 14:28 |
kmlussier |
The script was originally created by miker and is usually handled by the RM. But anybody could update it. It's in the release notes next directory. |
| 14:28 |
yboston |
yes, LP bug should help get things started |
| 14:28 |
Stompro |
I can create the LP bug. |
| 14:29 |
kmlussier |
Stompro++ |
| 14:29 |
remingtron |
thanks Stompro |
| 14:29 |
yboston |
I have been meaning to learn how to build release notes. I will look at it in case it is a simple fix |
| 14:30 |
yboston |
#action Stompro will create LP bug for teaching the release notes creation bacth file(s) to handle .adoc file suffuxes |
| 14:30 |
yboston |
(sorry for my spelling, when I type fast) |
| 14:30 |
Stompro |
I'll do it in a few minutes, no need for an action item... |
| 14:30 |
yboston |
anything else on this issue/topic before me move on? |
| 14:31 |
remingtron |
Stompro: you're that much more ahead on next meeting :) |
| 14:31 |
yboston |
moving on |
| 14:31 |
yboston |
#info 4) remingtron will begin testing use of and conversion to the .adoc extension |
| 14:32 |
yboston |
is there more to say about this? |
| 14:32 |
remingtron |
not yet, I'll keep working on it |
| 14:32 |
yboston |
no problem at all |
| 14:32 |
yboston |
remingtron++ |
| 14:32 |
yboston |
moving on |
| 14:32 |
yboston |
#info 5) kmlussier will send out an email to DIG list to request updates on unfinsished 2.8 new features |
| 14:33 |
kmlussier |
Hmmmm |
| 14:33 |
yboston |
also related to this |
| 14:33 |
yboston |
#info 6) kmlussier will follow up with direct emails to request updates on unfinsished 2.8 new features or to ask for works in progress |
| 14:33 |
yboston |
I can postpone |
| 14:33 |
kmlussier |
Sorry, I can do that today. |
| 14:34 |
yboston |
I can repost so you are a head for next week :) |
| 14:34 |
yboston |
sorry, next month |
| 14:34 |
yboston |
#action kmlussier will send out an email to DIG list to request updates on unfinsished 2.8 new features |
| 14:34 |
yboston |
#action kmlussier will follow up with direct emails to request updates on unfinsished 2.8 new features or to ask for works in progress |
| 14:34 |
yboston |
should I move on? |
| 14:35 |
kmlussier |
sure |
| 14:35 |
yboston |
OK |
| 14:35 |
yboston |
#info 7) yboston will move the undocumented content of the 2.8 new feature “TPAC Discoverability Enhancements” to its own section in the docs |
| 14:35 |
yboston |
I started workign on this, but not done |
| 14:35 |
yboston |
I came up with three possible locations, and I emailed dbs today to ask his opinion in case he had any ideas |
| 14:36 |
remingtron |
yboston++ #progress! |
| 14:36 |
yboston |
the locations are 1) "Using the Public Access Catalog" 2) developer resoruces, where we might encourage developers to keep addign support |
| 14:36 |
yboston |
3) As an appendix to |
| 14:37 |
yboston |
the whole manual |
| 14:37 |
Stompro |
yboston++ |
| 14:37 |
yboston |
I will psotpone for next meeting |
| 14:37 |
yboston |
but let me know if you have anythoughts right now off the top of your head |
| 14:37 |
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:38 |
remingtron |
yboston: I think I'd vote for 1), without looking into it |
| 14:38 |
yboston |
thanks, that is all I wanted for now |
| 14:38 |
yboston |
moving on |
| 14:39 |
yboston |
#info 8) remingtron will contact Robert Soullier about updating the docs sites to match the footer of the regular EG site; also to add the CC icon |
| 14:39 |
remingtron |
done! |
| 14:39 |
yboston |
nice |
| 14:39 |
remingtron |
#info See the new footer at: http://docs.evergreen-ils.org/ |
| 14:39 |
* kmlussier |
agrees with remingtron on location for schema.org docs |
| 14:39 |
yboston |
kmlussier: thanks |
| 14:39 |
remingtron |
rsoulliere++ (spelling?) |
| 14:40 |
remingtron |
Robert changed the footer for docs version 2.6+, since those are the current supported versions |
| 14:40 |
yboston |
cool |
| 14:41 |
yboston |
rsoulliere++ (I looked up spelling) |
| 14:41 |
kmlussier |
rsouilliere++ |
| 14:41 |
yboston |
moving on? |
| 14:41 |
yboston |
#info 9) kmlussier will add an agenda item tot he web team about updating the doc site footers to match the main site footer, as well as include the CC icon |
| 14:42 |
kmlussier |
Done |
| 14:42 |
kmlussier |
The web team didn't think it was critical for the two footers to match. |
| 14:42 |
yboston |
cool |
| 14:42 |
yboston |
OK |
| 14:42 |
kmlussier |
They had one request to update the copyright date in the docs footer, but it looks like that happened. |
| 14:43 |
kmlussier |
We're also looking to add the CC licensing for the web site contact, but gmcharlt and I first need to do some work to reach out to content creators for the WP site. |
| 14:43 |
kmlussier |
Ugh. Not web site contact. Web site content. |
| 14:43 |
yboston |
OK |
| 14:44 |
yboston |
anything else? |
| 14:44 |
kmlussier |
nope |
| 14:44 |
yboston |
menaing, comments from someoen else or quesitons |
| 14:44 |
remingtron |
nothing from me |
| 14:44 |
yboston |
OK |
| 14:44 |
kbutler |
I'm good. |
| 14:44 |
yboston |
that is the last of the previous meeting action items |
| 14:45 |
yboston |
on the agenda we have various topics that we can discuss |
| 14:45 |
yboston |
http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20150806-agenda |
| 14:45 |
yboston |
web client docs, re-org, etc |
| 14:45 |
yboston |
any requests? |
| 14:46 |
remingtron |
how about 2.8 progress? |
| 14:46 |
remingtron |
I'd like to discuss how we might push things forward to completion |
| 14:46 |
remingtron |
thoughts? |
| 14:46 |
yboston |
good topic |
| 14:46 |
remingtron |
(I don't mean make people feel bad who signed up for something and haven't done it, but I do mean following up when necessary) |
| 14:47 |
yboston |
we have plans to have kmlussier reach out |
| 14:48 |
remingtron |
yes, kmlussier's coming emails are certainly the right idea |
| 14:48 |
Stompro |
How would people feel about adding the date next to their name when they sign up for an item, so it is easy to see which items are over 6 months old, and probably not being activly worked on? |
| 14:49 |
remingtron |
my hope is that we can find an effective way to finish up the last 10% of each version |
| 14:49 |
kmlussier |
Yeah, there are just a handful of items. Two of them are mine, but I have a working branch that is partially completed. |
| 14:49 |
kbutler |
I think one of them is mine. I should finally have time to work on it in the next week or two. |
| 14:50 |
yboston |
when we get to the that last 10%, I guess we can get more veteran volunteers |
| 14:50 |
yboston |
to offer to take over |
| 14:50 |
remingtron |
kmlussier and kbutler: thanks to both of you! |
| 14:50 |
yboston |
for the folks that are not done, or at least help them finsish up |
| 14:51 |
remingtron |
yboston: that's what I'm wondering, how we can make this a more collaborative project so it's easy to help out a little here and there |
| 14:51 |
remingtron |
it seems GitHub could facilitate that well |
| 14:51 |
yboston |
I defiently see Gists helping |
| 14:51 |
remingtron |
kmlussier: can you easily push your working branch to github for collaboration? |
| 14:52 |
kbutler |
I would definitely like to get more comfortable using GitHub. |
| 14:52 |
kmlussier |
I could push it to the working repository |
| 14:52 |
remingtron |
or should we declare that the master repo is open for such half-finished work? |
| 14:52 |
yboston |
I just started experimenting pushing a copy of EG git repo on Github so I can store works in progress |
| 14:52 |
yboston |
I can share my notes with folks |
| 14:52 |
kbutler |
yboston that would be great |
| 14:52 |
kmlussier |
To be honest, I'm going to be working a lot on billing docs through the end of the month anyway, so it's just as easy for me to finish them up at this point. |
| 14:53 |
remingtron |
if we just use the master repo, then people can easily "fork" the repo, make their edits, and make a pull request even if their work isn't done |
| 14:53 |
kmlussier |
Is there a reason we would be pushing those to GitHub instead of the working repository? For those of us who are already comfortable with pushing branches there? |
| 14:53 |
Stompro |
What about public gists for collaboration? Maybe just include links to the gist from the documentation needs page? |
| 14:53 |
yboston |
Stompro: I was just thinking that |
| 14:53 |
remingtron |
kmlussier: I'm mostly thinking of those not comfortable with git |
| 14:54 |
kmlussier |
Ah, ok. That makes sense |
| 14:54 |
remingtron |
so a web-only interface would be beneficial |
| 14:54 |
yboston |
I was just working with Carole from Bibliomation by sharing both a public and a private Github Gist |
| 14:54 |
yboston |
to fix some issues she had |
| 14:54 |
yboston |
went well |
| 14:55 |
remingtron |
Stompro: gists could work; it leaves a little more work for whoever pushes it into the master repo, but it's an improvement on our current process |
| 14:56 |
yboston |
I do like the idea of havign folks post a link to a Gist at the end of a DIG hackfest or hack-a-way |
| 14:56 |
yboston |
so that we get at least a quick snapshot of |
| 14:56 |
yboston |
where people left of |
| 14:56 |
yboston |
off |
| 14:56 |
remingtron |
yboston: yes, great idea |
| 14:56 |
yboston |
or even a Google Doc link |
| 14:56 |
yboston |
Stompro++ |
| 14:57 |
remingtron |
also, I'd like to formally propose that we ask the Dev list if we can use the master repo docs folder for work-in-progress, with the promise that it will be nice before a version is released |
| 14:57 |
remingtron |
I think that would allow us more freedom for using GitHub for collaboration |
| 14:57 |
yboston |
or what about a working branch for DIG work in progress? |
| 14:57 |
yboston |
just to offer to solutions to the devs |
| 14:57 |
yboston |
*two |
| 14:57 |
kbutler |
I think keeping work in progress in relatively one spot would probably help. |
| 14:58 |
remingtron |
yboston: I don't think EG currently has working branches on github |
| 14:58 |
kbutler |
I know when I get told 'email it, or a google doc, or github, or etc etc.' I worry which one is preferred. |
| 14:58 |
|
krvmga joined #evergreen |
| 14:58 |
yboston |
I meant to use a EG working repo topic branch for DIG to use |
| 14:58 |
yboston |
with an agreed term |
| 14:58 |
remingtron |
kbutler: we could always say "We'll take anything, but we prefer GitHub" |
| 14:58 |
yboston |
I mean name |
| 14:59 |
krvmga |
has anyone else experience the vertical green band on the right side of the staff client screen when looking at a record with parts? |
| 14:59 |
kbutler |
remingtron That's true |
| 14:59 |
yboston |
krvmga: we are havign a meeting now |
| 14:59 |
yboston |
krvmga: give us a few minutes |
| 14:59 |
krvmga |
sorry, back later |
| 14:59 |
yboston |
krvmga: no problem at all |
| 14:59 |
remingtron |
yboston: I don't quite understand your idea yet |
| 15:00 |
remingtron |
you mean instead of github? |
| 15:00 |
yboston |
instead of Github for those that are familiar with git and using "working" |
| 15:00 |
yboston |
but for beguiners I support using github |
| 15:00 |
remingtron |
yboston: okay, we are on the same page |
| 15:01 |
yboston |
want to twam up to play around witht his |
| 15:01 |
yboston |
? |
| 15:01 |
kmlussier |
remingtron: When you say the master repo docs folder, are you talking about doing it in github? Does it affect the master branch in the Evergreen git repository? |
| 15:01 |
* kmlussier |
is confused. |
| 15:01 |
remingtron |
kmlussier: yes, it's part of the normal master repo |
| 15:01 |
yboston |
kmlussier: I beleive he means that I would need to fork the main EG repo |
| 15:01 |
yboston |
oh |
| 15:02 |
remingtron |
kmlussier: the only difference is some folks (like me) only have commit access to the docs folder |
| 15:02 |
kmlussier |
I'm not sure I'm comfortable with partial docs being in the master repo. |
| 15:02 |
remingtron |
so I just want the Dev's to approve us using the master repo in a way that we don't currently allow for code |
| 15:03 |
remingtron |
kmlussier: any reason? |
| 15:03 |
yboston |
keep going remingtron |
| 15:03 |
yboston |
I am a little confused. Can you give an exampel of what John Doe the new contributor might do with Github, versus what you might do to push John's info |
| 15:03 |
kmlussier |
Because of the likelihood they won't be done by release time. |
| 15:03 |
yboston |
? |
| 15:05 |
kmlussier |
And I'm also not picturing how it helps improve collaboration on those docs. |
| 15:05 |
remingtron |
kmlussier: I agree, we'd need a plan for anything that's really ugly, but we currently have lots of minor issues with all of our live docs |
| 15:05 |
remingtron |
okay, here are the benefits I imagine: |
| 15:06 |
remingtron |
John Doe can use GitHub to make even a tiny edit (like fix a typo) |
| 15:06 |
remingtron |
GitHub makes it easy, so he clicks "Edit this file", which automatically forks the master repo to his GitHub account |
| 15:06 |
remingtron |
he makes the change, then clicks "Create pull request" and we get an email about it |
| 15:07 |
yboston |
oh, OK you are talking about John forking the EG master repo |
| 15:07 |
remingtron |
Now, we can use GitHub to preview it and easily merge it in |
| 15:07 |
yboston |
then doing a pull request? |
| 15:07 |
remingtron |
yboston: yes |
| 15:07 |
yboston |
sorry, for some reason I thought you meant something else |
| 15:07 |
yboston |
We followed that worlflow already with the potential GNU interns |
| 15:07 |
remingtron |
for bigger additions, like new files, we still have some work to do |
| 15:07 |
yboston |
and I think Stompro too |
| 15:08 |
yboston |
remingtron: that should handle file changes to |
| 15:08 |
yboston |
too |
| 15:08 |
kmlussier |
remingtron: But the way you describe it, the thing that gets merged in doesn't sound like it's partially finished. |
| 15:09 |
remingtron |
kmlussier: I'd want even the partially finished stuff to get added this way, and hopefully the original person can keep committing parts until it's done |
| 15:09 |
remingtron |
if they can't, then anyone else can take over |
| 15:09 |
remingtron |
or help along the way, just like a collab branch |
| 15:10 |
remingtron |
My main goal is to prevent stuff from stalling out |
| 15:10 |
Stompro |
Can't anyone fork the modified branch that the user submitted as a pull request also, and continue to work on it? |
| 15:10 |
yboston |
we could just make the user make a pull request, and that can be used to follwo up with stuff later on to finally merge it to master or release branch |
| 15:11 |
remingtron |
Stompro: probably, so maybe we keep it in that pull request branch until it's done |
| 15:11 |
dbs |
Why even bother with GitHub and pull request and AsciiDoc, seriously? |
| 15:11 |
dbs |
Just let writers write and have a few Asciidoc / git-knowledgable people. |
| 15:12 |
dbs |
In Word or Google Docs or whatever: the content is the important contribution |
| 15:12 |
kmlussier |
I'm inclined to agree with dbs. I think it's great that we do so much work teaching asciidoc and finding ways to use github to make it easier, but I think it also puts off potential contributors. |
| 15:12 |
remingtron |
dbs: I support that approach |
| 15:13 |
krvmga |
i agree with dbs |
| 15:13 |
Stompro |
dbs, that is still an optiion, and I think it gets communicated to those wishing to work on documentation. Yamil mentioned that during the doc hackfest. |
| 15:13 |
yboston |
on a related note, we coudl use Google Drive, so we could share partially complete asciidoc and inital screenshots. so they stay together |
| 15:14 |
remingtron |
I guess the main thing to emphasize is "please share your work-in-progress link as soon as possible so others can help" |
| 15:14 |
kbutler |
dbs: I think sometimes that can lead to clogs where contributions do not get added. |
| 15:14 |
yboston |
more specifically, we should encourage a "data dump" / progress report at the end of hackfests, etc so we know where to pick up later on |
| 15:14 |
kbutler |
dbs: It also can make it hard for people to know if someone else is working on something already. |
| 15:16 |
yboston |
so we have reached the one hour mark |
| 15:16 |
yboston |
so I think we all agree that we need to ask for works in progress to be stored somewhere easy for new volunteers? |
| 15:16 |
kmlussier |
I don't see how collaborating in Google docs would make it more difficult to see if someone else is working on something. |
| 15:17 |
remingtron |
yboston: yes |
| 15:17 |
yboston |
kmlussier: not sure to who or what comment you are replying too? |
| 15:18 |
remingtron |
kmlussier: the key is if people are willing to share their link |
| 15:18 |
yboston |
remingtron: I agree that sharing the Gist, Google doc, etc link is key |
| 15:18 |
kmlussier |
Yes, that could be done from the wiki page where the person has added their name? |
| 15:19 |
yboston |
kmlussier: yes |
| 15:19 |
dbs |
kbutler: separate forks makes it hard to coordinate too, fwiw |
| 15:19 |
remingtron |
kmlussier: yes, can you ask in your email if people are willing to share their links that way? Google doc, gist, etc.? |
| 15:19 |
kmlussier |
remingtron: Sure thing |
| 15:19 |
yboston |
or just habe them email their text fiels and screenshots to the list |
| 15:19 |
remingtron |
dbs: a good point |
| 15:19 |
dbs |
+1 link from wiki to <wherever content lives> |
| 15:20 |
kbutler |
I'm not necessarily advocating for any particular solution, but I do think 'let the writers write wherever' has been confusing and hard to track. |
| 15:21 |
dbs |
Right. Communication is key. |
| 15:21 |
dbs |
Writers _should_ be able to communicate somehow, right? :) |
| 15:21 |
yboston |
to me the most important is havign a "paper trail" of sorts to the works in progress |
| 15:22 |
remingtron |
okay, that sounds like consensus |
| 15:22 |
remingtron |
kmlussier will mention it in her email, and I will add such a request to the wiki page |
| 15:22 |
yboston |
OK |
| 15:22 |
yboston |
we shoudl wrap up, lets get final comments and quesitosn in |
| 15:22 |
remingtron |
that's all from me, thanks all! |
| 15:23 |
yboston |
#idea encourage volunteers to submit links to their works in progress on the relevant DIG wiki page |
| 15:23 |
yboston |
any other "ideas"? |
| 15:24 |
yboston |
#idea possible palces to store works in progress to allow linking back to content include: dropbox, Google docs/drive, Github forks, Github Gists |
| 15:25 |
yboston |
anything else? |
| 15:25 |
kbutler |
Possibly instructions for using some of said locations effectively? |
| 15:25 |
kbutler |
Or just suggestions or something. |
| 15:25 |
yboston |
that makes sense |
| 15:26 |
yboston |
#idea come up with guidelines/suggestions for how to store works in progress or finsished work for DIG to access later on |
| 15:26 |
yboston |
#idea always ask volunteers to share works in progress at the end f DIG hackfest or DIG hack-a-ways |
| 15:26 |
yboston |
OK, I will end the meeting |
| 15:26 |
yboston |
3 |
| 15:26 |
yboston |
2 |
| 15:26 |
yboston |
1 |
| 15:27 |
kmlussier |
heh |
| 15:27 |
yboston |
#endmeeting |
| 15:27 |
pinesol_green |
Meeting ended Thu Aug 6 15:27:06 2015 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:27 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-08-06-14.15.html |
| 15:27 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-08-06-14.15.txt |
| 15:27 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2015/evergreen.2015-08-06-14.15.log.html |
| 15:27 |
remingtron |
yboston++ |
| 15:27 |
kmlussier |
yboston: That was a fairly big gap after the '1'. :) |
| 15:27 |
kmlussier |
yboston++ |
| 15:27 |
krvmga |
yboston++ |
| 15:27 |
kbutler |
yboston++ |
| 15:27 |
Stompro |
yboston++ |
| 15:27 |
remingtron |
kmlussier: dramatic pause |
| 15:27 |
Stompro |
Must have been network latency. |
| 15:28 |
yboston |
I wanted to give folks a chance for a last word :) |
| 15:28 |
yboston |
Is hould have done |
| 15:28 |
yboston |
1.75 |
| 15:28 |
yboston |
1.50 |
| 15:28 |
csharp |
kmlussier: yboston learned that at Berklee College of Music :-) |
| 15:28 |
yboston |
1.25 |
| 15:28 |
kmlussier |
csharp++ |
| 15:29 |
csharp |
okay, so for the logs, I did a giant purge of old hold requests and that seems to have fixed the Clear Holds Shelf checkin modifier on our test server |
| 15:30 |
csharp |
now to figure out how to do the same on production without scheduling a several-hours-long downtime |
| 15:33 |
Dyrcona |
csharp: What did you do to purge the old holds? |
| 15:33 |
dbs |
yboston++ |
| 15:35 |
|
rlefaive joined #evergreen |
| 15:38 |
Dyrcona |
We have some fairly aggressive hold aging settings: 7 days for fulfilled holds and 30 days for canceled, expired, etc. |
| 15:51 |
csharp |
Dyrcona: I just did a 'delete from' with a few reasonable parameters |
| 15:52 |
csharp |
Dyrcona: I was looking for YAOUS settings for those but didn't see them - do you do them via cron? |
| 15:52 |
Stompro |
I'm confused by Long Overdue and Lost statuses. The Example action triggers show a 6 month trigger to move to long overdue, and a 90 day trigger for moving to lost. So does something get moved to lost and then to long overdue. It would make more sense to me to move to long overdue first, and then lost sometime later? Do sites use both long overdue and lost? |
| 15:52 |
Dyrcona |
csharp: config.internal_flag |
| 15:52 |
mmorgan |
chsarp: about how many rows did you purge? |
| 15:52 |
csharp |
mmorgan: a little over 10 million |
| 15:53 |
csharp |
we have hold data back to 2006 :-) |
| 15:53 |
mmorgan |
WOW! |
| 15:53 |
csharp |
Dyrcona: thanks! |
| 15:54 |
Dyrcona |
Stompro: They're basically two words for the same thing. You can configure them how you like. Use one and not the other, use both and really confuse people, etc. :) |
| 15:54 |
Dyrcona |
csharp: Deleting works, too. :) |
| 15:54 |
mmorgan |
Stompro: right now the two options are mutually exclusive. You can use either Lost or Long Overdue ... Oh. Essentially what Dyrcona said :) |
| 15:55 |
Dyrcona |
They're intended to be mutually exclusive, but I'm not so sure they really are. |
| 15:56 |
mmorgan |
Stompro: You may want to have a look at lp 1331174 |
| 15:56 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 4, heat: 18) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 15:56 |
Dyrcona |
Using long overdue is probably better than using lost, because staff often think lost means the same as "missing" when it doesn't. |
| 15:57 |
Stompro |
mmorgan, thanks for the link. |
| 15:57 |
Dyrcona |
That said, we use lost. |
| 15:57 |
mmorgan |
I think the original idea for Long Overdue was to distinguish between items billed through an automated process vs. billed because they were declared lost by the patron. |
| 15:57 |
Stompro |
Is it possible to use Lost for manually marked lost items, but use the action trigger for long overdue? |
| 15:57 |
Dyrcona |
mmorgan++ # And here I thought that had already gone in at some point. |
| 15:58 |
Dyrcona |
Stompro: Think so, 'cause "mark lost by patron" only understands lost. |
| 15:58 |
Stompro |
Great, thanks. |
| 15:58 |
mmorgan |
I think the current functionality is what Stompro is looking for. |
| 15:59 |
Stompro |
mmorgan++ Dyrcona++ |
| 16:00 |
mmorgan |
FWIW, currently we aren't automatically billing patrons by marking items Lost or Long Overdue. We're waiting for negative balances to go away :) |
| 16:03 |
kmlussier |
mmorgan: Next upgrade! |
| 16:04 |
mmorgan |
:-D |
| 16:10 |
|
Dyrcona joined #evergreen |
| 16:34 |
berick |
haha, george_duimovich++ |
| 16:42 |
|
bmills joined #evergreen |
| 16:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 16:57 |
Dyrcona |
Does the live test do a fresh install and run tests? |
| 16:58 |
Dyrcona |
Does it run pgtap as well as perl tests? |
| 17:06 |
|
mmorgan left #evergreen |
| 18:07 |
|
bmills joined #evergreen |
| 18:10 |
|
jonadab_znc joined #evergreen |
| 18:15 |
|
bmills1 joined #evergreen |
| 18:21 |
|
jonadab_znc joined #evergreen |
| 18:23 |
|
eady joined #evergreen |
| 18:36 |
bshum |
parsr++ |
| 19:22 |
|
dbwells_ joined #evergreen |
| 19:56 |
kmlussier |
parsr++ indeed |
| 20:10 |
|
buzzy joined #evergreen |
| 20:50 |
|
buzzy joined #evergreen |
| 22:17 |
jeff |
lies, damned lies, and service area coverage maps. |
