| Time |
Nick |
Message |
| 00:16 |
|
pinesol_green` joined #evergreen |
| 07:09 |
|
Callender joined #evergreen |
| 07:38 |
|
rjackson_isl joined #evergreen |
| 07:54 |
|
Shae joined #evergreen |
| 08:02 |
|
jboyer-isl joined #evergreen |
| 08:09 |
|
ericar joined #evergreen |
| 08:24 |
|
mrpeters joined #evergreen |
| 08:38 |
|
sarabee joined #evergreen |
| 08:57 |
kmlussier |
Good morning #evergreen |
| 08:57 |
kmlussier |
@coffee [someone] |
| 08:57 |
* pinesol_green` |
brews and pours a cup of Kenya Mamuto, and sends it sliding down the bar to rashma |
| 08:57 |
kmlussier |
@tea [someone] |
| 08:57 |
* pinesol_green` |
brews and pours a pot of Honey Black Tea, and sends it sliding down the bar to book`_ (http://ratetea.com/tea/health-and-tea/honey-black-tea/7529/) |
| 09:03 |
|
Dyrcona joined #evergreen |
| 09:03 |
jeff_ |
morning, kmlussier! |
| 09:05 |
Dyrcona |
Good morning! |
| 09:06 |
* Dyrcona |
just wants to say that tunneling DB connections from PgAdmin over SSH is awesome. |
| 09:07 |
Dyrcona |
Or, maybe it isn't. |
| 09:08 |
Dyrcona |
Yeah, no. I'll go back to making the tunnels manually. PgAdmin's don't seem so reliable. |
| 09:10 |
|
maryj joined #evergreen |
| 09:14 |
|
jwoodard joined #evergreen |
| 09:16 |
|
sarabee joined #evergreen |
| 09:19 |
|
mmorgan joined #evergreen |
| 09:36 |
|
yboston joined #evergreen |
| 09:54 |
|
sarabee joined #evergreen |
| 10:07 |
kmlussier |
Dyrcona: For clarification, test writing day is today, not tomorrow. |
| 10:08 |
Dyrcona |
Well, now you tell me. |
| 10:08 |
kmlussier |
ldw sent his email last night. |
| 10:08 |
Dyrcona |
And, goodbye. I have a day of meetings. |
| 10:36 |
|
maryj joined #evergreen |
| 10:45 |
|
Dyrcona joined #evergreen |
| 10:46 |
dbs |
hrm, looks like pg_enable_utf8 is no longer a good idea in clark-kent.pl |
| 10:48 |
dbs |
per http://search.cpan.org/~turnstep/DBD-Pg/Pg.pm#pg_enable_utf8_(integer) "Use of the default is highly encouraged" (default is -1, we set it to 1). Removing it fixed our utf8 encoding output problems in HTML even though we're on DBD::Pg 2.19. |
| 10:49 |
dbs |
behaviour changed in DBD::Pg 3.0.0, but I suspect since we're using use open ':utf8' pragma we're getting extra levels of encoding that we don't really want |
| 10:51 |
* Dyrcona |
is likely to disappear in a minute or so. |
| 10:51 |
gmcharlt |
dbs: wheee! incompatible changes FTW! at least it was documented |
| 10:53 |
berick |
oh right... release cutting. |
| 10:53 |
* dbs |
ponders the work required to set up a suite of tests for the reporter |
| 10:54 |
dbs |
live tests I guess |
| 10:54 |
berick |
kmlussier: are you still our point person for release docs? |
| 10:54 |
kmlussier |
berick: Yup. I haven't done the legwork to find somebody to take my place yet. |
| 10:55 |
|
sandbergja joined #evergreen |
| 10:55 |
kmlussier |
I'm planning to get the point release notes done today, so that y'all aren't waiting on me tomorrow. :) |
| 10:56 |
berick |
kmlussier: awesome, thank. i'm just proud of myself for thinking about it slightly in advance. |
| 10:56 |
berick |
er, thanks |
| 10:56 |
berick |
let me know if I can assist |
| 10:56 |
kmlussier |
will do! |
| 10:59 |
* Dyrcona |
wonders how much of his data plan he'll use up today. |
| 10:59 |
dbs |
oh that's fun, fixing the HTML output ruins the Excel output |
| 10:59 |
dbs |
MADRE DIOS |
| 11:00 |
Dyrcona |
dbs: Of course it does. |
| 11:00 |
bshum |
"Can open.... worms everywhere...." |
| 11:01 |
Dyrcona |
bshum++ |
| 11:07 |
StomproJ |
Question for the core devs. I was working on combining all the outstanding "Permission missing from system" launchpad tickets into one branch. And I was also planning on merging all of the database upgrade scripts into one file. I was thinking that it would be easier to deal with them all at once, and just have one db update to apply and test. Is this an ok practice? |
| 11:07 |
bshum |
StomproJ++ # yes |
| 11:07 |
bshum |
And in fact I mentioned doing something similar at the Hackaway with mmorgan |
| 11:07 |
|
ericar joined #evergreen |
| 11:07 |
bshum |
Mainly I just worried about having tons of conflict |
| 11:08 |
bshum |
Though personally, I also suggested that it might be nice to get rid of the IDs entirely for permission and change it to work off the codes themselves as the key |
| 11:08 |
StomproJ |
The 950.seed-data conflicts is what made me want to do it in the first place. Every addition conflicts with every other addition, so combining them together seemed like a good idea. |
| 11:09 |
Dyrcona |
bshum: I seem to recall having the same idea about dropping ids for permissions. |
| 11:09 |
jeff_ |
as long as the changes are all similar in nature, it seems reasonable. if we do go that route, i'd suggest one omnibus LP bug to tie it all together. |
| 11:09 |
bshum |
It's been floating around for awhile. |
| 11:09 |
* bshum |
doesn't claim the idea as his |
| 11:09 |
jeff_ |
so that said omnibug would be attributed in the commit message, and could link to the individual bugs. |
| 11:09 |
StomproJ |
jeff_, that was my next question, if I should create a meta bug report to cover the ones I'm working on. |
| 11:10 |
jeff_ |
oh, look. i've been entailed. |
| 11:10 |
gmcharlt |
or even just create the new omnibus bug, then close out the older bugs as "duplicates" |
| 11:11 |
bshum |
+1 to gmcharlt's suggestion. |
| 11:13 |
miker |
StomproJ: I agree with jeff, but offer this warning: the .override permissions were (at the time) intentionally left out, as that is a "soft" mechanism. Any event could potentially become override-able, but not all need to be, so a prescribed list was eschewed in favor of letting sites add just the .override perm versions that they needed. the documentation for that was, of course, *COUGH* underwhelming as most early documentation was :) |
| 11:14 |
jeff |
launchpad doesn't give us much nuance with regard to this kind of thing, but duplicate seems to be the wrong designator there. i think it might also make things more difficult to search (an impressive feat). |
| 11:15 |
miker |
so, the .override permissions will likely continue to lag behind the state of the art... future batch updates will likely be needed |
| 11:15 |
gmcharlt |
jeff: meh - if the omnibus bug cites all of the perms being added from the bugs being closed out, it would be as searchable as before |
| 11:15 |
miker |
and google's site: makes it marginally searchable |
| 11:18 |
StomproJ |
miker, so should the .override related bugs be closed out and documentation updated instead? Or are you saying that the launchpad bugs for those are showing that they are needed in the default install? |
| 11:20 |
kmlussier |
I like including the override ones in the stock permissions if they are ones that are likely to be used. |
| 11:20 |
miker |
sorry I was unclear. I'm personally fine with adding the perms to the seed data (and an upgrade script), but many folks have added some of those perms already, so the upgrade should take care to renumber local ones |
| 11:21 |
bshum |
So, to remove IDs. I'm thinking we need to alter the permission map tables too then, to change them to map to the codes as well. |
| 11:21 |
miker |
AND documentation updates to explain that useful permissions can be added (or removed, as the site chooses) to change the ability to override events |
| 11:21 |
* bshum |
tries to think of where else to rip it out |
| 11:21 |
|
Christineb joined #evergreen |
| 11:21 |
miker |
bshum: the map tables should have ON UPDATE CASCADE fkeys to handle that |
| 11:21 |
miker |
(and if they don't, now would be a good time to add them) |
| 11:22 |
|
sarabee joined #evergreen |
| 11:23 |
StomproJ |
The updates have just been adding perms if they don't exist, and haven't tried to add new perms to perm groups so far. I would be against adding perms to groups on upgrades, but adding them to the seed data where it seems to make sense. There is just no telling what someone has in mind for the perm groups once they are in use. |
| 11:23 |
Dyrcona |
I'm gonna leave. I'll catch up with the logs, later. |
| 11:24 |
bshum |
StomproJ: What miker means is that sites may have individually already added the permissions as named. So if the upgrade script doesn't account for that possibility, it could fail right away on conflict (same name). |
| 11:24 |
bshum |
So renumbering an existing permission in someone's database to match what ends up in the seed code can be good for "consistency". |
| 11:25 |
bshum |
But if they already have an ID in their DB and it conflicts, that would be bad too. |
| 11:25 |
* bshum |
runs away for a moment too. |
| 11:25 |
kmlussier |
bshum: But if we remove the IDs, it solves that problem, right? |
| 11:25 |
bshum |
kmlussier: That's my hope. |
| 11:25 |
bshum |
Maybe that should be a 2.10 goal :) |
| 11:25 |
kmlussier |
bshum: Add it to the roadmap! :) |
| 11:26 |
gmcharlt |
bshum: if you're offering to do the work, go for it! :) |
| 11:26 |
berick |
what gmcharlt said |
| 11:26 |
* bshum |
contemplates, and wanders away |
| 11:26 |
berick |
too late, you have to do it now. |
| 11:26 |
kmlussier |
And I always thought if you added something to the roadmap, it just magically happened. ;) |
| 11:27 |
StomproJ |
bshum, I think the adding the same name case is covered, that shouldn't be a problem. But I hadn't thought about renumbering. I'll try to add that also. |
| 11:28 |
gmcharlt |
kmlussier: alas, the RM is fresh out of magic dust! ;) |
| 11:28 |
miker |
renumbering is important if we want to (or already do) protect permissions in UIs (the "reserved range" stuff in conify interfaces) |
| 11:31 |
dbs |
oh yay we have a local fix for our DBD::Pg HTML vs. Excel + CSV report output issue |
| 11:32 |
dbs |
long story short: use the classic 3-arg open(my $raw, ">:encoding(utf-8)", "$file.raw.html") approach to open the filehandle rather than pg_enable_utf8 & FileHandle |
| 11:33 |
* berick |
reads "maintain_control_numbers() GEICO identifiers" |
| 11:34 |
csharp |
@tea the GEICO gecko |
| 11:34 |
* pinesol_green` |
brews and pours a pot of Top Leaf™ Green Tea, and sends it sliding down the bar to the GEICO gecko (http://ratetea.com/tea/mellow-monk/top-leaf/1186/) |
| 11:35 |
berick |
the union of MARC and insurance... it doesn't get any better than that |
| 11:35 |
gmcharlt |
berick: that suggests an exciting new model for funding Evergreen development... insurance for your every metadata need! |
| 11:35 |
gmcharlt |
*snap* |
| 11:35 |
jeff |
miker: and if we're removing IDs adding a bool for "protect this / system perm" might be needed to take the place of the id range(s). |
| 11:36 |
berick |
gmcharlt: haha.. "do you keep losing bits to the bucket? have I got a product for you!" |
| 11:36 |
gmcharlt |
jeff: +1 |
| 11:37 |
jeff |
"Sorry, your Basic Naming Collision coverage doesn't extend to records with incorrect nonfiling indicators." |
| 11:37 |
* berick |
chuckles |
| 11:38 |
csharp |
@blame librarian road rage because of Evergreen |
| 11:38 |
pinesol_green` |
csharp: librarian road rage because of Evergreen broke Evergreen. |
| 11:39 |
jeff |
how recursively meta. |
| 11:39 |
berick |
it's a vicious cycle |
| 11:43 |
|
collum joined #evergreen |
| 11:46 |
kmlussier |
bug 1402018 has a milestone of 2.next, but it feels more like a bug fix to me than a new feature. |
| 11:46 |
pinesol_green` |
Launchpad bug 1402018 in Evergreen "Acq Copy location UI scoped to registered workstation" [Undecided,New] https://launchpad.net/bugs/1402018 - Assigned to Chris Sharp (chrissharp123) |
| 12:07 |
pinesol_green |
[evergreen|Steven Chan] Fix LP1175711, OPAC can't renew item on booking resource list - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=69e5ef2> |
| 12:08 |
|
Shae joined #evergreen |
| 12:15 |
kmlussier |
Anyone have opinions on whether the above acq copy location bug should be backported? |
| 12:15 |
* kmlussier |
wanders off to lunch |
| 12:16 |
|
bmills joined #evergreen |
| 12:17 |
dbs |
The "Fix HTML UTF8 output of clark-kent" fix we're using is here, if anybody wants to try it out locally: http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=commitdiff;h=8eb2187676508697c2cc6789626b2d08cc5df935 |
| 12:17 |
* dbs |
sees $index getting initialized twice, goes to fix that |
| 12:19 |
dbs |
I meant http://git.evergreen-ils.org/?p=contrib/Conifer.git;a=commitdiff;h=78d3d4e0347178651974f33549039d3058f9661f |
| 12:19 |
dbs |
yeah, yeah that's the ticket |
| 12:20 |
gmcharlt |
kmlussier: I think it reasonable to treat it as a backportable bugfix |
| 12:23 |
gmcharlt |
dbs: what about CSV and the debug HTML output? |
| 12:23 |
ldw |
Following the emails regarding test writing day and patch release day, I will postpone test writing day until next week. I will send out an email shortly. |
| 12:25 |
dbs |
gmcharlt: CSV seems to be handled by the Text::CSV_XS module, same way Excel module does |
| 12:25 |
gmcharlt |
OK |
| 12:26 |
gmcharlt |
(I'm asking on the basis of having just read the patch, not yet putting it through its paces) |
| 12:26 |
dbs |
I suppose debug should be fixed too, but I can count on one hand (literally) the number of times I've looked at the debug output |
| 12:26 |
dbs |
so that wasn't forefront of mind. More focused on the stuff most mortals actually see |
| 12:27 |
tsbere |
dbs: I know that at least one person here in the office uses debug frequently to see what went wrong in the SQL when a template doesn't quite work. |
| 12:27 |
dbs |
I haven't bugged this or submitted it as a formal fix because I'm curious about what happens on a system with DBD::Pg 3.0.0+ |
| 12:28 |
dbs |
tsbere: I can believe that |
| 12:35 |
|
jihpringle joined #evergreen |
| 12:41 |
kmlussier |
ldw: I don't think that's necessary. Dyrcona thought test-writing day was tomorrow, not today. |
| 12:42 |
kmlussier |
ldw: I clarified the date for him in channel, but forgot to send something out to the list. |
| 12:45 |
|
sarabee joined #evergreen |
| 12:45 |
dbs |
fwiw, the debug output seems thoroughly escaped; a report name of 'Test Francais 8é' gets translated in the output as 'name' => "Test francais 8\x{e9}" |
| 12:46 |
dbs |
which seems fine. But then the subject of the email gets corrupted because we're not doing the right SMTP things |
| 12:46 |
dbs |
so... how far down this rathole do we really want to go? Me, I'm happy just seeing the HTML output fixed as a start. |
| 12:47 |
dbs |
Having fixed the email output for action-trigger notifications way back when, the path is reasonably clear, but the cost/benefit ratio is suspect |
| 12:48 |
gmcharlt |
do what you can, LP the rest and move on |
| 12:50 |
kmlussier |
ldw: Another thing to consider, next week could be problematic due to U.S. Thanksgiving. |
| 12:57 |
|
jihpringle_ joined #evergreen |
| 12:57 |
|
Shae_ joined #evergreen |
| 13:11 |
pinesol_green |
[evergreen|blake] LP1402018_Acq_Copy_location_UI_scoped_to_registered_workstation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4b094b1> |
| 13:20 |
ldw |
kmlussier: ahhh. I think now that I have gone and spammed the list about a date change, I might as well stick with it. Hopefully, we can find one day next week that works for everyone in the US. |
| 13:24 |
ldw |
Unless everyone here wants to write tests today (just reading the emails now). I am fine with doing it today too. |
| 13:34 |
kmlussier |
I'm fine going along with the crowd. Based on the silence, I'm guessing there aren't many people around to do it today. |
| 13:34 |
ldw |
kmlussier: seems to be the case. Do people take extended holidays for Thanksgiving? Should I move it to the next week? |
| 13:38 |
kmlussier |
I think it's common for people to take both Thursday and Friday off - don't want to miss all those Black Friday sales. Monday and Tuesday might be better. |
| 13:38 |
kmlussier |
You could always keep next week on the poll and just add a few days from the following week just in case. |
| 13:38 |
ldw |
Ok, I will modify the Doodle Poll to include Monday and Tuesday. |
| 13:41 |
csharp |
kmlussier++ # using core committer access for great justice |
| 13:42 |
kmlussier |
csharp: My goal was to get through all the bugs with a signedoff tag. There's just one left, but it's a new feature, so I'm saving it for another day. :) |
| 13:43 |
csharp |
rock on |
| 13:45 |
|
jlitrell joined #evergreen |
| 14:06 |
|
Callender joined #evergreen |
| 14:16 |
* jeff |
ponders the idea of offering to set valid = true on an invalid address when saving changes to it |
| 14:22 |
tsbere |
jeff: I can see that being potentially useful. Also potentially annoying as "set to invalid" could be the change. |
| 14:22 |
jeff |
well, right. that would be what i would consider to be a poor implementation of my pondered feature. ;-) |
| 14:47 |
jeffdavis |
Just to confirm - SIPServer does not support fee payments, correct? |
| 14:48 |
tsbere |
jeffdavis: I believe it does, in fact, support payments now. |
| 14:48 |
tsbere |
Or, if it doesn't I wonder how one of our library's selfchecks are accepting payments. |
| 14:51 |
jeffdavis |
Are they using EG's native selfcheck interface instead of SIP? |
| 14:52 |
tsbere |
3M, I believe |
| 14:52 |
tsbere |
We don't have anyone using the native one |
| 14:52 |
tsbere |
Or if we do nobody told me |
| 14:57 |
bshum |
jeffdavis: As far as I know SIP payments are supported. |
| 14:58 |
bshum |
jeffdavis: I say that cause we're working on a spec for enhancing the support for it |
| 14:58 |
bshum |
So I've collected some information on what is there now |
| 14:58 |
bshum |
https://bugs.launchpad.net/evergreen/+bug/1012328 and https://bugs.launchpad.net/evergreen/+bug/803121 |
| 14:58 |
pinesol_green |
Launchpad bug 1012328 in Evergreen "Add support for Fine Items (AV) field in Patron Information response message (64)" [Wishlist,Fix released] |
| 14:58 |
pinesol_green |
Launchpad bug 803121 in Evergreen "SIP2 Fee Paid Message support (37/38)" [Wishlist,Fix released] - Assigned to Bill Erickson (berick) |
| 14:58 |
bshum |
Have been around for awhile. |
| 14:59 |
bshum |
What we're interested in (for one of our libraries) is adding the ability to pay a specific fine by ID, instead of mass bill payment. |
| 14:59 |
bshum |
So just some bills, not all bills. |
| 15:03 |
jeffdavis |
thanks |
| 15:08 |
tsbere |
bshum: As far as I know, the EG side of the SIPServer dance already *can* do that if the client sends over the ID. |
| 15:11 |
tsbere |
bshum: http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/perlmods/lib/OpenILS/SIP/Transaction/FeePayment.pm;hb=master#l64 |
| 15:11 |
bshum |
Fun |
| 15:12 |
* bshum |
ponders that |
| 15:12 |
bshum |
So maybe what we need is a way to let the client know about the billing ID then |
| 15:12 |
bshum |
I don't think that's covered by the patron information message |
| 15:13 |
jeff |
it's a matter of formatting the Fine Items field, mostly. |
| 15:13 |
jeff |
There was a spec. It was not supported by Vendor 3, despite their name being all over the spec. |
| 15:14 |
tsbere |
Yea, looking I don't think the formatted lines include the ID. Wouldn't be hard to *add*, but I dunno how various systems would react to it. |
| 15:15 |
jeff |
jeffdavis: going back to your original query, there is a distinction between "fine payment" and "fee payment" in some self check clients. Can you clarify if you're looking to support things like "we require $1 to check out this book"? That's "chargeable loans" or "fee" in some cases, distinct from "fines" like "you have these bills on your account". |
| 15:15 |
tsbere |
how much is owed, the last billing type, title/author or last note.... |
| 15:16 |
jeff |
tsbere: various systems will react differently. it would likely be best to have two "typical" formats and a templated config format string to support other formats. |
| 15:16 |
jeff |
one being "unformatted, what we've defaulted to for the past few years", another being "the sane/reasonable format that gives enough detail to support paying individual transactions", and then "give me a format string" :-) |
| 15:16 |
tsbere |
jeff: Fun. Not in my list of things to implement right now, though. |
| 15:17 |
* jeff |
nods |
| 15:19 |
tsbere |
jeff: Not that hard to implement if we say "this is going to be a perl-style sprintf format string, here are the things we are passing in, go wild" though. |
| 15:21 |
jeffdavis |
jeff: I was basically thinking "pay overdue fines" ... and getting confused by SIPServer's ILS::Transaction::FeePayment module which says "Not implemented," when I needed to be looking at the OpenILS::SIP::Transaction::FeePayment module in EG. :) |
| 15:21 |
jeffdavis |
In other words, your questions are too sophisticated for me. :P |
| 15:24 |
jeff |
jeffdavis: But did my questions help you to determine which questions to ask? :-) |
| 15:29 |
jeff |
oh, and I suppose above I should s/unformatted/unstructured/ on the "unformatted, what we've defaulted to" bit. |
| 16:20 |
jeff |
actor.hours_of_operation dow numbering is different from ISO 8601 (and postgres) dow numbering. |
| 16:21 |
jeff |
also different from Javascript getDay(). Huh. |
| 16:21 |
bshum |
That always used to drive me a little bit crazy. |
| 16:21 |
bshum |
Then I just stopped looking at it :) |
| 16:23 |
jeff |
Yeah. It seems vaguely familiar that I've been annoyed by this before. |
| 16:24 |
jeff |
I'm trying to see if I can make a report that's a bit more aware of hours of operation, closed dates, etc. |
| 16:26 |
tsbere |
jeff: That annoys me whenever I am looking at that too. |
| 16:42 |
csharp |
rock on |
| 16:42 |
csharp |
er.. that was from earlier ;-) |
| 16:43 |
csharp |
bad wifi |
| 16:43 |
csharp |
@blame bad wifi |
| 16:43 |
pinesol_green |
csharp: bad wifi wants the TRUTH?! bad wifi CAN'T HANDLE THE TRUTH!! |
| 16:43 |
kmlussier |
heh |
| 16:43 |
kmlussier |
mmorgan++ #Grabbing core queries from the NOBLE database. |
| 16:44 |
kmlussier |
I added it to the LP bug, but adding it here for the real karma points. :) |
| 16:44 |
csharp |
@blame add Forget it, Jake. It's just $who. |
| 16:44 |
pinesol_green |
csharp: The operation succeeded. Blame #20 added. |
| 17:11 |
|
dcook joined #evergreen |
| 17:13 |
* mmorgan |
emerges from last meeting of the day just in time to go home :) |
| 17:14 |
csharp |
mmorgan: that's always nice |
| 17:15 |
mmorgan |
Indeed! Good night #evergreen! |
| 17:15 |
|
mmorgan left #evergreen |
| 17:16 |
kmlussier |
gmcharlt: Remind me. Do we have a deadline yet for when new features need to be posted to LP to make it for beta? |
| 17:18 |
kmlussier |
gmcharlt: Never mind. jlitrell found it for me. Feb. 5 |
| 17:18 |
jlitrell |
http://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:2.10 |
| 17:19 |
gmcharlt |
*quack* |
| 17:19 |
jlitrell |
2016, the year of Linux on the desktop. |
| 17:20 |
berick |
heh |
| 17:27 |
miker |
jeff: re DOW numbering, that comes from perl's DateTime module, IIRC. to facilitate biz-logic-layer ease |
| 17:27 |
miker |
kmlussier: bug updated ... with a branch :) |
| 17:28 |
kmlussier |
Excellent! I may load up a VM with it now. |
| 17:28 |
kmlussier |
miker++ |
| 17:28 |
* csharp |
finds http://search.cpan.org/~drolsky/DateTime-1.21/lib/DateTime.pm#0-based_Versus_1-based_Numbers based on miker's last comment |
| 17:28 |
kmlussier |
hmmm...I wonder if I can find a good example in Concerto to test the branch against. |
| 17:29 |
miker |
kmlussier: it's a one-liner ... maybe noble's test system can absorb it? |
| 17:31 |
miker |
csharp: right... my thinking was, "if we use the /explicit/ *_0 method names in the perl, there will never be a question" ... whether that thinking was sound is left as an exercise for the reader to determine ;) |
| 17:31 |
kmlussier |
miker: Maybe. I'll run it by them in the morning since it looks like mmorgan just left. |
| 17:31 |
csharp |
miker: makes sense ;-) |
| 17:32 |
miker |
of course, the module's contention that "There is a year 0." is ... problematic :) |
| 17:33 |
csharp |
@eightball is there a year 0? |
| 17:33 |
pinesol_green |
csharp: The answer is certainly yes. |
| 17:34 |
csharp |
cal: year `0' not in range 1..9999 |
| 17:35 |
dbwells |
Those year 10000 bugs are going to be a doozy |
| 17:35 |
csharp |
heh |
| 17:40 |
|
Christineb joined #evergreen |
| 19:14 |
jwoodard |
@librarian |
| 19:14 |
pinesol_green |
jwoodard: Management:13, Cataloging:14, Acquisitions:14, Reference:14, Circulation:7, Systems:14, Research:7, Custodial:17 |
| 19:16 |
jwoodard |
Circulation has felt like that today. "You want to check out a book? Let me get my Director." |
| 19:26 |
kmlussier |
jwoodard: On the plus side, you're acing custodial! |
| 19:28 |
kmlussier |
For the 2.9 point release notes, I'm structuring things a bit differently. I've never been quite happy with the way I handled some things with the 2.8 release notes. |
| 19:28 |
kmlussier |
I have a working branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kmlussier/2-9-1-release-notes if anyone wants to take a look at the changes before I merge them tomorrow. |
| 19:31 |
kmlussier |
And a gist that shows the changes at https://gist.github.com/anonymous/41365389d5f537428538 |
| 19:51 |
kmlussier |
@sortinghat |
| 19:51 |
pinesol_green |
Hmm... kmlussier... Let me see now... SLYTHERIN! |
