| Time |
Nick |
Message |
| 01:39 |
bshum |
@later tell csharp Check out this error that I'm seeing when using the holds patches that eeevil and senator put together -- https://bugs.launchpad.net/evergreen/+bug/1272316/comments/19 |
| 01:39 |
pinesol_green` |
bshum: The operation succeeded. |
| 01:39 |
pinesol_green` |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed] |
| 01:48 |
bshum |
Bleh, make that every time a hold is placed, retargeted, etc. |
| 02:06 |
bshum |
Yep, and that error prevents the hold from processing at all. Double bleh. |
| 02:16 |
bshum |
Ahhh, I found my mistake |
| 02:16 |
bshum |
Missing part of one commit |
| 02:16 |
bshum |
I think |
| 02:16 |
bshum |
Yeah, error is gone. Nevermind, all is well after all. |
| 02:50 |
|
gmcharlt joined #evergreen |
| 07:35 |
|
rjackson-isl joined #evergreen |
| 07:54 |
csharp |
bshum++ # testing through the night |
| 08:07 |
|
remingtron joined #evergreen |
| 08:08 |
|
akilsdonk joined #evergreen |
| 08:13 |
|
kbeswick joined #evergreen |
| 08:26 |
|
kmlussier joined #evergreen |
| 08:28 |
kmlussier |
A question for csharp, bshum, and/or eeevil regarding the fix for https://bugs.launchpad.net/evergreen/+bug/1272316/ |
| 08:28 |
pinesol_green |
Launchpad bug 1272316 in Evergreen "much slower holds processing in 2.4+" (affected: 10, heat: 46) [High,Confirmed] |
| 08:29 |
kmlussier |
It looks like most of the testing involved holds placement. Are you also seeing improvement for retargeting holds at checkin? Or is this fix specifically for the "place holds" issue? |
| 08:29 |
|
Shae joined #evergreen |
| 08:30 |
csharp |
kmlussier: we were not aware of a problem at checkin in PINES, so I haven't investigated that |
| 08:33 |
csharp |
I'm investigating why our users are able to edit their own accounts in Evergreen 2.5.1 - I'm not sure that this wasn't going on before that... In any case, I'm looking closely at Open-ILS/xul/staff_client/server/patron/user_edit.js for clues |
| 08:33 |
|
finnx joined #evergreen |
| 08:33 |
kmlussier |
csharp: How about in the overall holds targeting process? You had noted that it was taking longer to complete in the initial bug report. Are you seeing improvements there? |
| 08:34 |
csharp |
kmlussier: let me check that and get back to you |
| 08:34 |
kmlussier |
csharp++ Thanks! |
| 08:49 |
|
timlaptop joined #evergreen |
| 09:07 |
csharp |
kmlussier: from my testing, I can see the hold targeter churning through far faster than before |
| 09:07 |
csharp |
before the messages would hang, then move, then hang then move |
| 09:08 |
csharp |
now they're moving pretty fast |
| 09:08 |
|
tsbere_ joined #evergreen |
| 09:10 |
csharp |
on a related note, has anyone implemented a "delete holds and notify the patron when all eligible copies are in a non-holdable status" feature? |
| 09:10 |
csharp |
I'm assuming A/T could handle that |
| 09:10 |
csharp |
s/eligible/previously eligible/ |
| 09:12 |
jeff |
We don't currently have anything like that, and I'd be a bit hesitant to introduce it without at least a timeout interval, during which reporting could give staff the opportunity to intervene. |
| 09:13 |
jeff |
But it would also probably be important to have a means to selectively suspend the pending cancellation process, and I'm not sure what form that should take. |
| 09:14 |
csharp |
jeff: good points |
| 09:14 |
tsbere |
csharp/jeff: We have a "these holds can't be filled" report that staff poke through every so often (I hope) |
| 09:14 |
csharp |
tsbere: yeah that may be a better approach |
| 09:15 |
jeff |
similar here. they show up on our standard holds ratio report with a ratio of infinity. :-) |
| 09:16 |
bshum |
kmlussier: Agreed with csharp that hold_targeter churn does seem faster than before. |
| 09:16 |
bshum |
As far as checkin, that's trickiwr |
| 09:16 |
bshum |
*trickier for me to test right now. |
| 09:17 |
bshum |
But I'm sure it'll come up soon. |
| 09:20 |
csharp |
bshum: are you running the patches in production? |
| 09:21 |
bshum |
csharp: Maybe .... :) |
| 09:24 |
csharp |
heh |
| 09:24 |
csharp |
I'm planning to roll it in next week |
| 09:25 |
csharp |
the fact is, senator's patches helped enough that 10 of the 14 library systems reporting issues stopped complaining about it |
| 09:25 |
csharp |
but eeevil's additions will make our situation optimal |
| 09:30 |
|
yboston joined #evergreen |
| 09:35 |
kmlussier |
csharp++ bshum++ #Thanks for the retargeting info! |
| 09:40 |
bshum |
kmlussier: To clarify on checkin, you're talking about what we mentioned too about things like using checkin modifiers for "retarget local holds" bombing out on crazy bibs. |
| 09:40 |
bshum |
Or like how we were suspecting regular checkin to take forever to get to a screen saying put it on hold / in transit as it processed through the opportunistic stuff |
| 09:41 |
bshum |
And causing delays on the popup / printing |
| 09:42 |
kmlussier |
I was thinking of the problem where using the "retarget local holds" checkin modifier bombed out. |
| 09:43 |
* kmlussier |
didn't know about the theory with the hold / in trasnit screen |
| 09:43 |
kmlussier |
transit |
| 09:44 |
bshum |
Well, I'm probably going to ask for feedback on both of those on our end. |
| 09:44 |
bshum |
But it's always hard to predict when it'll come up. |
| 09:45 |
* kmlussier |
nods. |
| 09:51 |
bshum |
I think now my next battle on this one will be getting rid of all the noise warnings we get for uninitialized values every hold processing. |
| 09:53 |
* eeevil |
reads up |
| 09:54 |
|
BigRig joined #evergreen |
| 09:55 |
eeevil |
kmlussier: the "at checkin" slowdown for you is because of the "retarget local holds" modifier. csharp doesn't see the issue because without that in play, holds are retargetted in the background. all hold targetting will be faster, so you will see improvement |
| 09:56 |
kmlussier |
eeevil: Thanks! That's what I was hoping to hear. |
| 09:57 |
* eeevil |
should have read further ... you and bshum basically came to that conclusion, I see |
| 09:59 |
|
mrpeters joined #evergreen |
| 09:59 |
csharp |
okay - I'll re-ask my permissions question... any hints where I would start troubleshooting an issue where staff are able to edit their own accounts? I was looking at user_edit.js initially... |
| 10:00 |
csharp |
our expectation is that staff are not able to edit themselves or other staff at or above their perm group |
| 10:00 |
* csharp |
understands that "above" is relative and means something specific to PINES ;-) |
| 10:02 |
phasefx |
the permissions should be enforced server-side there |
| 10:02 |
bshum |
csharp: So.... |
| 10:02 |
bshum |
Yes, there's a local change *I* made to our system to prevent that from happening |
| 10:02 |
bshum |
And I think I shared it once in IRC during discussions |
| 10:03 |
* csharp |
cranks up the google |
| 10:03 |
csharp |
phasefx: I'm assuming somewhere in the perlmods? |
| 10:04 |
csharp |
well, actually, I'm looking in the server-side staff client js |
| 10:04 |
bshum |
But basically there's a part of the js where it says if the user id = itself, they can edit themselves. |
| 10:04 |
bshum |
And I removed it. |
| 10:04 |
phasefx |
csharp: wherever the patron.update call. A client side check could/should disable the interface, but the act of saving it self, should it happen, should fail if you don't have permission to edit the user |
| 10:05 |
bshum |
I asked about it back when and it's some sort of safeguard in case someone were to remove the perm to edit their own group for some reason. |
| 10:05 |
bshum |
But in our case, we don't ever want them to edit themselves anyways |
| 10:05 |
csharp |
right |
| 10:11 |
bshum |
Doh |
| 10:12 |
bshum |
It's a local branch on my laptop that's labeled "bug-fixes/remove-edit-user-check" so I guess that means I never pushed it publicly. |
| 10:12 |
bshum |
I'll rebase it, and then rename the branch to push somewhere for you csharp |
| 10:12 |
|
yboston_ joined #evergreen |
| 10:12 |
bshum |
For myself, I personally have it added to our local customizations branch, but would welcome seeing it made stock behavior. |
| 10:13 |
|
kbeswick_ joined #evergreen |
| 10:14 |
|
kmlussier1 joined #evergreen |
| 10:14 |
bshum |
Oooh |
| 10:14 |
|
gmcharlt_ joined #evergreen |
| 10:14 |
bshum |
There is a public branch with it |
| 10:14 |
bshum |
Oh okay, whew |
| 10:14 |
bshum |
So I wasn't being completely derelict there |
| 10:15 |
* bshum |
does a force push anyways |
| 10:15 |
|
t8r joined #evergreen |
| 10:15 |
bshum |
csharp: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/bshum/remove-edit-user-check |
| 10:19 |
csharp |
bshum++ |
| 10:20 |
csharp |
yay - that works |
| 10:23 |
|
gmcharlt joined #evergreen |
| 10:32 |
|
dkyle joined #evergreen |
| 10:34 |
eeevil |
csharp: there is, indeed, a prohibition on editing ones own account, because you can give yourself more permissions. group application permissions should allow editing of others in your group, though |
| 10:35 |
eeevil |
csharp: IOW, it's a security concern |
| 10:38 |
eeevil |
and ... it looks like the code that bshum removed is actually backwards ... which is worse than wrong ;) ... should it simply be fixed (" || patron.id() == openils.User.user.id()") instead of removed? |
| 10:38 |
eeevil |
bshum: thoughts? |
| 10:40 |
bshum |
eeevil: That... might be. I just know that in my process removing it made things go the way we wanted. Where the users weren't allowed to edit themselves in the staff client to do things like change their own password/phone, etc. |
| 10:40 |
bshum |
Unless they were explicitly granted the group perm for themselves |
| 10:40 |
bshum |
Which reflects the policy for our consortium's staff accounts. |
| 10:41 |
eeevil |
bshum: right ... I'm contending that a user should never be able to edit themselves. their manager should maintain their account ... is that overboard? (since they can do /those/ things in the opac) |
| 10:41 |
bshum |
But uh, feel free to correct my patch. I hadn't touched it since mid-2012 apparently. |
| 10:43 |
eeevil |
no, I'm looking for consensus here. I'm concerned about self-edits for security reasons (permission elevation, etc), but is the consensus that staff (including volunteer circ staff) should be trusted to edit their own account? |
| 10:43 |
eeevil |
in the SC, I mean |
| 10:44 |
bshum |
I would be +1 to removing self-edits. But I'd be interested to hear from groups who have more distinct staff account profiles. Like those Conifer folk. |
| 10:44 |
eeevil |
put another way, do others see the potential risks (I have not, recently, attempted to exploit them, but could in the long-long ago) outweighed by the convenience of staff self-edits (what I see as a personnel management issue ... but others may not) |
| 10:46 |
jeff |
I will make time to look at the code, but I believe that the permission elevation is addressed. It is my recollection that at least in 2.2, the underlying API could permit self-edit (other than permission group), but the user editor disabled editing. |
| 10:46 |
gmcharlt |
as there is real money involved in acq and circ ... -1 to letting staff users edit themselves |
| 10:46 |
gmcharlt |
+1 to let them do password resets for themselves, for obvious reason |
| 10:47 |
jeff |
The usual use case for staff users editing themselves is when a staff member uses the same Evergreen account for work purposes as they use for checking out books as a patron. |
| 10:47 |
gmcharlt |
I'd be in favor of discouraging that |
| 10:48 |
jeff |
I'm +1 to discouraging that practice, but I believe that may be appropriate for local policy to discourage and perhaps out of place for Evergreen to discourage -- though having almost said that, I wouldn't think that recommending against it would be appropriate. :-) |
| 10:48 |
gmcharlt |
IOW, staff member's personal accounts should be separate from the ones they use to do, well, staff functions |
| 10:48 |
* jeff |
nods |
| 10:49 |
jeff |
I was typing and re-editing for too long. :-) |
| 10:49 |
gmcharlt |
well, there's a balance between local policy and good security practice |
| 10:49 |
gmcharlt |
as in the example that I know there are a lot of libraries that would just as soon be able to get the plaintext version of a patron's password so that they can relay it over the phone to patrons who call up |
| 10:49 |
csharp |
eeevil: I think your assumption that staff should not be editing their own accounts is sound |
| 10:50 |
gmcharlt |
so there is an argument -- though yes, a paternalistic one -- to be made that the software should be at least making the attempt to discourage bad security practices |
| 10:51 |
csharp |
we have a director currently pushing very hard for the convenience of self-editing - she's actually the one who brought it to our attention |
| 10:51 |
csharp |
but we have stood by the principle of the long-established "staff do not edit themselves" principle |
| 10:52 |
csharp |
bleh - too many "principles" |
| 10:52 |
csharp |
@eightball is it the school? or just the principle of the thing? |
| 10:52 |
pinesol_green |
csharp: Maybe... |
| 10:53 |
eeevil |
gmcharlt: I don't think it's paternalistic, personally. I think it's a matter of the software fulfilling its mission, in part, by providing appropriate protections so that work can be done efficiently ... but, toe may toe, toe mah toe ;) |
| 10:54 |
gsams |
FWIW, NTLC would prefer staff be unable to edit themselves. We tell them to handle password changes and such through the public interface. |
| 10:59 |
jeff |
If you can edit another user in your same group, but cannot edit yourself, what is gained by preventing editing of yourself? |
| 11:03 |
berick |
right, create another user in your group, then use that account to edit yourself ;) |
| 11:03 |
eeevil |
jeff: the ability to elevate your own permissions. I suppose you could change the other user's password and log in as them |
| 11:03 |
eeevil |
heh |
| 11:03 |
csharp |
don't group application perms control that? |
| 11:04 |
csharp |
i.e., if "Circ1" doesn't have group application perms for Circ1, that solves it, right? |
| 11:05 |
csharp |
permissions+- |
| 11:06 |
jeff |
You can't change your own user's profile. |
| 11:06 |
jeff |
You can't change someone else's profile unless you have the correct perm. |
| 11:26 |
bshum |
I think I'm with jeff. If a user/group is granted permissions with that group and the user was part of it, my expectation would have been that I could edit myself since I was part of that group. |
| 11:27 |
bshum |
We don't do that of course, but it sounds the most consistent in my head right now. |
| 11:29 |
jeff |
that is a very library thing to say. |
| 11:29 |
jeff |
@quote add <bshum> We don't do that of course, but it sounds the most consistent in my head right now. |
| 11:29 |
pinesol_green |
jeff: The operation succeeded. Quote #79 added. |
| 11:29 |
bshum |
Ha! |
| 11:34 |
jboyer_isl |
Re: permission elevation, You can't give your own account permissions that you don't already have "grantable" rights, can you? I've never seen (though I can contrive some) examples where you can give someone else a permission you don't already have. |
| 11:34 |
jboyer_isl |
That should have said "grantable rights for, can you?" |
| 11:36 |
jeff |
The underlying method call will fail if you try to change your own profile -- at all. |
| 11:40 |
jeff |
And as for individual permissions, I did a quick refresh reading of the code, and it seems to confirm my understanding that 1) you can't grant someone a permission that you don't have permission to grant, and 2) you can't have permission to grant a permission without also having that permission |
| 11:41 |
jeff |
Keeping in mind that you CAN have permission to set a profile on someone else's user or a new user where that profile may have more permissions than your current profile or your current explicit permissions. That's by design, and usually not used in that capacity, but when it is, you should be aware that you are doing it and what the possible side effects are. |
| 11:44 |
jeff |
Everything I've stated 1) is based on existing understanding combined with a quick review of the code. 2) is only talking about the API method calls, not including what additional restrictions may be placed on the client side 3) could be wrong. :-) |
| 12:09 |
|
krvmga joined #evergreen |
| 12:10 |
|
Wyuli joined #evergreen |
| 12:10 |
|
jihpringle joined #evergreen |
| 12:11 |
krvmga |
bshum: you do site-specific configuration for your libraries' catalogs. are you controlling that solely with eg_vhost.conf? |
| 12:11 |
bshum |
krvmga: ...what do you mean "site-specific" ? |
| 12:13 |
krvmga |
bshum: ansonia.biblio.org, beacon.biblio.org, bethel.biblio.org, etc. |
| 12:13 |
bshum |
Oh, that. |
| 12:15 |
bshum |
krvmga: Yes, it's mostly through eg_vhost.conf, but we're using the approach that MVLC shared with us for doing apache RewriteMap to files that control the various options. |
| 12:15 |
bshum |
So rather than defining everything in the apache config directly, we have some leeway in how it gets strung together based on various other files. |
| 12:16 |
krvmga |
bshum: thanks. i'll have to ask Dyrcona when he gets on. |
| 12:16 |
krvmga |
unless tsbere knows about this |
| 12:19 |
|
afterl joined #evergreen |
| 12:20 |
bshum |
I'm sure he does. But in any case, I can say that MVLC's approach has worked very nicely to fit our goals. |
| 12:21 |
krvmga |
bshum: what i want to experiment with is scoping the kpac to each library. |
| 12:24 |
bshum |
krvmga: Fwiw, that's something I've been wondering if tmccanna will ultimately find an alternate solution other than pref_lib for it. |
| 12:25 |
bshum |
Since PINES is now also experimenting with it and we're doing that presentation together. |
| 12:25 |
bshum |
But PINES doesn't scope the way we do |
| 12:26 |
krvmga |
bshum: that is very interesting. i'll be there. |
| 12:29 |
tsbere |
pref ou for scoping should automatically work for kpac the way MVLC does things. <_< Doesn't help those that don't do things the way MVLC does right now, though. |
| 12:29 |
bshum |
pref_lib is basically the only way to scope KPAC presently I think. |
| 12:29 |
bshum |
Otherwise, search would be defined in the kpac configuration manually, or done consortially |
| 12:41 |
jeffdavis |
krvmga: Sitka does site-specific opacs using apache config - a separate vhost for each site, some site-specific params (e.g. locg) defined as environment variables, and then a bunch of shared rewrite rules to tie everything together |
| 12:42 |
jeffdavis |
we don't use RewriteMap, but maybe we should be :) |
| 12:43 |
bshum |
I like it a lot. |
| 12:43 |
bshum |
I don't always get it at first, but they are fun. |
| 13:02 |
* tsbere |
likes the fact that MVLC only has one vhost for each SSL cert |
| 13:05 |
|
Bmagic joined #evergreen |
| 13:17 |
|
snowkitten joined #evergreen |
| 13:48 |
|
benhyman joined #evergreen |
| 13:57 |
|
ElizabethM_ joined #evergreen |
| 13:58 |
|
terran joined #evergreen |
| 13:58 |
|
abneiman joined #evergreen |
| 14:00 |
gmcharlt |
#startmeeting Evergreen Oversight Board Meeting, 27 February 2014 |
| 14:00 |
pinesol_green |
Meeting started Thu Feb 27 14:00:08 2014 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 14:00 |
pinesol_green |
Useful Commands: #action #agreed #help #info #idea #link #topic. |
| 14:00 |
pinesol_green |
The meeting name has been set to 'evergreen_oversight_board_meeting__27_february_2014' |
| 14:00 |
dbs |
That's "Oversight Boarding Meeting" if I read the subject line correctly. Which makes it sound... torturous :) |
| 14:00 |
gmcharlt |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=governance:minutes:2014-2-27 Agenda |
| 14:00 |
gmcharlt |
#topic Introductions |
| 14:01 |
gmcharlt |
EOB members please signfiy your presence with #info |
| 14:01 |
|
sborger joined #evergreen |
| 14:01 |
gmcharlt |
#info gmcharlt = Galen Charlton, ESI |
| 14:01 |
kmlussier |
#info kmlussier = Kathy Lussier, MassLNC |
| 14:01 |
ElizabethM_ |
#info ElizabethM = elizabeth mckinney, PINES |
| 14:01 |
yboston |
#info ysboston - Yamil Suarez - Berklee College of Music (EOB) |
| 14:01 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Kent County Public Library |
| 14:01 |
benhyman |
#info benhyman is benhyman, BC Libraries Co-op |
| 14:01 |
sborger |
#info sborger = Shauna Borger, Evergreen Indiana |
| 14:02 |
dbwells |
#info dbwells = Dan Wells, Hekman Library (guest) |
| 14:02 |
afterl |
#info afterl = Amy Terlaga, Bibliomation (guest) |
| 14:02 |
gmcharlt |
#info known apologies from Rogan Hamby and Chauncey Montgomery |
| 14:04 |
gmcharlt |
OK, we have a quorum |
| 14:05 |
gmcharlt |
OK, I'm going to be reordering the agenda a bit given the news about the conference |
| 14:05 |
gmcharlt |
so first up will be dbwells |
| 14:05 |
gmcharlt |
#topic Evergreen 2.6 release manager's report |
| 14:06 |
dbwells |
#info Beta cutoff and feature freeze was last Friday. |
| 14:07 |
dbwells |
#info The beta release was packaged and posted on Tuesday, 2/25 |
| 14:07 |
dbwells |
#info In all, 35 bugs were committed since alpha, which you can see here : https://launchpad.net/evergreen/+milestone/2.6.0-beta1 |
| 14:07 |
dbwells |
(still cleaning up a few) |
| 14:08 |
dbwells |
#info Summary email (similar to other milestones) is pending, hopefully tomorrow. |
| 14:09 |
dbwells |
#info RC cutoff is tentatively scheduled for 3/12 |
| 14:10 |
dbwells |
I would be remiss to not mention that at least one feature was held back to the consternation of many, but I believe it will be for the best in the end. |
| 14:11 |
dbwells |
Any questions? |
| 14:11 |
gmcharlt |
do you see any significant blockers to the release candidate cutoff? |
| 14:12 |
dbwells |
The biggest blockers will certainly be the three PG 9.3 related bugs. Don't have them handy, but they will get mention in the email tomorrow. |
| 14:12 |
dbwells |
I believe we will manage. |
| 14:13 |
gmcharlt |
any other questions |
| 14:13 |
gmcharlt |
? |
| 14:14 |
benhyman |
dbwells +1 |
| 14:14 |
gmcharlt |
ok, thanks Dan |
| 14:14 |
dbwells |
thank you |
| 14:14 |
gmcharlt |
#topic Financial report |
| 14:14 |
gmcharlt |
#link http://evergreen-ils.org/dokuwiki/doku.php?id=governance:minutes:2014-2-27 Current financial summary |
| 14:15 |
gmcharlt |
let's try that again |
| 14:15 |
gmcharlt |
#link http://list.evergreen-ils.org/pipermail/eg-oversight-board/2014-February/000669.html The real current financial summary |
| 14:15 |
gmcharlt |
#info as of 2014-02-27, at present the project's account with SFC has a positive balance of $79,512.07 |
| 14:16 |
gmcharlt |
any questions? |
| 14:16 |
|
RoganH joined #evergreen |
| 14:16 |
RoganH |
hello |
| 14:16 |
benhyman |
great to see donations @ $~60K. What is the advertising revenue? |
| 14:19 |
gmcharlt |
benhyman: that represents how a sponsorship from Lyrasis in 2011 was subdivided, in part |
| 14:20 |
benhyman |
gmcharlt - thanks - hadn't noticed it before. No more q's here |
| 14:20 |
gmcharlt |
or to be more clear, all of the advertising revenue comes from that particular transaction |
| 14:20 |
gmcharlt |
any other questions? |
| 14:20 |
gmcharlt |
ok, moving on |
| 14:20 |
gmcharlt |
#topic Evergreen 2014 Conference Committee Report |
| 14:20 |
afterl |
Before kmlussier's report, I just wanted to mention that we had a last minute sponsor/exhibitor appear on the scene - Bibliotheca for an additional $1250 in sponsorships/exhibitors (plus an additional registration). We are now at capacity for exhibitors. |
| 14:21 |
yboston |
yay! |
| 14:21 |
kmlussier |
afterl++ |
| 14:21 |
sborger |
Awesome! |
| 14:21 |
benhyman |
Bibliotheca +1 |
| 14:21 |
ElizabethM_ |
great! |
| 14:23 |
kmlussier |
I don't have much to add beyond what I sent in my e-mail regarding the budget with one small addition. |
| 14:23 |
kmlussier |
I did receive confirmation that we reached our attrition numbers for the hotel, so I have updated the budget to remove that expense. |
| 14:23 |
yboston |
yay again! |
| 14:24 |
kmlussier |
But the budget is still showing a loss at this point. My hope is that we'll have some more registrations in the next couple weeks. I also am still working to reduce those a/v costs so that we don't end up in the negative. |
| 14:24 |
kmlussier |
Does anyone have any questions about the information I sent out? |
| 14:25 |
|
ktomita_ joined #evergreen |
| 14:25 |
abneiman |
I was surprised to see registrations so low -- almost 1/3 less than expected, if I'm mathing right. Any sense why that is? Just a down year? |
| 14:25 |
abneiman |
(to be clear, not placing blame AT ALL, just wondering) |
| 14:25 |
|
Stephen joined #evergreen |
| 14:25 |
kmlussier |
No, I'm not taking it as blame. I honestly don't have an answer. |
| 14:26 |
kmlussier |
It could be because Boston is an expensive venue. It could be the earlier conference. It cold be the proximity to PLA. |
| 14:26 |
benhyman |
kmlussier - sorry - is the loss with or without Biblitheca? |
| 14:26 |
kmlussier |
Or maybe it's something else. |
| 14:26 |
kmlussier |
benhyman: It's with Bibliotheca. I had already accounted for their sponsorship when I sent the budget this morning. |
| 14:27 |
|
ktomita__ joined #evergreen |
| 14:27 |
benhyman |
kmlussier thanks. Sooooo close! Great work - we'll get to break even |
| 14:27 |
kmlussier |
afterl and I were looking at the numbers from Indianapolis when we made our projections because we thought Vancouver may have been a down year due to the international travel. |
| 14:27 |
kmlussier |
But it's looking like we'll be closer to the Vancouver numbers. |
| 14:28 |
kmlussier |
benhyman: I really do think we will be at breakeven or above, but I felt like I had to send out the worst case scenario today. |
| 14:28 |
abneiman |
I think you have a good point about PLA -- being the week after probably meant many people had to pick one or the other. |
| 14:28 |
yboston |
I arrived back from Vancouver the day of the Boston Marathon bombings, and I immediately thought that it could affect the desire of people coming to Boston |
| 14:28 |
ElizabethM_ |
Question: do we have statistics for use/viewing of taped session? |
| 14:28 |
yboston |
but it may not be related at all |
| 14:29 |
kmlussier |
benhyman: Do you know if we have those stats? |
| 14:29 |
benhyman |
kmlussier standby |
| 14:32 |
benhyman |
we streamed the breakout session in Vancouver; 30 concurrent views day 1 on avg; 60 day two on avg |
| 14:32 |
benhyman |
er - the breakout session was the tech stream |
| 14:34 |
kmlussier |
We weren't planning to stream, but just offer recordings that could be accessed later. But it's still a loss. |
| 14:35 |
kmlussier |
Once we our original plans fell through, we just had a lot of difficulty finding an alternate that was also affordable. |
| 14:36 |
benhyman |
Just peeking at Internet Archives recordings from EG2013... |
| 14:37 |
gmcharlt |
it sounds like the two main budget changes that you're seeking EOB approval are (1) dropping the bandwidth for the wireless and (2) dropping recording |
| 14:37 |
gmcharlt |
is that correct? |
| 14:37 |
benhyman |
a sampling of EG13 recordings were downloaded between 25-66 times each so far, JFYI |
| 14:38 |
kmlussier |
Those are the big ones. There are also other small adjustments that were made in other areas of the budget. Oh, and I did put the preconference down to $500 since we now know the space is free. |
| 14:38 |
gmcharlt |
indeed |
| 14:39 |
gmcharlt |
what is your view of the risk of the current AV sponsors dropping out entirely? low or high? |
| 14:39 |
afterl |
low, I think |
| 14:39 |
afterl |
Heard from Lyrasis. She's checking with others but didnt' think it would be a problem |
| 14:40 |
afterl |
Haven't heard back from the others so it's just my gut instinct I guess on them |
| 14:40 |
gmcharlt |
it occurs to me that since we don't have a keynote sponsor, offering the current AV sponsors shares in that might be an option |
| 14:40 |
kmlussier |
That's a possibility too. In fact, I think afterl may have suggested that idea to me at one point. :) |
| 14:41 |
afterl |
The concern from Lyarsis - that they retain their sponsorship privileges |
| 14:41 |
kmlussier |
aftel: Acknowlegement in the program and the web site? |
| 14:41 |
kmlussier |
And the complimentary registration? |
| 14:41 |
afterl |
Right |
| 14:42 |
kmlussier |
I think the problem with shifting to keynote at this point is that the program is already out for printing. |
| 14:42 |
Guest8499 |
sell access to the recorded sessions for those that didn't attend instead of giving it away for free? |
| 14:42 |
afterl |
Right |
| 14:44 |
gmcharlt |
if I understand correctly, we have at present no financially prudent option for any recording at all; I'm not sure I would expect people to precommit to purchasing recordings in enough numbers |
| 14:44 |
kmlussier |
Guest8499: That would be a possibility, but I think the big problem, before the budget was ever seen as an issue, was the late notice that our team couldn't record. It's been difficult to find another team on short notice. |
| 14:45 |
kmlussier |
I think it might be something for the next conference to consider. |
| 14:47 |
abneiman |
This may sound silly (and it certainly won't be professional quality) but for this conference, could we get volunteers? I mean, most smartphones can do decent audio recording. I can bring a little crappy flip video cam. Etc. Maybe that would be too much to manage, but if not, it would at least be some form of recording rather than none. |
| 14:47 |
gmcharlt |
#link https://docs.google.com/spreadsheet/ccc?key=0Ar4gDMUDwDXqdFoxZFJGbGxMYXR0bUdNYmZmc3A1M3c&usp=sharing. Feburary 2014 revision to the EG2014 conference budget |
| 14:48 |
gmcharlt |
abneiman: crowdsourcing it is something to encourage, I think, but also to make clear that it's best effort |
| 14:48 |
gmcharlt |
can I have a motion to approve the EG2014 budget revisions? |
| 14:49 |
ElizabethM_ |
I make the motion... |
| 14:49 |
ElizabethM_ |
to accept revisions. |
| 14:49 |
abneiman |
second |
| 14:50 |
gmcharlt |
#startvote Shall the EOB accept the February revision to the EG2014 budget? Yes, No, Abstain |
| 14:50 |
pinesol_green |
Begin voting on: Shall the EOB accept the February revision to the EG2014 budget? Valid vote options are Yes, No, Abstain. |
| 14:50 |
pinesol_green |
Vote using '#vote OPTION'. Only your last vote counts. |
| 14:50 |
gmcharlt |
#vote Yes |
| 14:50 |
benhyman |
#vote Yes |
| 14:50 |
ElizabethM_ |
#votes Yes |
| 14:50 |
abneiman |
#vote Yes |
| 14:50 |
yboston |
#vote yes |
| 14:50 |
kmlussier |
#vote Yes |
| 14:50 |
Guest8499 |
#vote yes (Elfstrand) |
| 14:50 |
pinesol_green |
Guest8499: yes (Elfstrand) is not a valid option. Valid options are Yes, No, Abstain. |
| 14:50 |
sborger |
#vote yes |
| 14:51 |
Guest8499 |
#vote yes |
| 14:51 |
gmcharlt |
#endvote |
| 14:51 |
pinesol_green |
Voted on "Shall the EOB accept the February revision to the EG2014 budget?" Results are |
| 14:51 |
pinesol_green |
Yes (7): kmlussier, abneiman, gmcharlt, Guest8499, benhyman, sborger, yboston |
| 14:51 |
gmcharlt |
motion carries |
| 14:53 |
gmcharlt |
#topic EOB elections |
| 14:54 |
gmcharlt |
#info motion to reduce the size of the EOB still needs to be drafted |
| 14:54 |
gmcharlt |
however, I think there was a reasonably clear consensus that dropping it to 9 next year was acceptable |
| 14:54 |
gmcharlt |
so I'd like to proceed under the assumption that two positions will be up for vote this year |
| 14:54 |
kmlussier |
+1 |
| 14:54 |
ElizabethM_ |
+1 |
| 14:55 |
gmcharlt |
also, Conservancy has announced that they have a tool and williness to run the election using STV (single-transferable-vote) |
| 14:55 |
gmcharlt |
but if we go that way, it will first require a period of time for folks who want to vote to be registered |
| 14:55 |
ElizabethM_ |
I saw that earlier. Any charge for using that? |
| 14:55 |
gmcharlt |
since the application needs to be seeded with a fixed voting list |
| 14:55 |
gmcharlt |
*voter list |
| 14:56 |
ElizabethM_ |
Can folks self-register? Sorry, I did not get a chance to investigate prior to meeting. |
| 14:56 |
kmlussier |
Do we have the time for people to register themselves? The conference is only a few weeks off. |
| 14:56 |
gmcharlt |
that said, if we announce a call for folks to register next Monday and give it a week, that would be tight but -- but arguably the folks who are really interested in voting would be paying attention anyway |
| 14:57 |
gmcharlt |
ElizabethM_: I asked, and unfortunately, self-registering is not an option |
| 14:57 |
kmlussier |
We need a couple of weeks to get nominations too, don't we? |
| 14:57 |
gmcharlt |
yeah, concurrently with gathering the rolls of voters |
| 14:58 |
gmcharlt |
OK, how about this |
| 14:58 |
gmcharlt |
- we plan on using Conservancy voting app |
| 14:58 |
gmcharlt |
- we announce a week-long period for folks to add themselves to the list of votors |
| 14:59 |
gmcharlt |
- we solicit nominations during that same week |
| 15:00 |
yboston |
sounds reasonable |
| 15:00 |
gmcharlt |
- we hold the election open from (say) 3/12 through 3/21 |
| 15:02 |
gmcharlt |
any objections? |
| 15:02 |
ElizabethM_ |
No objections from me. |
| 15:02 |
kmlussier |
It sounds good to me. |
| 15:03 |
abneiman |
OK with me |
| 15:03 |
Guest8499 |
sound resonable |
| 15:04 |
gmcharlt |
#action Voter registration will be held next week |
| 15:04 |
gmcharlt |
#action An email will be sent out by Friday to ask for nominations and self-nominations |
| 15:05 |
kmlussier |
gmcharlt: Who is taking those action items? |
| 15:05 |
gmcharlt |
to be decided shortly :) |
| 15:06 |
|
sborger joined #evergreen |
| 15:06 |
gmcharlt |
so first off, can I have three volunteers to be points of contact for potential nominees, and to help solicit them? |
| 15:07 |
gmcharlt |
as far as the votor list is concerned, I'll take it upon myself to send out the call for registration |
| 15:10 |
ElizabethM_ |
I can do it |
| 15:10 |
gmcharlt |
I'll add myself to that group |
| 15:10 |
gmcharlt |
one more volutneer? |
| 15:11 |
abneiman |
I'll do it |
| 15:11 |
yboston |
I'd like to help, but I have too much conference work to do still |
| 15:11 |
gmcharlt |
OK, so ElizabethM_, me, and abneiman |
| 15:12 |
gmcharlt |
let's work out the text of the solicitation for nominations so that we can send it out by Monday at the latest, let's say |
| 15:12 |
abneiman |
Sounds good |
| 15:12 |
gmcharlt |
of course, anybody is free to self-nominate earlier |
| 15:12 |
gmcharlt |
(if you are here and wathcing the meeting, you may be interested in joining us! ;) |
| 15:13 |
gmcharlt |
so moving quckly on |
| 15:13 |
gmcharlt |
#topic |
| 15:14 |
gmcharlt |
#topic Action items from previous meeting |
| 15:14 |
gmcharlt |
#action Work on the code of conduct should be picked up again |
| 15:14 |
gmcharlt |
any final announcements? |
| 15:15 |
benhyman |
just a quick one |
| 15:15 |
benhyman |
17 RSVP's confirmed for the Resource Allocator summit so far - hoping to round up ~5 more |
| 15:16 |
gmcharlt |
great |
| 15:17 |
gmcharlt |
the next EOB meeting is currently scheduled for 3/20 |
| 15:17 |
kmlussier |
In Cambridge? |
| 15:17 |
gmcharlt |
which falls during hte conference, of course - though I wouldn't be surprised if we'll need to tweak the date and time to reflect what else is going on at the conference |
| 15:17 |
gmcharlt |
in Cambridge with Google Hangout, I think |
| 15:18 |
gmcharlt |
or we could all sit in our hotel rooms and conduct it over IRC |
| 15:18 |
gmcharlt |
as you all prefer ;) |
| 15:18 |
benhyman |
lol |
| 15:18 |
kmlussier |
Well, there's meeting space available if we want to see what everyone looks like. |
| 15:18 |
gmcharlt |
+1 |
| 15:19 |
gmcharlt |
kmlussier: afterl: shall we defer to you for a time and a space? |
| 15:19 |
gmcharlt |
actually, let's move finalizing that to email |
| 15:19 |
kmlussier |
Well, I guess it depends on when everyone is at the conference. We usually schedule something for the morning or afternoon, right? |
| 15:19 |
gmcharlt |
thanks, everybody! |
| 15:19 |
gmcharlt |
yeah |
| 15:19 |
gmcharlt |
#endmeeting |
| 15:19 |
pinesol_green |
Meeting ended Thu Feb 27 15:19:45 2014 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:19 |
pinesol_green |
Minutes: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-02-27-14.00.html |
| 15:19 |
pinesol_green |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-02-27-14.00.txt |
| 15:19 |
pinesol_green |
Log: http://evergreen-ils.org/meetings/evergreen/2014/evergreen.2014-02-27-14.00.log.html |
| 15:20 |
yboston |
gmcharlt++ |
| 15:21 |
kmlussier |
gmcharlt++ |
| 15:24 |
|
benhyman left #evergreen |
| 15:28 |
phasefx |
maybe I'll get my hair cut for the EG conference :) |
| 15:30 |
gmcharlt |
which one? ;) |
| 15:30 |
phasefx |
haha |
| 15:31 |
kmlussier |
No way! Let your freak flag fly! |
| 15:31 |
phasefx |
wouldn't want to weigh the plane down |
| 15:35 |
berick |
@dunno add http://scientopia.org/blogs/scicurious/files/2013/03/cousin-it.png |
| 15:35 |
pinesol_green |
berick: The operation succeeded. Dunno #28 added. |
| 15:36 |
kmlussier |
berick++ |
| 15:37 |
|
krvmga joined #evergreen |
| 15:37 |
krvmga |
here's an interesting thing that just happened to us. i made a change to place_hold.tt2 in our templates directory /openils/var/cwopac_templates/opac/parts |
| 15:37 |
gmcharlt |
http://www.youtube.com/watch?v=qFPbAqOKeV0 |
| 15:38 |
krvmga |
i put a copy of place_hold.tt2 in the directory above parts /openils/var/cwopac_templates/opac |
| 15:38 |
berick |
gmcharlt: hah, forgot about that |
| 15:38 |
krvmga |
for some reason, when trying to place a hold in the catalog, evergreen picked up the place_hold.tt2 in the opac directory rather than the parts directory |
| 15:38 |
gmcharlt |
this is the second time in two days I've had occassion to link to that clip |
| 15:39 |
krvmga |
with predictable messy results |
| 15:39 |
krvmga |
is this a bug? |
| 15:40 |
krvmga |
btw, firefly is probably my all time favority show |
| 15:40 |
berick |
krvmga: opac/place_hold.tt2 and opac/parts/place_hold.tt2 are two different files, both in use |
| 15:40 |
krvmga |
berick: well that's not confusing at all |
| 15:41 |
berick |
opac/place_hold.tt2 is read, it loads opac/parts/place_hold.tt2 |
| 15:41 |
berick |
yeah, the parts/ one could use a better name |
| 15:41 |
krvmga |
but it's important to know. thanks :) |
| 15:42 |
krvmga |
with the passing of harold ramis, bill murray's "important safety tip" comment comes to mind |
| 15:44 |
bshum |
"I'm fuzzy on the whole good/bad thing." https://www.youtube.com/watch?v=jyaLZHiJJnE |
| 15:45 |
bshum |
I think I do this too often at work. |
| 15:45 |
bshum |
Quoting from movies I mean. |
| 15:48 |
krvmga |
holy cow, i don't know where my daily conversation would be without quoting from movies |
| 15:49 |
krvmga |
in fact, i'm strangely comfortable with it. |
| 15:51 |
krvmga |
it's the modern day equivalent of peppering your conversation with bits from shakespeare |
| 15:52 |
krvmga |
i've been binge-watching downton abbey and last night i heard maggie smith use the phrase "a consummation devotely to be wished" |
| 15:52 |
krvmga |
so there ya go |
| 15:52 |
krvmga |
anyway, i vote for changing the name of place_hold.tt2 in the parts directory to something less confusing and more useful |
| 15:52 |
krvmga |
berick++ |
| 15:55 |
krvmga |
devotely = devoutly |
| 15:55 |
jeff |
metabib.real_full_rec allows me to do fun things for bib QA, but some of those things are a bit of a downer, like answering the question of "can we rely on ind2 of the 505?" |
| 15:56 |
gmcharlt |
jeff: Guy Fawkes was a stooge |
| 15:56 |
gmcharlt |
the plan to blow up Parliament was actuallly initiated by a time-traveling traitorous MARC record |
| 16:00 |
|
afterl left #evergreen |
| 16:03 |
|
akilsdonk joined #evergreen |
| 16:06 |
jeff |
I have 15 bibs with an mrfr.value of length 3746 |
| 16:07 |
jeff |
which isn't the longest value, but it is the largest value shared by more than one record. |
| 16:10 |
|
Claudia_Love joined #evergreen |
| 17:02 |
|
gsams joined #evergreen |
| 17:03 |
bshum |
Oops |
| 17:03 |
bshum |
Looks like Elliot is burned on osrf_control because he's not using the OpenSRF 2.3 beta |
| 17:03 |
bshum |
In conjunction with testing for Evergreen 2.6 beta1 |
| 17:04 |
bshum |
gmcharlt: Was 2.3 cut after the last dev meeting? |
| 17:04 |
bshum |
*OpenSRF 2.3 |
| 17:05 |
gmcharlt |
no, I'll get on that now |
| 17:05 |
bshum |
I'll do some explanation for the discussion on the lists. |
| 17:05 |
bshum |
Thanks gmcharlt |
| 17:08 |
dbwells |
bshum: Thanks. I will add a column for EG2.6 to the downloads page now that we are at beta, and perhaps that will help clarify that OSRF 2.3 is required. |
| 17:09 |
bshum |
dbwells++ # Sounds like a plan! |
| 17:09 |
jeff |
bshum++ gmcharlt++ dbwells++ |
| 17:13 |
|
kmlussier joined #evergreen |
| 17:17 |
bshum |
ElliotFriend++ # for keeping us on the ball with our own instructions too :) |
| 17:17 |
bshum |
(though they're not in channel atm) |
| 17:40 |
|
dcook joined #evergreen |
| 17:47 |
pinesol_green |
[opensrf|Bill Erickson] LP#1284137: Avoid WARN logging on router shutdown - <http://git.evergreen-ils.org/?p=OpenSRF.git;a=commit;h=3692bb3> |
| 17:48 |
dbwells |
gmcharlt: I've got the downloads page ready whenever you are. |
| 17:49 |
gmcharlt |
dbwells: I'm still writing release notes; just save a draft and I'll update both when I'm rady |
| 18:04 |
|
gsams joined #evergreen |
| 18:04 |
dbwells |
gmcharlt: Apparently I am too dense to figure out how to have a draft without unpublishing the page. At any rate, my latest revision is here http://evergreen-ils.org/wp-admin/revision.php?revision=1951 |
| 18:05 |
gmcharlt |
ok |
| 18:06 |
dbwells |
gmcharlt: I went back and forth a few times restoring older revisions, so if you follow that link and just do "Restore this Revision", you should at least have a good start :) |
| 18:09 |
|
gsams joined #evergreen |
| 18:37 |
|
ktomita joined #evergreen |
| 18:41 |
|
ktomita_ joined #evergreen |
| 18:44 |
|
ningalls1 joined #evergreen |
| 18:53 |
|
ktomita joined #evergreen |
| 18:53 |
jeffdavis |
we've got a 2.6beta1 test server up and running, will start proper testing tomorrow |
| 19:37 |
|
dac joined #evergreen |
| 19:42 |
|
jeff joined #evergreen |
| 19:42 |
|
b_bonner_ joined #evergreen |
| 19:49 |
|
jeff_ joined #evergreen |
| 19:51 |
|
gmcharlt_ joined #evergreen |
| 20:29 |
|
ldwhalen joined #evergreen |
| 20:30 |
|
_bott_ joined #evergreen |
| 20:30 |
|
dkyle joined #evergreen |
| 20:33 |
|
kmlussier joined #evergreen |
| 20:33 |
|
jeff joined #evergreen |
| 20:33 |
|
jeff joined #evergreen |
| 20:38 |
gmcharlt_ |
dbwells: I've released 2.3.0-beta and pushed through your update to the Evergreen downloads page |
| 21:34 |
|
ldwhalen_ joined #evergreen |
| 21:40 |
jeff |
gmcharlt++ |
| 23:30 |
|
zerick joined #evergreen |
| 23:37 |
|
rangi joined #evergreen |
| 23:37 |
|
rangi joined #evergreen |
| 23:38 |
|
_bott_ joined #evergreen |
| 23:42 |
|
ldwhalen_ joined #evergreen |
| 23:49 |
|
rangi` joined #evergreen |
