Time |
Nick |
Message |
04:36 |
|
serflog joined #evergreen |
04:36 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged. | Large pastes at http://paste.evergreen-ils.org |
04:53 |
|
pastebot joined #evergreen |
06:02 |
csharp |
@dessert add "Lemon Chess Pie" |
06:02 |
pinesol_green |
csharp: The operation succeeded. Dessert #4 added. |
07:40 |
|
jboyer-laptaupe joined #evergreen |
07:51 |
|
rjackson-isl joined #evergreen |
08:00 |
|
collum joined #evergreen |
08:04 |
|
akilsdonk joined #evergreen |
08:14 |
|
timlaptop joined #evergreen |
08:23 |
|
mrpeters joined #evergreen |
08:25 |
|
kmlussier joined #evergreen |
08:25 |
|
_bott_ joined #evergreen |
08:28 |
kmlussier |
Looks like we need to add some more desserts to the database. |
08:32 |
kmlussier |
@dessert add mllewellyn's cupcakes |
08:32 |
pinesol_green |
kmlussier: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
08:36 |
kmlussier |
@dessert add mllewellyn's cupcakes |
08:36 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #5 added. |
08:42 |
|
mmorgan joined #evergreen |
08:45 |
kmlussier |
@dessert 4 |
08:45 |
* pinesol_green |
grabs some Lemon Chess Pie for kmlussier |
08:46 |
kmlussier |
@dessert 5 |
08:46 |
* pinesol_green |
grabs some mllewellyn's cupcakes for kmlussier |
08:46 |
kmlussier |
hmm |
08:47 |
|
ericar joined #evergreen |
08:50 |
|
tspindler joined #evergreen |
08:52 |
bshum |
@dessert 5 kmlussier |
08:52 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes for kmlussier |
08:52 |
kmlussier |
bshum++ |
08:55 |
|
jbfink joined #evergreen |
08:56 |
* bshum |
is tackling tspindler's question about LP bugs and milestones on the dev list. |
08:58 |
kmlussier |
@dessert add Supreme Brownie Sundae |
08:58 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #6 added. |
08:58 |
kmlussier |
@dessert add Apple Crisp |
08:58 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #7 added. |
08:58 |
kmlussier |
I added that last dessert for bshum because I know how much he loves apple desserts. ;) |
08:59 |
kmlussier |
@dessert add Cookies and Cream ice cream |
08:59 |
pinesol_green |
kmlussier: The operation succeeded. Dessert #8 added. |
09:07 |
tspindler |
bshum: thanks, I have a vague understanding about what they might mean but I don't want to assume, you know what they say about assuming |
09:08 |
|
jeff___ joined #evergreen |
09:10 |
bshum |
tspindler: I just sent the reply, I think I'll take some of what I said and add it to the bug wrangler wiki page for the milestone section of the page. |
09:11 |
bshum |
tspindler: Thanks for asking the question, it's something I've been a bit delinquent in getting fully explained in my past roles. |
09:12 |
|
akilsdonk joined #evergreen |
09:13 |
bshum |
tspindler: I just realized I didn't say anything specific about the one bug you linked to |
09:14 |
bshum |
I note in https://bugs.launchpad.net/evergreen/+bug/1086550/comments/13 that I guess I removed the pullrequest tag off the bug because there were conflicting approaches being suggested and we hadn't reached a final conclusion over what code we were testing/reviewing. |
09:14 |
pinesol_green |
Launchpad bug 1086550 in Evergreen "TPAC: Not clear to patron how to deselect a facet" (affected: 5, heat: 24) [Wishlist,Confirmed] |
09:14 |
bshum |
Without an active pullrequest and the unfinished discussion, I guess this one slipped through the cracks during development cycles for 2.5, etc. |
09:17 |
bshum |
My recommendation is to take back the conversation and get a new pullrequest on the bug with the code that should be reviewed. |
09:18 |
bshum |
And target it for 2.next with the plan to complete it during 2.7's development cycle. |
09:19 |
bshum |
It's good to champion for the bugs we care about. And anyone can do that, developers, contributors, users alike. |
09:19 |
|
mrpeters joined #evergreen |
09:21 |
bshum |
http://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq |
09:21 |
bshum |
Does this count as me completing my long standing task of explaining LP bugs on the list? :D |
09:21 |
tspindler |
bshum: i am going to talk to dpearl about this, I think he was satisified with Mark Cooper's approach even though he had a separate approach. I appreciate also the need to champion bugs. kmlussier has pointed this out to me in different terms |
09:22 |
bshum |
tspindler++ # sounds like a plan, I look forward to looking at this one anew. |
09:23 |
kmlussier |
One nitpicky thing I just noticed on http://wiki.evergreen-ils.org/doku.php?id=dev:bug_wrangler:faq. For "Confirmed" status, it says it should be assigned an importance at the time of confirming. |
09:23 |
kmlussier |
However, any Launchpad user has the ability to confirm a bug. But you need to be a bug wrangler to assign an importance. |
09:24 |
bshum |
Fwiw, I'm fairly sure I do often assign an importance. |
09:24 |
bshum |
Hmm |
09:24 |
kmlussier |
Sure, I do now too. But before you gave me powers, I had to confirm without assigning importance. |
09:25 |
bshum |
I have mixed feelings then. I think the language as written is appropriate for bug wranglers (i.e. members of the bug team) |
09:25 |
bshum |
But if you think that anyone may be expected to mark a bug as "confirmed" status, that's something we can discuss. |
09:25 |
kmlussier |
I agree. But I also think it's helpful when non-bug wranglers can confirm a bug because it takes time to confirm them. |
09:26 |
bshum |
Nominally, I would also take a "me too" in the comments as affirming the bug's nature. |
09:26 |
bshum |
And leave the status changes and importance settings to the bug wrangler team members. |
09:27 |
bshum |
That said, historically, our core group of bug wranglers have been a bit lax in this department. :( |
09:28 |
dbs |
bshum: suggestion for the "deleted record" that might make everyone happy - just add an extra @class value that sites that don't want greyed-out bibs can just override in their CSS with background-color: inherit; or whatever? |
09:29 |
kmlussier |
Since LP already allows any LP user to mark it as confirmed, I expect some people will do it whether it's part of our best practices or not. And I don't think that's a bad thing. We just need to be aware that there may be a valid reason why an importance isn't set when somebody marks a bug as confirmed. |
09:29 |
tspindler |
If i can chime in, i thinnk keeping the status changes to the bug wrangler team is important, i think it could really muddy things if all users could do this. A regular user can argue in a comment section for its importance or indicate it was tested. |
09:29 |
kmlussier |
+1 to dbs' suggestion. |
09:29 |
kmlussier |
tspindler: I'm not advocating that all users set the importance level. But I do think it's a good thing that they can mark it as confirmed. |
09:29 |
bshum |
dbs: That's a fair suggestion. I'm not even sure how much my users will even notice or complain about its return. I was just being grumpy yesterday :\ |
09:30 |
dbs |
bshum: I understand grumpy |
09:30 |
* kmlussier |
can never tell when bshum is grumpy. |
09:31 |
bshum |
kmlussier: Perhaps we should review the FAQ to note that bug wrangler team members should set an importance for confirmed bugs if unset. |
09:31 |
bshum |
*revise |
09:31 |
kmlussier |
bshum comes across as cheerful even when he's grumpy. |
09:31 |
tspindler |
kmlussier: yes I think that makes sense, i have even mixed feelings about allowing that permission |
09:31 |
kmlussier |
tspindler: It's already allowed. |
09:31 |
tspindler |
kmlussier: understood |
09:32 |
tspindler |
kmlussier: I guess there has been no abuse from any users for confirming bugs (when they have not done the work) so I assume it has never been a problem and no need to make it one |
09:33 |
bshum |
Hard enough getting anyone to use LP in the first place :) |
09:33 |
bshum |
I encourage them to help pitch in. |
09:33 |
tspindler |
i guess it would be great then if it were a problem, more people would be contributing |
09:33 |
kmlussier |
bshum: I think confirming bugs is a great way to pitch in. But I've never marked anything as confirmed based on their bug comments, so maybe I'll start doing that. |
09:34 |
bshum |
kmlussier: Generally speaking, I only mark bugs as confirmed when I personally have confirmed them as well :) |
09:34 |
bshum |
But that's just cause my name is attached then to the bug status change email. |
09:35 |
bshum |
Otherwise, I'd just use the Triaged status to move it out of "new" status. But these days I've been doing that less since we're trying to avoid bug churn. |
09:35 |
bshum |
And also I prefer finding out whether it's really a problem. |
09:35 |
eeevil |
bshum / tspindler: I just commented on https://bugs.launchpad.net/evergreen/+bug/1086550 with a (hopefully) simpler option |
09:35 |
pinesol_green |
Launchpad bug 1086550 in Evergreen "TPAC: Not clear to patron how to deselect a facet" (affected: 5, heat: 24) [Wishlist,Confirmed] |
09:36 |
bshum |
kmlussier: "Bug wrangler team members should assign an importance, if not already set." |
09:36 |
bshum |
For revised language on the FAQ |
09:37 |
kmlussier |
bshum: +1 |
09:41 |
|
yboston joined #evergreen |
09:41 |
ericar |
bshum: I am comfortable, as a non wrangler, confirming bug and agree that the importance should be set by wranglers. And I'd be disappointed if my ability to confirm bugs was disabled. |
09:42 |
kmlussier |
ericar++ |
09:42 |
bshum |
ericar++ |
09:42 |
bshum |
If you ever feel like getting a promotion, the wrangler team is always recruiting :) |
09:44 |
|
ericar_ joined #evergreen |
09:46 |
|
ericar__ joined #evergreen |
09:51 |
bshum |
Oh come on..... IE-- |
09:58 |
* dbs |
wonders about the feasibility of turning the catalog into a card-based UI so that in the staff client you click on the top right corner of a record and it flips around to show the cataloging/circ actions on the back... |
09:59 |
* dbs |
has obviously been looking at G+ far too much. |
09:59 |
bshum |
Hehe, that'd be kind of fun |
10:00 |
dbs |
Might be a way of containing all the real estate needed for the vast set of actions we expose in the staff client |
10:01 |
jeff |
dbs: very trello! (though that's backbone and not angular!) |
10:01 |
jeff |
(which matters little) |
10:03 |
|
RoganH joined #evergreen |
10:07 |
|
mllewellyn joined #evergreen |
10:41 |
|
remingtron joined #evergreen |
10:47 |
RoganH |
I'm having one of those days where I'm trying to remember if something I remember is real or something my brain made up. |
10:47 |
jeff |
been there. |
10:47 |
jeff |
"did i fix that bug, or did i dream i fixed that bug?" |
10:48 |
jeff |
s/fixed that bug/wrote that code/ etc |
10:49 |
csharp |
@who dreams about fixing Evergreen bugs? |
10:49 |
pinesol_green |
sseng dreams about fixing Evergreen bugs. |
10:52 |
jeff |
a pox on "delimited" files that aren't. |
10:54 |
csharp |
RoganH++ # wrangling the Hack-A-Way once again ;-) |
10:57 |
RoganH |
Something I didn't mention in the email is that if a / group of organizations wanted to just sponsor it I'd take care of arrangements and save them them the hassle. |
10:58 |
RoganH |
them = them - them (apologies for multiplying thems) |
11:00 |
kmlussier |
@praise RoganH |
11:00 |
* pinesol_green |
RoganH can run a report without assistance |
11:01 |
kmlussier |
How many praises do we have? |
11:05 |
bshum |
@praise search |
11:05 |
pinesol_green |
bshum: 4 found: #1: "$who is the very model of a modern major hacker", #2: "$who is kind and patient to newbies", #3: "$who can run a report without assistance", and #4: "the upgrade came off brilliantly, and it's all..." |
11:05 |
|
jbfink joined #evergreen |
11:05 |
bshum |
Not that many I guess. |
11:06 |
pinesol_green |
[opensrf|Bill Erickson] LP#1306044 Debian Jessie Makefile.install target - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=a53e387> |
11:06 |
pinesol_green |
[opensrf|Bill Erickson] LP#1306044 Removing deprecated jabber register script - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=0d2c6d7> |
11:09 |
|
RoganH left #evergreen |
11:10 |
|
RoganH joined #evergreen |
11:15 |
|
RoganH left #evergreen |
11:15 |
dbs |
@praise add $who is one of the few who deserve to be praised |
11:15 |
pinesol_green |
dbs: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
11:16 |
dbs |
fine |
11:16 |
|
dbs joined #evergreen |
11:16 |
dbs |
@praise add $who is one of the few who deserve to be praised |
11:16 |
pinesol_green |
dbs: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). |
11:22 |
kmlussier |
dbs: Shouln't it be "deserves"? |
11:23 |
dbs |
kmlussier: mebbe. dang antecedents or whatever |
11:23 |
kmlussier |
@praise add $who is one of the few who deserves to be praised |
11:23 |
pinesol_green |
kmlussier: The operation succeeded. Praise #5 added. |
11:24 |
dbs |
Of course out of context that's going to seem weird, because _many_ people deserve praise in this community |
11:25 |
dbs |
it was mostly about how few @praises we had. |
11:26 |
kmlussier |
Funny. @dessert already has more responses and it's less than 24 hours old. |
11:26 |
kmlussier |
It's easier to think up tasty desserts than to think of a good way to praise people. |
11:27 |
mmorgan |
perhaps some would prefer dessert over praise ;-) |
11:28 |
kmlussier |
mmorgan: I generally prefer dessert over most things. |
11:28 |
mmorgan |
me too! |
11:29 |
dbs |
@praise [dessert] |
11:29 |
* pinesol_green |
grabs some of mllewellyn's Cupcakes is the very model of a modern major hacker for dbs |
11:29 |
|
vlewis joined #evergreen |
11:29 |
kmlussier |
Well, that was interesting. |
11:31 |
|
dreuther joined #evergreen |
11:32 |
bshum |
Heh |
11:34 |
bshum |
ericar++ # joining our intrepid bug wrangler force |
11:34 |
bshum |
Welcome to the team! :) |
11:41 |
|
tspindler1 joined #evergreen |
11:44 |
bshum |
gmcharlt: berick: What version of automake does Jessie use at the moment? Wondering if you guys encountered or dealt with similar issues like csharp and I noted in https://bugs.launchpad.net/opensrf/+bug/1272937 |
11:44 |
pinesol_green |
Launchpad bug 1272937 in OpenSRF "OpenSRF configure.am showing deprecation warnings with autoreconf -i step" (affected: 2, heat: 10) [Undecided,New] |
11:45 |
gmcharlt |
bshum: yep, I've seen that |
11:45 |
gmcharlt |
doesn't prevent installation, although obviously it's annoying and should be cleaned up |
11:45 |
kmlussier |
ericar++ indeed |
11:49 |
bshum |
gmcharlt: Yeah that's what I found as well. I was just checking. |
11:49 |
bshum |
gmcharlt: Thanks. |
11:50 |
bshum |
The error at line 30 is actually simple to repair on face value. It's the INCLUDES vs. AM_CPPFLAGS part that looks like it'll be slightly more complex. |
11:57 |
|
krvmga joined #evergreen |
11:58 |
krvmga |
i think i don't understand how the library list in Show More Details works. take a look at this URL http://bark.cwmars.org/eg/opac/results?query=davinci%20code%20brown;qtype=keyword;locg=1;detail_record_view=1;page=0 For number 5, why does the second, checked out item show up? i thought checked out items wouldn't show in this view. |
11:59 |
bshum |
krvmga: It's only one of 2 copies. I would assume the others have more copies with more relevant statuses. |
12:00 |
kmlussier |
krvmga: It shows, it's just ranked lower. |
12:00 |
kmlussier |
For a title with a lot of copies, it might not show at all since this page only displays a certain number of copies (5?). |
12:01 |
bshum |
That seems different than it ought to be. Customized? |
12:01 |
kmlussier |
Different in what way? |
12:02 |
krvmga |
kmlussier: i think the page is only supposed to show 5 (although it sometimes shows 6) |
12:03 |
bshum |
Ah okay I get it now |
12:03 |
bshum |
It's five unique lines of Library + Shelving Location + Call Number. |
12:03 |
bshum |
If there happen to be more copies for that given set, it'll display up to five of those as well. |
12:04 |
bshum |
http://acorn.biblio.org/eg/opac/results?query=da+vinci+dan+brown&qtype=keyword&fi%3Aitem_type=&locg=1&sort= (our number 5, for example) |
12:05 |
bshum |
The first two groups have 3 copies each, but same lib + shelving + call number |
12:05 |
bshum |
But then the next three lines are same lib, different shelving and call numbers |
12:05 |
bshum |
So that's how it adds up to 5. |
12:05 |
krvmga |
what i think i'm seeing is that the checked out item is always the last one in the library list. |
12:05 |
bshum |
That's what I would expect. |
12:05 |
bshum |
The available copy matters most to me. |
12:07 |
krvmga |
for instance http://bark.cwmars.org/eg/opac/results?query=hunt%20for%20red%20october;qtype=keyword;locg=1;detail_record_view=1;page=0 numbers 1, 15, and 33. the last library in the list, the item is checked out |
12:07 |
bshum |
For 1, it's the only library with a copy? So that's "normal" :) |
12:07 |
krvmga |
1 and 15, it's the only item in the list |
12:07 |
bshum |
Same for 2 |
12:07 |
kmlussier |
krvmga: And to give a little background, that's something MassLNC requested way back when we were working with dbs on some TPAC development. Previously, a library's checked out copy might appear on the search results page when there was an available copy that didn't display. The patron might not click in to get more information. |
12:07 |
bshum |
Err, 15 |
12:08 |
|
Shae joined #evergreen |
12:08 |
krvmga |
kmlussier: are you saying this is a feature then? |
12:08 |
bshum |
And for 33, there's only 3 copies at all. |
12:08 |
bshum |
Why is this a bad thing? |
12:08 |
kmlussier |
krvmga: It was for us. Do you want checked out copies to display ahead of available ones? |
12:08 |
|
akilsdonk joined #evergreen |
12:08 |
krvmga |
bshum: i'm not saying it's a bad thing. i'm just trying to be able to explain the behavior coherently to library directors who are asking me about it. |
12:09 |
krvmga |
kmlussier: in 33, for instance, the checked out item is also the last library in alphabetical order |
12:09 |
|
jihpringle joined #evergreen |
12:10 |
krvmga |
kmlussier: i found an example where it works the way you described it. |
12:11 |
kmlussier |
Yeah, 33 doesn't look right to me. |
12:11 |
krvmga |
kmlussier: this search http://bark.cwmars.org/eg/opac/results?query=guns%20of%20navarone;qtype=keyword;locg=1;detail_record_view=1;page=1 number 19 |
12:11 |
krvmga |
kmlussier: the last library is not in alphabetical order |
12:11 |
kmlussier |
I have another thought. Hold on, let me look up the bug number... |
12:12 |
kmlussier |
I know https://bugs.launchpad.net/evergreen/+bug/1234845 was loaded on your test server a while back, and we talked about loading it in production because it looked good under my testing. |
12:12 |
pinesol_green |
Launchpad bug 1234845 in Evergreen "possible optimization for evergreen.ranked_volumes database function" (affected: 2, heat: 12) [Medium,Triaged] |
12:13 |
kmlussier |
Do you know if it ever was loaded in production? Because, if so and if my testing didn't catch something, that's where you would see the problem. |
12:14 |
krvmga |
kmlussier: i do not know if it was. i'll see if i can find out. |
12:14 |
kmlussier |
Nice. I actually listed what the expected ranking behavior was in my testing notes. It should be preferred library -> search library name ->call number label -> availability. |
12:17 |
jeff |
asking because it just came up in conversation: does anyone have an example of where you might use a copy's "reference" attribute vs the copy's "circulate" attribute (or perhaps more commonly, the copy's location's "circulate" attribute)? |
12:18 |
jeff |
i.e., is there a situation where "reference" wouldn't just be an inverse of "circulate"? |
12:19 |
gmcharlt |
jeff: to explain why it doesn't circulate, particulary for reference books that are interfiled with circulating material |
12:20 |
|
kmlussier left #evergreen |
12:21 |
mmorgan |
jeff: "reference" is a flag that can be used as a circ matrix matchpoint. We have some libraries that circulate some reference materials with a shorter loan period and higher fine than other materials. |
12:21 |
jeff |
gmcharlt: does reference display in the staff or public view of the catalog, and/or does an attempt to check out the item throw a different message to staff? |
12:21 |
* jeff |
looks |
12:21 |
jeff |
mmorgan: okay, that was one example that i had wondered about -- good to know. |
12:25 |
|
RoganH joined #evergreen |
12:33 |
|
mmorgan left #evergreen |
12:42 |
|
RoganH left #evergreen |
12:44 |
|
RoganH joined #evergreen |
12:52 |
bshum |
omg, 8 days, 8 hours for auth to bib linking? |
12:52 |
* bshum |
dies a little inside |
12:53 |
* RoganH |
buys bshum a mint shake. |
12:54 |
* bshum |
admires ktomita_'s patience. |
12:55 |
bshum |
I don't think I would survive that long. |
12:55 |
ktomita_ |
bshum: I just started it and walked away. |
12:56 |
bshum |
Heh |
12:57 |
|
hbrennan joined #evergreen |
12:59 |
RoganH |
ktomita_: SSDs? |
13:00 |
bshum |
I wonder if other activity on the same server would slow things down. |
13:00 |
bshum |
Like any bib changes, acq loading, item deletions. |
13:00 |
bshum |
I don't have any experience, just pondering |
13:00 |
RoganH |
bshum: btw, forget SSDs, pure PCIe flash storage |
13:01 |
bshum |
RoganH: I really wanted PCIe storage, but I couldn't sell it to the higher ups this round |
13:01 |
bshum |
I needed to do more research too on if that allows for good RAID options. |
13:01 |
ktomita_ |
this was just done on a single box with an SSD. Nothing else was run on the server |
13:01 |
RoganH |
bshum: I got it in my new laptop and I cry with joy a little every time I run a VM. |
13:05 |
|
ericar joined #evergreen |
13:07 |
|
afterl joined #evergreen |
13:08 |
bshum |
Mini break at BiblioHQ for mllewellyn cake (island style for the last day of our intern working on Islandora) |
13:08 |
* bshum |
comes back with a slice |
13:31 |
|
RoganH left #evergreen |
13:32 |
|
dkyle joined #evergreen |
13:35 |
|
kmlussier joined #evergreen |
13:58 |
mceraso |
mllewellyn++ #delicious cake! |
13:59 |
jeff |
aha! |
14:00 |
|
dbs joined #evergreen |
14:00 |
jeff |
force checkin of a copy (let's pretend it isn't needed for a hold/etc) at a location other than that copy's circ_lib (let's pretend the copy isn't floating) results in 1) a transit being created to send the copy to its circ_lib followed by a changing of the copy's status to Reshelving instead of in-transit. |
14:01 |
jeff |
er, forgot to number the second step as 2) |
14:01 |
jeff |
but anyway, bug identified! |
14:04 |
dbs |
kmlussier++ # we should get that sorting behaviour into the catalogue docs |
14:04 |
jeff |
in the words of the G.I. Joe character "Launchpad", "identification isn't even half the battle!" |
14:06 |
kmlussier |
dbs: Agreed |
14:07 |
kmlussier |
krvmga: Those public catalog docs you shared yesterday, are those targeted for end users (i.e. library patrons) or library staff? |
14:07 |
* kmlussier |
hasn't had a chance to look at them. |
14:10 |
* dbs |
hasn't had time yet either |
14:10 |
* dbs |
takes off again |
14:11 |
jeff |
seems like expecting non-staff users to read documentation to use your library catalog is unrealistic. |
14:14 |
kmlussier |
jeff: I generally was thinking the same thing. In looking at what we now have for public catalog documentation (the little we have), it also looks like we have a mish mash of material. Some more end user type "how to do a browse search" mixed with configuration options to make things behave differently. |
14:14 |
|
bmills joined #evergreen |
14:15 |
kmlussier |
Adding things like how the holdings information information is more along the lines of explaining to staff why things display the way they do, which is useful for staff, sys admins, etc. but I don't think the end user typically thinks about it. |
14:16 |
kmlussier |
I'm just grappling with the best way to present all of this information in an organized fashion. |
14:18 |
dbs |
jeff: I don't think non-staff users are going to read it. But staff need a place with answers for when patrons or other staff are asking "What the heck is going on?" |
14:18 |
* dbs |
_really_ takes off |
14:30 |
|
RoganH joined #evergreen |
14:33 |
pinesol_green |
[opensrf|Galen Charlton] LP#1234816: improve const-correctness of osrfCachePutString and osrfCachePutObject - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=8a8b4cb> |
14:33 |
pinesol_green |
[opensrf|Galen Charlton] LP#1285915: document that perl2JSON doesn't order hash keys - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=8fb4405> |
14:33 |
pinesol_green |
[opensrf|Galen Charlton] LP#1286248: remove osrf_ctl.sh - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=339ac28> |
14:34 |
|
pastebot joined #evergreen |
14:59 |
|
kmlussier left #evergreen |
15:08 |
|
jbfink joined #evergreen |
15:42 |
|
RoganH left #evergreen |
15:49 |
|
kmlussier joined #evergreen |
15:53 |
|
artunit joined #evergreen |
15:56 |
|
bmills left #evergreen |
16:02 |
|
afterl joined #evergreen |
16:26 |
|
kbutler joined #evergreen |
16:27 |
|
tspindler1 left #evergreen |
16:41 |
bshum |
csharp: Hmm, you know, I can't seem to find an open bug for adding Trusty support for OpenSRF |
16:42 |
* bshum |
creates one so that he can merge csharp's branch |
16:45 |
bshum |
gmcharlt: Any issue if I were to merge csharp's Ubuntu 14.04 branch to OpenSRF master for 2.4.0-alpha target? |
16:46 |
bshum |
Happy to let it sit another weekend in case it needs more eyes, but so far, so good I think. |
16:46 |
gmcharlt |
I want to look at it |
16:46 |
gmcharlt |
also, I'm not seeing the bug # |
16:47 |
gmcharlt |
ah, there it is |
16:47 |
gmcharlt |
bshum: on second thought, go ahead |
16:48 |
bshum |
gmcharlt: Actually what I should do is take csharp's work and add the README updates as another commit. |
16:48 |
bshum |
Then give it to you for a quick glance and merge ;) |
16:48 |
gmcharlt |
ok |
16:55 |
bshum |
gmcharlt: Bug updated https://bugs.launchpad.net/opensrf/+bug/1315525 |
16:55 |
pinesol_green |
Launchpad bug 1315525 in OpenSRF "Add Ubuntu 14.04 makefile target for OpenSRF" (affected: 1, heat: 6) [Medium,Confirmed] |
17:08 |
|
bmills joined #evergreen |
17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
17:30 |
pinesol_green |
[opensrf|Chris Sharp] LP#1315525: Updating Makefile.install for Ubuntu 14.04. Removing lucid support. - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=be5c3d8> |
17:30 |
pinesol_green |
[opensrf|Ben Shum] LP#1315525: Add trusty target and remove lucid from README - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=65ce998> |
17:41 |
bshum |
Thanks gmcharlt! Now the fun part, getting Evergreen squared away.... |
17:58 |
|
edoceo joined #evergreen |
18:09 |
bmills |
https://bugs.launchpad.net/evergreen/+bug/1315552 |
18:09 |
pinesol_green |
Launchpad bug 1315552 in Evergreen "Duplicate initial search results where copy circ lib/call number owning lib are different" (affected: 1, heat: 6) [Undecided,New] |
18:30 |
bshum |
bmills: Well, that looks.... lovely |
18:30 |
bshum |
:\ |
22:14 |
* jeff |
yawns |
22:33 |
|
afterl1 joined #evergreen |