| Time |
Nick |
Message |
| 00:47 |
|
Mark__T joined #evergreen |
| 02:19 |
|
kmlussier joined #evergreen |
| 02:19 |
|
mceraso joined #evergreen |
| 07:56 |
|
mrpeters joined #evergreen |
| 08:06 |
|
rjackson_isl joined #evergreen |
| 08:12 |
|
kmlussier joined #evergreen |
| 08:12 |
|
mceraso joined #evergreen |
| 08:12 |
|
bshum joined #evergreen |
| 08:12 |
pinesol_green |
All hail the supreme potentate, bshum has arrived! |
| 08:21 |
|
ericar joined #evergreen |
| 08:42 |
|
mmorgan joined #evergreen |
| 08:42 |
kmlussier |
Good morning #evergreen! |
| 08:43 |
mmorgan |
Good Morning! |
| 08:45 |
|
ericar_ joined #evergreen |
| 08:49 |
|
Dyrcona joined #evergreen |
| 08:53 |
|
mmorgan joined #evergreen |
| 09:04 |
Dyrcona |
dbwells++ |
| 09:15 |
kmlussier |
Hmmm...I feel like I'm missing something with the code on bug 1494544. |
| 09:15 |
pinesol_green |
Launchpad bug 1494544 in Evergreen "Void options in the billing UI allow negative balances to occur when they should be prohibited" (affected: 1, heat: 6) [Critical,Confirmed] https://launchpad.net/bugs/1494544 - Assigned to Jason Stephenson (jstephenson) |
| 09:16 |
dbwells |
kmlussier: What are you seeing, or not seeing? |
| 09:16 |
kmlussier |
Hold on, I'm re-reading your comments. |
| 09:18 |
kmlussier |
dbwells: I'm not seeing the warning. I'm using an account with void permissions, and I have prohibit negative balances set to True for the consortium. |
| 09:18 |
|
maryj joined #evergreen |
| 09:18 |
kmlussier |
When I partially pay a bill and then void it, is that when I should see the warning? |
| 09:19 |
dbwells |
It should happen with any voiding in that setup. |
| 09:20 |
kmlussier |
dbwells: It's not popping up for me. |
| 09:20 |
dbwells |
ok, will take a look |
| 09:21 |
Dyrcona |
I am just about to have a look, too. |
| 09:21 |
dbwells |
you're overdue/lost specific settings are both unset? |
| 09:21 |
dbwells |
s/you're/your/ |
| 09:21 |
kmlussier |
dbwells: Yes, they are. I just have the Default one set to True. |
| 09:22 |
kmlussier |
Thanks dbwells! While you're looking at it, I was thinking it might be better if the warning said "Voiding these bills may violate local policy by producing a negative balance." Our users like lots of clarity in their messages. :) |
| 09:24 |
* mmorgan |
is wondering about the use of the term "local policy" here. |
| 09:24 |
kmlussier |
dbwells: Ugh. Never mind! I just realized I loaded the wrong branch on the server. Sorry! |
| 09:26 |
kmlussier |
dbwells: Scratch that last comment. It is the correct branch. |
| 09:26 |
kmlussier |
This is what happens when kmlussier tests without coffee. |
| 09:26 |
mmorgan |
I agree with kmlussier - lots of clarity for users. |
| 09:26 |
mmorgan |
@coffee kmlussier |
| 09:26 |
* pinesol_green |
brews and pours a cup of Panama Esmeralda Mario Carnival, and sends it sliding down the bar to kmlussier |
| 09:26 |
kmlussier |
mmorgan: I have a cup of Honey Dew maple cream coffee sitting right next to me. I just haven't started drinking it yet. |
| 09:27 |
|
yboston joined #evergreen |
| 09:27 |
mmorgan |
Maple cream? Wow. |
| 09:29 |
kmlussier |
mmorgan: For a limited time only! |
| 09:29 |
dbwells |
kmlussier: Are the menu options showing and hiding as expected? |
| 09:30 |
kmlussier |
dbwells: I'm testing that now. |
| 09:30 |
mmorgan |
You can always tell what season it is by looking at the coffee flavors available :) |
| 09:31 |
mmorgan |
Just my $.02 about the warning message, I'd find this clearer "Voiding these bills may produce a negative balance. Are you sure you wish to continue?" |
| 09:32 |
kmlussier |
dbwells: Yes. The void option is gone now that I've removed the void permission. |
| 09:32 |
kmlussier |
+1 to mmorgan 's suggested change. |
| 09:33 |
dbwells |
kmlussier: The warning is showing up for me with the setting set as you have described. There must be some other factor I am missing. |
| 09:34 |
kmlussier |
dbwells: Do I need to exit out of the client after enabling the negative balance settings? |
| 09:34 |
dbwells |
kmlussier: Yes, all settings are cached when you login. |
| 09:35 |
kmlussier |
dbwells: Ok, you probably said that in the bug comment, and I missed it. I knew to do it for the permissions change. I'll try again. |
| 09:36 |
dbwells |
No, I didn't say that, sorry. Probably should have. It's just part of the way the client works. One of the bunch of things "Retrieved" in the login screen. |
| 09:38 |
Dyrcona |
That also means the menus do not change when you change operator. |
| 09:39 |
dbwells |
Actually, the perms are fetched with every patron load, so the menus should update. |
| 09:39 |
dbwells |
If you reload the patron, anyway. |
| 09:39 |
Dyrcona |
I'll try that. |
| 09:42 |
Dyrcona |
dbwells++ # That worked. |
| 09:46 |
kmlussier |
dbwells++ indeed |
| 09:47 |
kmlussier |
dbwells: For the most part, this branch looks very good. I just have one comment in addition to the one about the warning message. |
| 09:47 |
kmlussier |
dbwells: I see the void option was removed from the Full Details interface when the void permission is removed. This is good because there are cases where that void could produce a negative balance. |
| 09:48 |
kmlussier |
However, there isn't a corresponding adjust option there that staff can use if they want to remove a few days of an overdue fine rather than removing the entire overdue fine. |
| 09:49 |
kmlussier |
I'll add my comments to the bug, but I'm bringing it up here since people seem to be around and looking at the code. |
| 09:52 |
* kmlussier |
will have to update release notes. |
| 09:59 |
Dyrcona |
Well, you can always change the message as a local customization. |
| 09:59 |
Dyrcona |
It all seems to work for me so far. |
| 10:00 |
Dyrcona |
I have a staff meeting. |
| 10:06 |
dbwells |
kmlussier: I did wonder about that. Is that a common case? One workaround would be to first apply real payments, then adjust what remains. The crux is that all of the adjustment code from the start has considered entire transactions, since that is what is needed to know where 'zero' is. Attempting to apply the code to individual billings may just work, but it also may lead to all kinds of unexpectedness. I could hook up a button for you withou |
| 10:06 |
dbwells |
t too much trouble if you want to experiment. |
| 10:09 |
kmlussier |
mmorgan may be better able to speak to how often it occurs. I think one problem with the workaround is that patrons may not always be paying at the time that the adjustment needs to be made. |
| 10:09 |
kmlussier |
dbwells: If it |
| 10:10 |
kmlussier |
dbwells: If it is indeed not too much trouble to hook up a button, I would like to experiment with it to see if it breaks anything. |
| 10:10 |
|
krvmga joined #evergreen |
| 10:11 |
dbwells |
I also support any of the suggested warning messages. I used "violate local policy" only as an attempt to sound sufficiently scary. |
| 10:12 |
mmorgan |
What kmlussier says is often true. Adjustments to what's owed and payments often don't happen at the same time. |
| 10:13 |
dbwells |
Could we use forgive payments in these cases? Or is that frowned upon for other reasons? |
| 10:16 |
mmorgan |
dbwells: Yes, definitely those are scary words :). But warning about the actual consequences I think helps connect things in a staff member's head if they see a negative balance later. |
| 10:17 |
miker |
dbwells: forgive++ # IMHO ... that's the ongoing-transaction mechanism for "adjusting" part of the balance |
| 10:17 |
kmlussier |
In general, I think forgive tends to be used when the fine was correctly applied, but the library is "forgiving" it. Void/adjust tends to be used when staff is removing something that should not be there. |
| 10:17 |
mmorgan |
Forgive payments are generally what staff use now when a patron isn't paying a whole assessed fine. |
| 10:18 |
mmorgan |
There is definitely a distinction between a legitimately owed fine that is forgiven, and a fine that should not have been assessed in the first place. |
| 10:21 |
mmorgan |
Having a way to say "this fine should never have been assessed" that's as easy as a forgive payment would be ideal so that all the money reports make sense. |
| 10:21 |
* berick |
just realizes today is release-cutting day |
| 10:23 |
Dyrcona |
I removed my assignment on lp 1494544. I'm satisfied with what I see, if dbwells wants to do more work we can wait before pushing it. |
| 10:23 |
pinesol_green |
Launchpad bug 1494544 in Evergreen "Void options in the billing UI allow negative balances to occur when they should be prohibited" (affected: 1, heat: 6) [Critical,Confirmed] https://launchpad.net/bugs/1494544 |
| 10:23 |
mmorgan |
But right now it's so cumbersome to void partial fines, that staff never do it, and generally forgive instead. |
| 10:24 |
kmlussier |
mmorgan: Like an Account Adjustment in the payment type dropdown menu? |
| 10:26 |
mmorgan |
kmlussier: That makes sense. |
| 10:30 |
|
RoganH joined #evergreen |
| 10:32 |
dbwells |
In my mind, void == "this fine should never have been assessed". The goal of a lot of this work has been to preserve that concept, I think. It wouldn't be hard to surface "adjustment" in the Payment Type dropdown, but it might further stir up some already pretty muddy waters. We'd probably want to think long and hard before doing that. |
| 10:33 |
kmlussier |
dbwells: Yeah, I was just thinking it might be an easier way to partially adjust a bill if you think the button in full details might be problematic. |
| 10:35 |
kmlussier |
I just worry that as soon as we implement it and a library toggles the "prohibit negative balance" setting and takes away the void permission, the first thing we'll here is complaints from staff that they can no longer partially void fines. |
| 10:35 |
kmlussier |
It sounds like it might be an issue for mmorgan's libraries since they've gotten in the habit of using forgive anyways, but it's a large community. |
| 10:36 |
kmlussier |
Sorry, I meant to say it might *not* be an issue for mmorgan's libraries. |
| 10:37 |
dbwells |
kmlussier: To be clear, I was actually thinking the same as you about offering adjustment as a payment option :) It's not a bad idea, just still thinking, that's all. |
| 10:39 |
kmlussier |
dbwells: Ok, understood. :) |
| 10:39 |
mmorgan |
Our staff members want to choose whatever is easiest to get the money off the patron's record so they can proceed with serving them, so as kmlussier says, losing the ability to partially void is probably not an issue for the day to day activities at the circ desk. |
| 10:41 |
mmorgan |
However, as a goal, it would be great to be able to rely on money reports from Evergreen. I like the idea of adjustment as a payment option, since it may get more amounts out of the cash category that aren't actually cash. |
| 10:45 |
mmorgan |
and also to be clear, I do agree with dbwells in that void == "this fine should never have been assessed" and that concept should be preserved. |
| 10:49 |
miker |
for history's sake, void was (is) indeed intended to mean "this (should) never (have) happened (but we're not going to throw away data)". ISTM that with dbwells' warning, staff are now well-informed and can look at the state of the transaction to see if voiding a particular billing line item is the correct action ... but, I don't stand at a circ desk :) |
| 10:52 |
kmlussier |
Yeah, in the case of our consortia, I think we'll just remove that void permission from our staff accounts just to make sure there's no room for error. But I agree that the warning helps, especially since you'll now have to click through 3 separate alerts to make that void happen. |
| 10:53 |
dbwells |
kmlussier: Are you still not seeing the warning, or did you get it to work? |
| 10:54 |
kmlussier |
dbwells: I got it to work, thanks! |
| 10:54 |
kmlussier |
dbwells++ |
| 10:54 |
* jeff |
dislikes the idea of voiding "already-paid" billing line items |
| 10:55 |
jeff |
(but hasn't been able to mine enough tuits to have a useful contribution to the conversation at hand) |
| 11:01 |
jeff |
Though I should probably at least note that my dislike statement above is at least somewhat unclear / ambiguous. |
| 11:02 |
kmlussier |
jeff: Well, the voiding behavior doesn't change at all from what we currently do. Which is why I'm looking at ways to make sure libraries can keep their staff away from it while also not losing the ability to do things that they currently can do. |
| 11:06 |
dbwells |
kmlussier: Dyrcona: I probably won't have time to work on this more today. I think the current branch is highly functional and seems to be not breaking, so I'd like to see it pushed sooner rather than later. (This is not a statement about overall release-readiness, which I leave entirely up to Dyrcona.) Thanks for testing! |
| 11:07 |
|
RoganH joined #evergreen |
| 11:10 |
bshum |
miker: https://bugs.launchpad.net/evergreen/+bug/1483857 got marked fix committed, but I don't see a corresponding commit to master or a milestone assigned to the bug. |
| 11:10 |
pinesol_green |
Launchpad bug 1483857 in Evergreen "Web based staff client in house use barcode box clear" (affected: 2, heat: 10) [Undecided,Fix committed] |
| 11:11 |
bshum |
miker: Is that getting put into some working branch on your end of things? If so, perhaps the more appropriate status is "confirmed" with an assignment to you till it's actually put into master and assigned an actual release milestone for 2.9.x as a bug fix, or 2.next as a new change? |
| 11:11 |
miker |
bshum: it's committed to the fix branch, sorry. I did that to avoid RMs from having to find all the touched bugs later -- the fixes will flow into master sooner rather than later (I hope!) |
| 11:12 |
miker |
webstaff stuff doesn't get a milestone -- it just goes into master... |
| 11:13 |
miker |
the fixes branch is at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/sprint2-fixes |
| 11:13 |
bshum |
miker: I'm not sure that's entirely true actually, I mean yes it goes into master, but we have been trying to keep things applied to specific milestones anyways. At least as far as I knew. |
| 11:14 |
miker |
per sprint, the whole lot goes in in one go, yes. but fixes should flow into master asap, IMHO |
| 11:14 |
miker |
fixes to past sprints, that is |
| 11:15 |
miker |
if the community at large disagrees, I can go back and change the bugs |
| 11:17 |
bshum |
miker: I'm confused, regardless of where it's applied and when, there are still milestones that apply to anything that goes into master. Either it's the next upcoming alpha/beta/rc for a given new series, or it'll be the next major series milestone 2.next (which then becomes a specific number during the next cycle). |
| 11:18 |
bshum |
At the point that a specific series is "released" that'll be when the bug transitions from fix committed (in master) to fix released for a series. |
| 11:19 |
miker |
seems like make-work to me, since the webstaff stuff is not intended for actual use ATM, but I'll change the bugs if you feel strongly. my intent was to save on bug wrangling effort in LP, but if that's not a concern, that's fine with me |
| 11:19 |
bshum |
It might be minor, but having untracked LP bugs with no milestone is what usually leads to bugs staying in LP open forever without end, cause they don't have a tracking point when they actually become "released" |
| 11:20 |
miker |
that assumes that the fix branch won't have commits pushed to master ... someone is /constantly/ looking at that branch, though, so there's no risk that it won't get pushed for lack of attention |
| 11:21 |
miker |
LP being an imperfect tool, I tried to make the best decision without adding overhead to others' plates ... I'll just add that work back, though |
| 11:23 |
bshum |
miker: I'd appreciate it, for consistency's sake anyways. Thanks! |
| 11:23 |
miker |
bshum: sure. I'll try to remember to remind you to wrangle bugs like that, I guess |
| 11:25 |
miker |
I'm going to mark them in-progress ... seems match the state most closely. I hope whoever looks at them next reads all the comments. |
| 11:26 |
gmcharlt |
Dyrcona: would there be any possibility of your branching rel_2_9 now? |
| 11:27 |
kmlussier |
This might be a dumb question, but is there any reason those fixes can't be pushed directly to master rather than being pushed to the current web client branch? |
| 11:27 |
|
Christineb joined #evergreen |
| 11:27 |
gmcharlt |
kmlussier: indeed; that's the motivation of the question I posed to Dyrcona just now |
| 11:27 |
bshum |
kmlussier: Two signoffs and go, right? :) |
| 11:27 |
jeff |
kmlussier: mostly because we late-cut releases, as opposed to releases being a given point in time. |
| 11:28 |
jeff |
kmlussier: it's my understanding that currently it's frowned upon to push to master around/near release time without coordination with the RM. i could be wrong. |
| 11:28 |
bshum |
jeff: Huh? |
| 11:29 |
bshum |
Oh hmm.... |
| 11:29 |
kmlussier |
jeff: Ah, ok. But if it were another say, say next week, miker could just push those changes to master since he's reviewed and tested them, couldn't he? |
| 11:29 |
kmlussier |
Apologies for garbling that sentence, but y'all know what I mean. |
| 11:29 |
miker |
also, they haven't been pushed to webby for broader testing yet |
| 11:34 |
miker |
if 2.9 is cut later than today (but don't delay for those minor fixes alone, please!) then broader testing will be applied, and I will push them to master for good and all |
| 11:42 |
kmlussier |
dbwells / Dyrcona: I've been waiting to hear back from one other person to get a sense of how often the void option in Full Details is used. And it may be too late to give feedback if Dyrcona has already started release cutting. |
| 11:43 |
kmlussier |
dbwells / Dyrcona: My personal opinion right now is, to truly prohibit negative balances we we had hope to do, we will need to remove that void permission from our users. And when we remove that void permission, they will lose the ability to do something they previously could do. It's a regression. |
| 11:44 |
kmlussier |
My preference is that they don't lose any functionality when the .0 release is out. But I leave it in the hands of our fearless RM to make the final decision. |
| 11:44 |
bshum |
I think Dyrcona said earlier that he's in a staff meeting. So maybe we've still got a little more time. |
| 11:44 |
bshum |
:) |
| 11:44 |
* kmlussier |
nods. |
| 11:47 |
kmlussier |
I know it seems overly complicated how we are handling each of these options in the staff client, but I think that's partially due to the fact that we now have two different ways - adjust and void - of handling bills that should be removed from the record. |
| 11:48 |
miker |
kmlussier: would you want the void to fail outright if it would cause a negative balance, if the "don't allow that" setting is on? |
| 11:48 |
mmorgan |
money is complicated :-( |
| 11:50 |
kmlussier |
miker: My original suggestion was that using the manual void option would handle it appropriately, i.e. void if the site allows negative balances and adjust to zero if they don't allow it. And I'm okay with the compromise we came up with. |
| 11:51 |
kmlussier |
miker: I just would like to see some way for staff who do not have the void permission to be able to adjust just a few days of an overdue fine the way they can currently void those few days through Full Details. |
| 11:52 |
kmlussier |
If an account_adjustment option is available in the payment dropdown, that works for me. In fact, it's even better because it's easier to do. An adjust option in Full Details is fine with me too. |
| 11:52 |
miker |
TBH, I'm pretty strongly against doing something that the user didn't ask for ... especially since void and adjust have different meanings (void being "this billing line item should never happened" and adjust meaning "staff wants this whole transaction to be $0") |
| 11:53 |
miker |
the work at different granularity levels. I realize that may be a non-trivial training issue, though |
| 11:53 |
kmlussier |
Yes, and I'm stongly against creating a situation where negative balances can be created when a site has explicitly said "we want to prohibit them." But we handled that through removing the void option when users don't have permission to use it. |
| 11:53 |
kmlussier |
It's just this one last small piece. |
| 11:53 |
miker |
right, no, I totally understand you point about avoiding negative balances |
| 11:53 |
miker |
I'm on board |
| 11:54 |
kmlussier |
miker: I think everyone understand my point about avoiding negative balances by this time. ;) |
| 11:54 |
miker |
heh :) |
| 11:54 |
gmcharlt |
... because one day somebody will try to take the square root – and then we'll be done for! |
| 11:54 |
gmcharlt |
;) |
| 11:54 |
|
yboston joined #evergreen |
| 11:55 |
miker |
i |
| 11:55 |
miker |
[aye] |
| 11:56 |
gmcharlt |
zing! # second day in a row that I've happened to walk into "eye" puns that are all miker's fault! |
| 11:56 |
miker |
gmcharlt: better than a sharp stick in the aiiiiiiiii! |
| 11:56 |
miker |
[credit to gmcharlt for "aiiiiiii"] |
| 12:32 |
Bmagic |
I have a hold policy issue. We want to prevent holds on a certain circ modifier at a certain system by anyone accept the staff users. It's looking like the policy is working. We found that other hold policies are beating this one because other systems have policies that match |
| 12:33 |
Bmagic |
we set the policy at the consortium level but the more specific policies for other branches are getting matched first because they are more specific I guess |
| 12:33 |
* dbs |
mused this morning about a 2.10 feature to remove all of the RDFa from the opac templates and replace it with one inline JSON-LD element in the head |
| 12:33 |
bshum |
accept/except, sure |
| 12:33 |
miker |
Bmagic: can you make either the group or org unit field "closer" to the real ones on the policy you want to win? |
| 12:34 |
bshum |
dbs: That sounds... like a large task? |
| 12:34 |
bshum |
But hey, you've got six months to get there! |
| 12:35 |
bshum |
(well, 4-5 months actually, given cutoffs, etc.) |
| 12:36 |
Bmagic |
miker: I think that means I need to make a rule for every other branch in the consortium. > 40 branches. That stinks |
| 12:36 |
bshum |
Bmagic: Use SQL to copy it out. |
| 12:36 |
bshum |
But yes, it sucks. |
| 12:36 |
miker |
Bmagic: could you make circ_mod most important? |
| 12:36 |
bshum |
When you get up over 1k rules, let me know. |
| 12:37 |
Bmagic |
yeah, I like the idea of weighting the circ mod |
| 12:37 |
miker |
if you don't use circ_mod much in other rules, that might do it |
| 12:38 |
dbs |
bshum: should make things a lot easier for people who want to tailor templates without worrying about breaking the embedded metadata, so would be worth it I think |
| 12:39 |
Bmagic |
miker: right now, we have about a 50/50 split of rules that mention circ mod and those that dont |
| 12:40 |
miker |
Bmagic: if the rule in question is the only one using that particular circ_mod, it still might be OK |
| 12:40 |
miker |
testing would tell, obv |
| 12:41 |
Bmagic |
right on |
| 12:42 |
Bmagic |
it would be neat if there was a mechanizm for "pickup library is NOT x" |
| 12:43 |
Dyrcona |
miker gmcharlt: I'm in favor of web staff client fixes being treated like normal bugs and have considered saying it would be OK to backport them to rel_2_9 once it is branched. |
| 12:43 |
Dyrcona |
If you think that would be too much work, than that's OK and they can just got to master. |
| 12:44 |
Dyrcona |
s/than/then/ |
| 12:46 |
|
bmills joined #evergreen |
| 12:46 |
miker |
Dyrcona: to date, we've treated all webstaff code as master-only, intentionally ... |
| 12:46 |
miker |
including all bug fixes |
| 12:47 |
miker |
we didn't backport any bugs fixed for sprint 1 to 2.7 or 2.8, IOW |
| 12:47 |
Dyrcona |
miker: Yep, I understand that. I'm offering to make it different for 2.9 so the preview can be kept up to date. |
| 12:48 |
Dyrcona |
Like I said, though if the consensus is that it is not worth it, then that's fine with me, too. |
| 12:50 |
miker |
well, for the 3 this morning, I don't have any problem pushing them to 2.9. it's when code starts to drift (causing merge conflicts) and dependent features added, and an expectation has been set that they'll be backported (and there will be plenty of bugs fixed, I'm sure -- it's software), that the effort starts becoming a problem |
| 12:52 |
Dyrcona |
miker: I'm fine with that, push the 3 this morning. |
| 12:53 |
miker |
Dyrcona: kk, thanks. do you have a timeframe for branching? |
| 12:53 |
miker |
(regardless, I'll make sure the fixes branch gets pushed to rel_2_9) |
| 12:53 |
|
bmills joined #evergreen |
| 12:53 |
Dyrcona |
Yeah, I was about to say I'd push dbwells' branch that we were discussing today and then branhc. |
| 12:54 |
Dyrcona |
miker: Are you in a position to push them into master, right now? I can wait for you or if you want, I'll go ahead. |
| 12:55 |
miker |
I can be in a position soon ... in, say, 15min |
| 12:55 |
Dyrcona |
OK. I can wait. |
| 12:55 |
Dyrcona |
I'd prefer to have as much as possible in master before branching. |
| 12:56 |
miker |
Dyrcona: and, to be clear, I'd like to push the top 6 commits of http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/gmcharlt/sprint2-fixes ... the first 4 are from this morning, the next 2 are fixes that are widely tested |
| 12:57 |
Dyrcona |
OK. That works for me. |
| 12:58 |
miker |
where "widely" means "by more than the author, and don't break webby" |
| 12:59 |
Dyrcona |
:) |
| 12:59 |
Dyrcona |
Should I use Chrome when testing the web staff client? |
| 12:59 |
Dyrcona |
Or, do you want it to work with Firefox, too? |
| 13:00 |
miker |
both ideally, but chrome is moar better in general |
| 13:00 |
Dyrcona |
Thanks! That is what I thought. |
| 13:06 |
Bmagic |
Does anyone have an action trigger definition setup to fire no matter what? I want to setup a trigger to run on a hook with something like "true always" and it will just run when the cron runs with it's granularity. |
| 13:07 |
|
ericar joined #evergreen |
| 13:08 |
Bmagic |
The idea here is to send an email to patrons every 30 days with a total owed summary. It seems like it could be done with action trigger with a clever template |
| 13:08 |
bshum |
Bmagic: I have lots of granularities in our A/T. |
| 13:08 |
Bmagic |
What hook do you use? |
| 13:08 |
Bmagic |
null? |
| 13:09 |
bshum |
I was just saying I have lots of granularities. I think we always have a trigger for our actions. |
| 13:09 |
Dyrcona |
To follow up with what csharp reported yesterday while I was not in IRC, http://irc.evergreen-ils.org/evergreen/2015-09-15#i_203351 : |
| 13:10 |
Dyrcona |
I'll modify the upgrade script to do the inserts on the altered table outside of the main transaction |
| 13:10 |
Bmagic |
bshum: hmmm, in this case, I don't care about a hook. I want the hook to be basically when the cron runs. |
| 13:10 |
mmorgan |
Bmagic: A hook in a trigger is required. |
| 13:11 |
Bmagic |
mmorgan: and there isn't a hook that means "true" or "always" ? |
| 13:11 |
mmorgan |
The hook tells the trigger what to grab to react on. |
| 13:11 |
mmorgan |
Like checkout.due looks at transactions and when they're due. |
| 13:12 |
Bmagic |
I came to the same conclusion but I wanted to bounce it off of you |
| 13:12 |
Bmagic |
looks like it's going to have to be a custom script |
| 13:12 |
bshum |
berick: Dyrcona: Hmm I was thinking, should berick and I do our releases first, so that you can build the path from 2.8.4-2.9.0? Or should we work independently? |
| 13:13 |
* bshum |
has decided 2.7 is the least important |
| 13:14 |
mmorgan |
Bmagic: It would be useful to have some hooks that start by looking at the usr, rather than starting from checkouts. |
| 13:14 |
Bmagic |
like "card about to expire" |
| 13:14 |
Dyrcona |
berick bshum: I would like to base the 2.9.0 upgrade script on 2.8.4 |
| 13:14 |
mmorgan |
Yes, that's what'a part of started me thinking along this line. |
| 13:15 |
bshum |
mmorgan: Card about to expire is a new A/T for 2.9 I thought? |
| 13:15 |
bshum |
Or did we not merge that |
| 13:15 |
* bshum |
checks back |
| 13:15 |
Dyrcona |
I think it went in. |
| 13:15 |
mmorgan |
bshum: It's in 2.8 |
| 13:16 |
Bmagic |
so, instead of developing a custom script, you suggest adding the hook and relative code the EG codebase? Perhaps make a LP request and see what everyone has to say about it? |
| 13:17 |
bshum |
mmorgan: Well, https://bugs.launchpad.net/evergreen/+bug/1124498 seems to indicate that it was in 2.9, but... hmm. |
| 13:17 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 6, heat: 40) [Wishlist,Fix committed] |
| 13:17 |
bshum |
Either way, something exists |
| 13:18 |
mmorgan |
bshum: Sorry! I stand corrected. You're right, 2.9. |
| 13:18 |
gmcharlt |
Bmagic: yes, I'd encourage that; yours is probably not the only library interested in being able to have some sort of periodic statement of account (for naughty patrons) be readily supportable |
| 13:19 |
mmorgan |
Bmagic: Yes, what gmcharlt said. I think a Launchpad bug is a good idea. |
| 13:19 |
Bmagic |
mmorgan: "card is about to expire" is in 2.8+ ? I must have missed an upgrade script, I don't see it in my available hooks |
| 13:19 |
mmorgan |
We have a need to send statements to students of what they have checked out at the end of a semester. I've done it using the checkout.due hook, but it really seems backwards. |
| 13:19 |
mmorgan |
Bmagic: No, sorry, it's 2.9. |
| 13:20 |
Bmagic |
mmorgan: oh good, that's a relief |
| 13:20 |
* mmorgan |
was confused because we added the code locally prior to it being released. |
| 13:22 |
mmorgan |
Bmagic: FYI, lp 1124498 |
| 13:22 |
pinesol_green |
Launchpad bug 1124498 in Evergreen "Wishlist: Patron notification via email when card is about to expire" (affected: 6, heat: 40) [Wishlist,Fix committed] https://launchpad.net/bugs/1124498 |
| 13:22 |
Bmagic |
I was just reviewing that |
| 13:24 |
miker |
Dyrcona: done! |
| 13:25 |
* mmorgan |
does not quite understand all the bits and pieces related to action trigger hooks, but it sure seems like creating hooks that start with the usr should be possible. |
| 13:25 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 13:25 |
pinesol_green |
[evergreen|Mike Rylander] webstaff: Provide hooks for on-save callback for marc edit to, for instance, refresh the record summary UI - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d4729ca> |
| 13:25 |
Dyrcona |
miker++ |
| 13:25 |
miker |
I'm going to restart webby ... head's up, webby testers |
| 13:25 |
pinesol_green |
[evergreen|Stephen Moss] webstaff: LP#1483857 Add code to clear barcodes from in-house use - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7d05cee> |
| 13:25 |
pinesol_green |
[evergreen|Victoria Lewis] webstaff: LP#1436980 Total Circulations in Patron Bills - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6e97a56> |
| 13:25 |
pinesol_green |
[evergreen|Mike Rylander] webstaff: LP#1436980: Default copy circ count to 0 instead of undefined - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=668e875> |
| 13:25 |
pinesol_green |
[evergreen|Victoria Lewis] webstaff: LP#1437110 add Manual Floating Active - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=575db96> |
| 13:27 |
|
jihpringle joined #evergreen |
| 13:28 |
Dyrcona |
grabbing 0944 |
| 13:29 |
berick |
bshum: so you and I need to cut soon, right? |
| 13:29 |
bshum |
berick: I'm about to get started, it's going to be a small release. But I guess that authority fix will be good. |
| 13:31 |
berick |
bshum: ok, cool. i'll get started over here, then |
| 13:33 |
pinesol_green |
[evergreen|Dan Wells] LP#1494544 Add ADJUST_BILLS permission to seed data - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=428214b> |
| 13:33 |
pinesol_green |
[evergreen|Dan Wells] LP#1494544 Complete XUL UI for adjustment vs. void options - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2128664> |
| 13:33 |
pinesol_green |
[evergreen|Jason Stephenson] LP#1494544 Stamping Upgrade Script - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b0f055> |
| 13:36 |
Dyrcona |
I just pushed rel_2_9 to the main repo server. |
| 13:43 |
jeff |
Dyrcona++ |
| 13:43 |
mmorgan |
Dyrcona++ |
| 13:44 |
bshum |
Dyrcona++ |
| 13:44 |
Bmagic |
Dyrcona++ |
| 13:44 |
Bmagic |
hanabi++ |
| 13:48 |
Dyrcona |
heh |
| 13:53 |
bshum |
Uploading 2.7.8 to lupin next. |
| 13:53 |
berick |
kmlussier: are you doing are release notes again? |
| 13:53 |
berick |
uh, s/are/our/ |
| 13:54 |
kmlussier |
berick: Sorry, just got back. I was working on the 2.9 release notes. Forgot about the other releases. :) |
| 13:54 |
kmlussier |
But I can do it. I don't think there has been too much activity for the point releases. |
| 13:54 |
berick |
fwiw, it looks like 2.9 will be cut after 2.8.4 and 2.7.whatever |
| 13:54 |
berick |
kmlussier: that would be most excellent |
| 13:54 |
berick |
kmlussier++ |
| 13:55 |
bshum |
2.7.8, but we don't do point release notes for 2.7. Whew. |
| 13:55 |
berick |
ah, ok, forgot about that |
| 13:58 |
kmlussier |
After the 2.8.3 release, I was going to write up some notes on the point release process to see if we could make it better. A month sure does go by very quickly, doesn't it? |
| 13:59 |
berick |
like sands through the hourglass |
| 14:08 |
Dyrcona |
;) |
| 14:09 |
|
wjr joined #evergreen |
| 14:13 |
bshum |
Does anyone remember offhand what a hold status of -1 means? I know it's indicative of some sort of error failure, I just don't recall the exact nature of it. |
| 14:14 |
Dyrcona |
The hold is in an invalid state. |
| 14:14 |
Bmagic |
bshum: I had this question a few weeks ago...... now I forget what the answer was, lol. Apparently it was important. Let me look back |
| 14:14 |
jeff |
only displayed in the staff client, it's "something isn't what i expect" |
| 14:15 |
jeff |
it's set to "-1" at display time as a fall-through after several conditional tests. |
| 14:15 |
Dyrcona |
Typically happens when some field has or is missing a value that it shouldn't because of other values in the hold request. |
| 14:15 |
berick |
usually a mismatch between copy status and hold disposition |
| 14:22 |
bshum |
Okay, 2.7.8 is all set. But I'll wait to update the downloads page for now. |
| 14:23 |
bshum |
And thanks guys, Dyrcona++ berick++ jeff++ |
| 14:23 |
bshum |
That was the problem for sure, copy was "available" but it was in-transit and captured for hold for someone |
| 14:23 |
bshum |
Super weird looking. |
| 14:23 |
bshum |
Maybe some failed, half aborted hold transit or something |
| 14:25 |
Dyrcona |
Aborting a transit will do it. |
| 14:30 |
kmlussier |
berick: the release notes are ready. Is it okay to push them to master now or should I wait until you're done cutting? If you haven't finished cutting yet. |
| 14:32 |
kmlussier |
I also have a question. yboston provided a nice release notes entry for one of the fixes and put it in the release notes next directory. I included it in the 2.8.4. bug fix release notes, but I'm guessing they'll be included in the 2.9 release notes too the next time Dyrcona runs the script to create release notes. |
| 14:32 |
kmlussier |
Should I remove that file from the release notes next folder so that it doesn't appear in both sets of release notes? |
| 14:32 |
kmlussier |
I had the same question last month with a fix from DPearl that made it into both the point release notes and in the 2.9 preview notes. |
| 14:33 |
berick |
kmlussier: go ahead and push to master, please |
| 14:35 |
pinesol_green |
[evergreen|Kathy Lussier] 2.8.4 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9d13c31> |
| 14:35 |
Dyrcona |
kmlussier: I'd say you can remove the next entry if it will show up in the 2.8.4 release notes. |
| 14:35 |
berick |
kmlussier++ |
| 14:35 |
Dyrcona |
kmlussier++ |
| 14:36 |
* berick |
will back-port to 2.8 |
| 14:38 |
kmlussier |
berick: Ha! I missed that. I just tried backporting it. |
| 14:39 |
kmlussier |
Is there a 2.9 to backport it too, or does that happen after Dyrcona is done with his release? |
| 14:39 |
berick |
actually, there is |
| 14:39 |
berick |
Dyrcona just created the new barnch |
| 14:39 |
berick |
heh, barnch |
| 14:39 |
Dyrcona |
branhc |
| 14:39 |
Dyrcona |
;) |
| 14:39 |
kmlussier |
Dyrcona: Is there any problem with me pushing that to 2.9 now? |
| 14:40 |
kmlussier |
The whole release cutting process is a mystery to me. |
| 14:40 |
Dyrcona |
no problem. I'm waiting. |
| 14:42 |
kmlussier |
Sorry, it always takes me a while to backport because it's not something I do very often. |
| 14:42 |
Dyrcona |
no problem |
| 14:43 |
Dyrcona |
At least you don't have to worry about code drift. |
| 14:43 |
kmlussier |
Dyrcona: I do have some changes I need to make to the 2.9 release notes. I think I'm done with the neg balance additions from today's branch, but I also need to add acknoledgements. I'll remove those bug fix release note entries at that time. |
| 14:43 |
Dyrcona |
OK. Works for me. |
| 14:44 |
* kmlussier |
will first grab the tea that is probably getting cold by now. :) |
| 14:51 |
jeffdavis |
dbwells: I was finally able to apply your fix for bug 1484989 on a test server. After applying the commit, lost transactions are being closed when the item is checked in and the fine balance hits zero, which is what we want. |
| 14:51 |
pinesol_green |
Launchpad bug 1484989 in Evergreen 2.8 "Fines are not calculating until after circulation is closed" (affected: 1, heat: 6) [Medium,Fix committed] https://launchpad.net/bugs/1484989 |
| 14:51 |
jeffdavis |
dbwells: However, that behavior still does not seem to be governed by the circ.lost.xact_open_on_zero setting, which is what we expected (i.e. the circs are closed even when that setting is true). |
| 14:52 |
jeffdavis |
I haven't replicated our original problem on a stock 2.8 install though. |
| 14:57 |
dbwells |
jeffdavis: Thanks for reporting back. As I understand it, circ.lost.xact_open_on_zero does not apply to lost circs which are checked in, but only to ones which remain lost, but are then paid off. Without the setting on, they stay open indefinitely; with the setting on, they are considered (and marked) "closed". |
| 14:57 |
berick |
Dyrcona: in case you're waiting on me, i'm building now. should be uploading soon |
| 14:58 |
Dyrcona |
berick: Thanks, I was mainly waiting on the branch to show up. |
| 14:58 |
berick |
gotcha, will be pushed soon |
| 15:06 |
berick |
Dyrcona: pushed |
| 15:06 |
Dyrcona |
berick++ |
| 15:07 |
|
ericar joined #evergreen |
| 15:18 |
berick |
2.8.4 files uploaded |
| 15:20 |
* berick |
ports 2.8.4 sql upgrade to various branches |
| 15:23 |
|
ericar joined #evergreen |
| 15:25 |
pinesol_green |
[evergreen|Bill Erickson] Porting 2.8.3->2.8.4 SQL upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6bbc363> |
| 15:27 |
kmlussier |
I missed adding Bill Ott to the 2.8 acknowledgements in the last point release. I'll need to add him. Also, it looks like I did something wrong with the top header for the 2.8.4 point release notes. |
| 15:29 |
kmlussier |
Actually, it looks like I missed a couple of people in the acknowldgements for the last point release. |
| 15:44 |
|
jlitrell joined #evergreen |
| 15:57 |
kmlussier |
Dyrcona: OK, pushing most recent release notes changes to master and 2.9. |
| 15:58 |
remingtron |
kmlussier: did we get the Authority release note typo fixed? |
| 15:58 |
kmlussier |
remingtron: Yup. Got it |
| 15:58 |
remingtron |
kmlussier++ |
| 15:59 |
kmlussier |
Ack! Git don't fail me now! |
| 16:02 |
Bmagic |
When "claimed never checked out" is applied to a "LOST" circulation, the claims_never_checked_out_count does not get increased. Is that by design? |
| 16:02 |
bshum |
Hmm |
| 16:02 |
bshum |
Probably not. |
| 16:03 |
Dyrcona |
Bmagic: Did you refresh the patron? |
| 16:03 |
Bmagic |
yep |
| 16:03 |
pinesol_green |
[evergreen|Kathy Lussier] Additions to the 2.9 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=1c06390> |
| 16:03 |
Bmagic |
I reloaded the patron in a new tab just to make sure |
| 16:04 |
kmlussier |
Release note changes are pushed. One change I made to the acknowlegements is that we are thanking people for contributions to tests as well as code and doc patches. |
| 16:04 |
Bmagic |
I tested it on a non-lost circ, and it did increase the count |
| 16:04 |
Dyrcona |
kmlussier++ |
| 16:04 |
Bmagic |
kmlussier++ |
| 16:04 |
mmorgan |
kmlussier++ |
| 16:04 |
bshum |
kmlussier++ |
| 16:04 |
kmlussier |
berick: Sorry, I have more changes I need to make to the 2.8 release notes that I discovered while working on 2.9. I'll have those merged in a bit. |
| 16:05 |
berick |
kmlussier: no worries, thanks for the heads up |
| 16:10 |
mmorgan |
Bmagic: Just saw the same thing on our training server. Had to override the COPY_STATUS_LOST to make it claimed never checked out. |
| 16:10 |
Bmagic |
I had to do the same. But the count was not increased |
| 16:10 |
mmorgan |
Yes, same here. |
| 16:10 |
Bmagic |
I just filed a bug |
| 16:11 |
Bmagic |
https://bugs.launchpad.net/evergreen/+bug/1496556 |
| 16:11 |
pinesol_green |
Launchpad bug 1496556 in Evergreen "Claimed never checked out count not increased when applied to LOST circulation" (affected: 1, heat: 6) [Undecided,New] |
| 16:35 |
pinesol_green |
[evergreen|Kathy Lussier] Docs: 2.8 Acknowledgements addition - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fa21a42> |
| 16:42 |
kmlussier |
Yup, ok. Where did the day go? |
| 16:42 |
bshum |
It's Wednesday right? |
| 16:42 |
bshum |
Right. |
| 16:42 |
mmorgan |
Chronological evaporation. |
| 16:43 |
mmorgan |
...or something. |
| 16:43 |
kmlussier |
As usual, when working on acknowledgements, it was great to see all the different types of organizations big and small that went into making this Evergreen release. A big y'all++ |
| 16:43 |
kmlussier |
And an even bigger Dyrcona++ |
| 17:08 |
|
mmorgan left #evergreen |
| 17:19 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:32 |
pinesol_green |
[evergreen|Remington Steed] Docs 2.9: Update and add detail for Holdings Import profile - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=584dfb9> |
| 17:46 |
pinesol_green |
[evergreen|Jason Stephenson] Porting 2.8.4->2.9.0 SQL upgrade - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=69bb3ce> |
| 17:48 |
pinesol_green |
[evergreen|Jason Stephenson] Forward port 2.9.0 translations. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d40524> |
| 18:13 |
Dyrcona |
Well, I hope that's that. |
| 18:16 |
pinesol_green |
[evergreen|Jason Stephenson] 2.9 Release notes creation and cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4d10f91> |
| 18:26 |
kmlussier |
Dyrcona++ |
| 19:02 |
|
Dyrcona joined #evergreen |
| 19:49 |
Dyrcona |
gmcharlt++ # for behind the scenes help with the release |
| 22:07 |
miker |
Dyrcona: he's cool lke that |
| 22:50 |
bshum |
berick: I updated the downloads page so that 2.8.4 and 2.7.8 are also shown to be the most current releases for those series. |
| 22:53 |
kmlussier |
Bah! I forgot that I had written the release notes entry for my feature in adoc and, since the script was never updated, that's the one entry missing from the release notes. |
| 22:54 |
kmlussier |
Can I berate the release notes wrangler for sloppy work? ;) |
| 22:56 |
bshum |
Heh |
| 22:56 |
bshum |
Easy enough to fix |
| 22:56 |
bshum |
In theory |
| 22:57 |
bshum |
kmlussier: I also wonder if we should set the stock _acknowledgements in master back to TODO, once we pass the actual release notes compilation stage. |
| 22:58 |
kmlussier |
Yes. Do we usually do the acknowledgements after the release notes file is created? |
| 22:59 |
* bshum |
doesn't recall |
| 22:59 |
kmlussier |
It looks like my little feature also didn't make it to the DIG to-do page because it wasn't in the release notes. We might need to update some screenshots. |
| 22:59 |
bshum |
But I think when I did 2.7, I just edited the main body file rather than tinker with the templates |
| 23:00 |
bshum |
kmlussier: It's the one in OPAC right? |
| 23:01 |
kmlussier |
bshum: The main body file being the RELEASE_NOTES_2_7.text file? |
| 23:01 |
kmlussier |
bshum: Yup. OPAC. |
| 23:01 |
bshum |
kmlussier: Right, I think by the time I realized that we needed to update the acknowledgements block, the _2_7.txt was already created |
| 23:01 |
bshum |
So we just directly changed that. |
| 23:01 |
bshum |
But there's lots of ways to make it work I guess. |
| 23:02 |
kmlussier |
Yeah. I didn't have that file yet to change. It's nicer when the acknowledgements are out there as soon as .0 is released. |
| 23:02 |
bshum |
Right. |
| 23:06 |
bshum |
I updated the notes on lupin to have the missed note |
| 23:06 |
bshum |
I'll push an update for git next. |
| 23:06 |
kmlussier |
bshum++ |
| 23:10 |
* bshum |
supposes he should backport that change to rel_2_9 too. |
| 23:13 |
pinesol_green |
[evergreen|Ben Shum] Docs: Add one missing entry to RELEASE_NOTES_2_9.txt - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d792969> |
| 23:13 |
bshum |
Hmm I just realized that rel_2_7 is about to be 12 months past initial 2.7.0 release (2 more days) |
| 23:14 |
bshum |
I'm in the "security fix only" stage |
| 23:14 |
bshum |
But I guess I'll take time to announce the next maintenance release as the "last one" barring any security fix needs. |
| 23:14 |
bshum |
Well, maybe. |
| 23:15 |
kmlussier |
bshum++ |
| 23:16 |
bshum |
"And now his watch is ended." (almost, almost....) |
| 23:27 |
jeff |
what's the bar for "commissioned developments"? |
| 23:27 |
jeff |
oh, and is there a better method for me to help fix this typo than just mentioning it here? "individuals who contributed code, documentations patche and tests to this release" :-) |
| 23:27 |
jeff |
(first question is just one of curiosity, not thinking that there was an omission or anything) |
| 23:28 |
kmlussier |
jeff: Organizations that contracted for development work that made it into the release. |
| 23:29 |
kmlussier |
In the case of this release, we have organizations that paid for development through Equinox, Sigio, and Catalyst. |
| 23:30 |
bshum |
I think it covers the base of funding partners who don't get their names/organizations represented with the actual authoring/testing/signoff/committing. |
| 23:30 |
kmlussier |
Basically, it's a way to give credit to organizations that may not have the development staff to contribute code, but made one of the features happen through funding. |
| 23:33 |
kmlussier |
bshum: Did you already update the release notes with my feature? If not, can you fix my typo? |
| 23:33 |
bshum |
kmlussier: Already updated, but we can do another one... |
| 23:34 |
bshum |
kmlussier: How should that line read, "patches"? |
| 23:35 |
kmlussier |
"documentation patches" |
| 23:35 |
bshum |
Got it |
| 23:35 |
bshum |
Live file patched |
| 23:35 |
kmlussier |
bshum++ |
| 23:35 |
bshum |
Going to make a git commit with the typo fix now |
| 23:46 |
bshum |
I should have added an oxford comma while I was fixing that. It's going to annoy me now... |
| 23:47 |
pinesol_green |
[evergreen|Ben Shum] Docs: Fix typo in acknowledgements for RELEASE_NOTES_2_9.txt - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=409cbf8> |
| 23:47 |
jeff |
heh |
| 23:53 |
kmlussier |
bshum: Don't succumb to over-comma use! |
