| 02:24 |
|
Mark__T joined #evergreen |
| 02:38 |
|
mrpeters joined #evergreen |
| 04:33 |
|
mrpeters joined #evergreen |
| 05:08 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:05 |
|
sbrylander joined #evergreen |
| 06:07 |
|
pmurray_away joined #evergreen |
| 07:11 |
|
sarabee joined #evergreen |
| 07:21 |
|
mrpeters joined #evergreen |
| 07:36 |
miker |
bshum: re later from last night, I'll respond to your comment when I get to a real computer, but tldr is "no, there are no concerns about 9.2+, and yes imo it should be pushed". I was hoping csharp would test as the reporter, but such is life and bugs |
| 07:45 |
|
rjackson_isl joined #evergreen |
| 07:47 |
|
jboyer-isl joined #evergreen |
| 08:02 |
|
ericar joined #evergreen |
| 08:51 |
|
yboston joined #evergreen |
| 08:56 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
ericar_ joined #evergreen |
| 09:05 |
dbwells |
bshum: thanks for testing. I am guessing you didn't grab enough commits from that branch. There are four by remingtron, but they are proceeded by two of mine, and those have the function you seek. |
| 09:08 |
Dyrcona |
FYI, I usually do a git merge into a development branch when testing. |
| 09:08 |
Dyrcona |
That way you don't miss commits. |
| 09:09 |
Dyrcona |
And, you can can always use https://gist.github.com/Dyrcona/4629200 |
| 09:10 |
Dyrcona |
Just don't use the latter if cherry-picking into a rel_* branch, it'll end up moving over most of master, too. |
| 09:42 |
|
Khanson_ joined #evergreen |
| 09:44 |
Dyrcona |
So, the beta is when the rel_2_X branch gets made, correct? |
| 09:53 |
dbwells |
I think I waited until RC, with the goal of minimizing hassle while focusing on bug fixes, but either way makes sense. In reality, master isn't likely to drift far very fast, so the hassle is really minimal. |
| 09:54 |
mrpeters |
from a personal standpoint, the branch would be nice to have at beta time, as we use it to test our debs |
| 09:54 |
mrpeters |
but, if a tarball is available, that is sufficient too |
| 09:55 |
dbwells |
It would get a "tag" branch in any case, I would think. |
| 10:00 |
|
pmurray joined #evergreen |
| 10:04 |
|
Khanson_ joined #evergreen |
| 10:14 |
csharp |
jeff: :-D |
| 10:15 |
Dyrcona |
bshum removed code from Makefile.am that cleans out existing files because it breaks with fresh installs after the branch is applied. |
| 10:15 |
Dyrcona |
I think we should put those lines back, but add if [ -d .... ] and if [ -f .... ] around the shell code. |
| 10:16 |
Dyrcona |
Or just throw the tests on the line with && in appropriate places. |
| 10:16 |
csharp |
miker: bshum: I'll give bug 1438136 a final poke and will comment on it and/or signoff - sorry for the delay :-/ (yep, life getting in the way) |
| 10:16 |
pinesol_green |
Launchpad bug 1438136 in Evergreen 2.8 "OPAC searching significantly slowed by adding format filters" (affected: 4, heat: 20) [High,Triaged] https://launchpad.net/bugs/1438136 |
| 10:16 |
Dyrcona |
But, maybe, instead of what it does, it should rm existing files for upgrades. |
| 10:33 |
Dyrcona |
berick: Sure thing. I'll probably be asking for help by that point. :) |
| 10:33 |
berick |
k, no problem. and I'm not in any rush, so do your thing :) |
| 10:38 |
|
RoganH joined #evergreen |
| 10:39 |
bshum |
dbwells: I could have sworn I did a merge/rebase when I tested, but you must be right. |
| 10:39 |
bshum |
dbwells: I'll see if I can rectify all that once I get to the office.. |
| 10:39 |
dbwells |
bshum: thanks! |
| 10:40 |
bshum |
No thank you! dbwells++ |
| 10:40 |
Dyrcona |
I'd /like/ to have the tarball on the website by 16:00 EDT. |
| 10:40 |
bshum |
This is what happens when I test at the 11th hour. |
| 10:43 |
kmlussier |
16:00? So how long does that give us to do any last-minute sign-offs? |
| 10:43 |
bshum |
Heh |
| 10:44 |
* bshum |
salutes Dyrcona, "Yes sir!" |
| 10:48 |
Dyrcona |
About 0, I think, but I'm making an exception for that as I consider it part of a feature that is already in. |
| 10:48 |
Dyrcona |
I think I'll note that on the bug, actually. |
| 10:48 |
kmlussier |
OK, then, I think I'll update the release notes to reflect what is there now. |
| 10:49 |
dbwells |
kmlussier: I guess I am more optimistic than Dyrcona, but I don't know how much chance it really has. Testing the code internally now... |
| 10:49 |
kmlussier |
I can always update it when bug 1479107 is done. |
| 10:49 |
pinesol_green |
Launchpad bug 1479107 in Evergreen "Replace manual void option with an "adjust to zero" option" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479107 - Assigned to Dan Wells (dbw2) |
| 10:49 |
kmlussier |
dbwells: I'm on hand to drop everything else to test it when it's ready. :) |
| 10:49 |
Dyrcona |
dbwells: Oh. I don't know how far along you were. |
| 10:49 |
Dyrcona |
s/don't/didn't/ |
| 10:50 |
kmlussier |
Also, the other remaining piece of the negative balance puzzle was bug 1479107 . Just an update to the description for an OU setting if anyone wants to take a look at it. |
| 10:50 |
Dyrcona |
I can test it, too. I'm still waiting on a db reload to finish, so I can add it to my branch with sprint2. |
| 10:50 |
kmlussier |
Wrong bug number apparently |
| 10:50 |
kmlussier |
bug 1479110 |
| 10:50 |
pinesol_green |
Launchpad bug 1479110 in Evergreen "Negative balance settings used in combination with one another should interact differently" (affected: 1, heat: 6) [Medium,New] https://launchpad.net/bugs/1479110 |
| 10:50 |
kmlussier |
How do I copy and paste a bug number incorrectly? |
| 10:51 |
jeff |
then when the beta's out, we can REALLY find the bugs. ;-) |
| 10:52 |
jboyer-isl |
I’d also like to stump for bug 1371647 real quick, it’s just a seed data bump (and full tests therefore, Dyrcona changed my mind about that) but not being a bugfix if it’s not in today, it’s 2.9.1 :( |
| 10:52 |
pinesol_green |
Launchpad bug 1371647 in Evergreen "config.marc21_ff_pos_map needs an audit" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1371647 |
| 10:52 |
Dyrcona |
kmlussier: Good typo, though, I've been meaning to look at that one, too. |
| 10:53 |
dbwells |
I guess I'll join the party. If anybody has any extra review eyes, I'd be very happy to see bug 1422379 get in. I have some good display improvements which depend on it, and I feel that biting the bullet it better than stringing it along. |
| 10:53 |
pinesol_green |
Launchpad bug 1422379 in Evergreen "Move money.billing timestamps back to moment of fine" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1422379 |
| 10:55 |
jeff |
dbwells: would the improvements be dampened if the upgrade script doesn't touch ALL billings? i.e., if it were to opt not to change the date on billings on transactions that were closed, or had payments? |
| 10:55 |
jeff |
dbwells: are there interactions with conditional negative billing? |
| 10:55 |
jeff |
dbwells: should we throw it in the beta so it's in there, THEN test the heck out of it? ;-) |
| 10:56 |
dbwells |
jeff: The only billings it /has/ to change are the open ones, i.e. ones which might accrue more overdue files. Otherwise, there will be a ripple in the fine stream. |
| 10:56 |
dbwells |
s/files/fines |
| 10:57 |
kmlussier |
Can I also make a pitch to core committers to review bugs that already have a signedoff tag? http://bit.ly/1E3DGNg |
| 11:23 |
berick |
bshum++ thanks |
| 11:23 |
* berick |
hates making messes |
| 11:23 |
bshum |
Just getting tsbere's fix for amnesty/backdating in first |
| 11:25 |
Dyrcona |
To any of the core committers: Feel free to push anything from test writing day that hasn't gone in, yet. If tests break, we can fix them after. :) |
| 11:25 |
pinesol_green |
[evergreen|Thomas Berezansky] LP#1444514: Have amnesty mode override backdate for voiding - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dcdce01> |
| 11:26 |
bshum |
berick: Pushed, thanks |
| 11:26 |
bshum |
berick++ |
| 11:26 |
jeff |
Dyrcona: are you saying those need to go in before beta, otherwise wait until next? |
| 11:26 |
Dyrcona |
No, I'm not saying that. I suppose that they could go in at any time, really. |
| 11:27 |
pinesol_green |
[evergreen|Bill Erickson] LP#1476370 Selfcheck warning template cleanup - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=8e0fdc5> |
| 11:28 |
Dyrcona |
I s'pose I'm giving a temporary dispensation to not test the tests for the beta. :) |
| 11:28 |
jeff |
hah |
| 11:28 |
jeff |
okay, noted. :-) |
| 11:29 |
berick |
thanks bshum |
| 00:15 |
|
bmills joined #evergreen |
| 01:39 |
|
Mark__T joined #evergreen |
| 04:52 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 06:32 |
|
artunit_away joined #evergreen |
| 07:02 |
|
jacobsd joined #evergreen |
| 07:20 |
|
rlefaive joined #evergreen |
| 07:35 |
|
jboyer-isl joined #evergreen |
| 07:48 |
|
mrpeters joined #evergreen |
| 07:57 |
|
jacobsd_ joined #evergreen |
| 08:00 |
jacobsd_ |
Good Morning. First time here. Testing a Kindle app and drinking coffee. Lots of coffee. |
| 08:16 |
|
eby joined #evergreen |
| 08:20 |
|
ericar joined #evergreen |
| 08:27 |
kmlussier |
Good morning jacobsd_. Welcome! |
| 09:05 |
|
maryj joined #evergreen |
| 09:06 |
|
jwoodard joined #evergreen |
| 09:12 |
Dyrcona |
gmcharlt++ kmlussier++ # For following up on bugs last night. |
| 09:16 |
kmlussier |
berick: I'm testing bug 1440114 this morning, but I was also wondering if a test is needed for that code. |
| 09:16 |
pinesol_green |
Launchpad bug 1440114 in Evergreen "Support "blanket" orders in acquisitions via direct charges" (affected: 1, heat: 8) [Wishlist,New] https://launchpad.net/bugs/1440114 - Assigned to Kathy Lussier (klussier) |
| 09:16 |
* kmlussier |
still doesn't have a good handle on how to determine if a test is needed and, therefore, may be asking that question a lot this week. |
| 09:18 |
* kmlussier |
is also setting a goal to get acq data in the Concerto dataset before the 2.10 release so that she doesn't have to continually create funds & providers every time she tests acq. |
| 09:19 |
berick |
kmlussier: hm, yeah, a pgtap test at minimum. i can look at that today |
| 09:19 |
berick |
thanks for testing |
| 09:19 |
|
akilsdonk_ joined #evergreen |
| 09:20 |
|
RoganH joined #evergreen |
| 09:20 |
|
yboston joined #evergreen |
| 10:58 |
|
jcamins__ joined #evergreen |
| 10:59 |
Dyrcona |
Well, fr_fr is AZERTY. |
| 11:05 |
|
csharp joined #evergreen |
| 11:07 |
bshum |
jeff: Well, for fun note, make install fails on the jspac removal branch because it tries to copy the jspac files and fails to do so |
| 11:10 |
|
bmills joined #evergreen |
| 11:12 |
|
eady joined #evergreen |
| 11:12 |
|
mtj_ joined #evergreen |
| 11:13 |
bshum |
I think it draws from webcore-install in Open-ILS/web/Makefile.am |
| 11:14 |
bshum |
The last step there is a cd to the different dirs for legacy web |
| 11:14 |
bshum |
And that fails cause we're removing most of them |
| 11:15 |
* bshum |
rebuilds without that for i loop to test |
| 11:17 |
|
bmills1 joined #evergreen |
| 11:17 |
bshum |
That worked at least. |
| 11:18 |
bshum |
Though we probably should go back and gut that Makefile to remove unnecessary bits |
| 11:18 |
* bshum |
builds a staff client to test interfaces |
| 11:18 |
|
bmills joined #evergreen |
| 11:27 |
kmlussier |
berick: In my last comment on the blanket bug, please replace any mentions of "standing order" with the word "blanket." |
| 11:27 |
* kmlussier |
hasn't had her coffee yet this morning. :/ |
| 12:32 |
pdot |
*has all |
| 12:32 |
|
jwoodard joined #evergreen |
| 12:35 |
kmlussier |
pdot: Yes, but it could be another way that the bug manifests itself. |
| 12:35 |
* mmorgan |
did not consider that the bug might be an issue with primary and secondary permission groups as well. Will need to test some more... |
| 12:45 |
mrpeters |
so, come to find out, we're already giving a hint about the password -- Open-ILS/src/templates/opac/myopac/update_password_msg.tt2 |
| 12:45 |
mrpeters |
Note: The password must be at least 7 characters in length, contain at least one letter (a-z/A-Z), and contain at least one number. |
| 12:46 |
mrpeters |
so my patch will only touch the config.org_unit_setting_type with a hint to update that template if you make a change to the regex |
| 14:26 |
jihpringle |
we found that sometimes we had to go through the MARC file and then would find that suddenly the vendor had a typo in a fund code |
| 14:26 |
RoganH |
Sometimes it's useful just to have reaffirmation that my suspicions are right. And yep, it looks like the fund codes got changed. |
| 14:26 |
jihpringle |
I want to say that once there was an extra space before one of the fund codes that threw everything |
| 14:27 |
pdot |
so I've decided to try creating another global admin account to test stuff out, still no luck with add a new patron. could someone tell my the privs required, and their default values? |
| 14:28 |
jihpringle |
I don't know what is actually possible, but long term it would be nice to have the error message at least point you to what it didn't like in the MARC file |
| 14:28 |
jihpringle |
it shouldn |
| 14:29 |
jihpringle |
pdot: it shouldn't affect a gobal admin account, but do you have a working location assigned? |
| 14:44 |
pdot |
hmm, neither seem to function for me, could this have something to do with circulation policy? |
| 14:51 |
mmorgan |
pbot: circulation policies shouldn't prevent you from adding a user. |
| 14:52 |
|
jlitrell joined #evergreen |
| 14:52 |
pdot |
alright, I think I have a hunch as to what my issue is, will confirm in a minute |
| 14:53 |
|
jihpringle joined #evergreen |
| 14:55 |
pdot |
so, I think it's because my schema has no ou at the system level. If I'm correct in assuming that the ACL is a database value comparision, anything at the system level might not be applying |
| 14:56 |
pdot |
in short, my setup looks like consortium > branch1 & 2 |
| 14:57 |
pdot |
as I only have test records at this point anyway, I suspect a DB wipe is in order |
| 14:58 |
kmlussier |
pdot: I don't know the details on this, but I think I've heard it's best to use, at a minimum, the consortium -> system -> branch hierarchy. We have one site that has added a level, but I don't think you want fewer than those three. |
| 15:02 |
pdot |
yeah, I think that's for the best. if my rebuild fixes the issue, I'll make a note for future documentation |
| 15:22 |
|
jonadab_znc joined #evergreen |
| 16:04 |
tsbere |
@weather 01834 |
| 16:04 |
pinesol_green |
tsbere: The current temperature in King St, Groveland, Massachusetts is 87.6°F (4:03 PM EDT on August 18, 2015). Conditions: Overcast. Humidity: 60%. Dew Point: 71.6°F. Pressure: 29.98 in 1015 hPa (Falling). |
| 16:04 |
* tsbere |
glares at web browser not being able to load several weather sites due to a local routing issue |
| 16:06 |
pdot |
locale test! |
| 16:06 |
pdot |
@weather n0b1e0 |
| 16:06 |
pinesol_green |
pdot: The current temperature in Ayr, Ayr, Ontario is 78.1°F (4:06 PM EDT on August 18, 2015). Conditions: Mostly Cloudy. Humidity: 71%. Dew Point: 68.0°F. Pressure: 29.92 in 1013 hPa (Falling). |
| 16:07 |
pdot |
a most useful bot |
| 16:07 |
jlitrell |
Huh, that's cool. |
| 16:10 |
pdot |
all I know is, they're equal when it's -40 out (a not uncommon occasion here) |
| 16:11 |
jlitrell |
Ahh, memories of my youth. I think that's why I enjoy stories of people walking out of Siberia. Reminds me of waiting for the bus in Edmonton. |
| 16:11 |
pdot |
ha, I have spent a few weeks in leduc |
| 16:13 |
Stompro |
Hello, does anyone know how man requests a second their EG front end servers can handle loading the default page? I'm just doing a little testing with the apache bench (ab), and i'm seeing about 11 request/second per server, 20 request/sec through our load balancer. |
| 16:17 |
bshum |
Stompro: I haven't tested that lately. |
| 16:17 |
bshum |
The last time I tried, I knocked out some servers by asking for like 1000 pages at once.... |
| 16:17 |
bshum |
But I feel like hopkinsju and/or Bmagic talked about that stuff once upon a time. |
| 16:18 |
bshum |
I wonder if they have better metrics for that sort of thing now. |
| 16:19 |
bshum |
gmcharlt: So I think that the 2.9 merge for web client sprint2 looks okay. I'm going to wait for Dyrcona to double-check, but I can see the major change between that and the time I last tested was the new copy/volume editing pieces. |
| 16:19 |
Stompro |
I was doing 1000 requests, 32-64 at a time. It looks like it is cpu bound on my hardware. |
| 16:19 |
bshum |
And none of that seems to touch any existing perl/XUL/SQL code, so I don't think it'll break anything to push that along. |
| 16:19 |
bshum |
The ordering of the sql upgrades is handy too, I'd just been guessing at it while testing. |
| 16:21 |
bshum |
berick++ # cool, glad your tests on jspac removal looked good too. |
| 16:22 |
kmlussier |
I have a question about the changing of labels in the acq admin menu that I was discussing with jihpringle earlier? If I change the labels, should I also change the accesskey to something that is more suitable for the new label? |
| 16:23 |
kmlussier |
Or do you think there are users that are accustomed to using the old accesskeys? I don't imagine they are visiting either of these interfaces very often. |
| 16:23 |
bshum |
I think it makes sense to use a key that matches the label. |
| 17:43 |
kmlussier |
remingtron++ |
| 17:43 |
pinesol_green |
[evergreen|Kathy Lussier] lp1486252 Change label for acq admin menu - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3793dde> |
| 17:55 |
jeffdavis |
kmlussier++ # thaks for the reminder about release notes |
| 18:12 |
bshum |
Hmm, I find myself confused now... |
| 18:13 |
bshum |
remingtron / dbwells: Looking over at https://bugs.launchpad.net/evergreen/+bug/1379815 and testing it, but I can't seem to see the stat cat data field during holdings import profiles. |
| 18:13 |
pinesol_green |
Launchpad bug 1379815 in Evergreen "Assign stat cats during Vandelay import/overlay of items" (affected: 1, heat: 8) [Wishlist,New] |
| 18:13 |
bshum |
I checked and my fm_IDL.xml has the proposed changes in there |
| 18:13 |
bshum |
and i would have thought that to update the dojo generated table accordingly, but wacky, weird, nothing seems to show up. |
| 18:20 |
bshum |
Hmm, yep, it should have shown up, since we altered viiad in fm_IDL.xml |
| 18:20 |
bshum |
That's super annoyingly weird... |
| 18:21 |
kmlussier |
bshum: I just loaded that on a VM today. I can take a look later. |
| 18:21 |
bshum |
kmlussier: I'm going to clear my cache and restart everything one more time just to be sure. |
| 18:21 |
bshum |
kmlussier: But thanks, I appreciate any insights you've got later. |
| 18:22 |
bshum |
This is admittedly an area of Evergreen I'm a little weaker on :( |
| 18:22 |
bshum |
Oh, nevermind there it is. |
| 18:22 |
bshum |
Maybe I had to copy it to both fm_IDL.xml files... |
| 18:23 |
bshum |
The one in /openils/conf and the one under /openils/var/web/reports/ |
| 18:23 |
bshum |
Wacky |
| 18:23 |
* bshum |
carries on with exploding his test server with nonsense |
| 18:25 |
bshum |
"Dancing *after* dinner!" |
| 18:25 |
* bshum |
goes to eat first. |
| 18:57 |
|
jihpringle_ joined #evergreen |
| 20:30 |
kmlussier |
Ugh. Why am I getting a conflict on berick's blanket order branch when he just rebased it today? |
| 20:45 |
bshum |
Maybe the progress bar changes touched the same files? |
| 22:24 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1450561: Restore org. unit settings history limit function and trigger - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=34337bd> |
| 22:24 |
pinesol_green |
[evergreen|Ben Shum] LP#1450561: Stamping upgrade script for library settings editor history limits - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=88e32ab> |
| 22:28 |
bshum |
Calling 0926 |
| 22:34 |
pinesol_green |
[evergreen|Dan Pearl] LP#1204671 Allow fund tags to remain attached to new fund during end-of-year propagation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=6fe3bbe> |
| 22:34 |
pinesol_green |
[evergreen|Ben Shum] LP#1204671: Stamping upgrade script for fund tag propagation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7a0ecf9> |
| 22:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1481036 Ignore future backdates (part 2). - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=dd8f8d5> |
| 22:42 |
pinesol_green |
[evergreen|Bill Erickson] LP#1481036 Ignore future backdates live test - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c22cd51> |
| 22:57 |
bshum |
@later tell tsbere Need a rebase on https://bugs.launchpad.net/evergreen/+bug/1444514 for master only. The code is fine for rel_2_8 and rel_2_7, but didn't apply to master because of some changed code. Will try to get that sorted before release cutting tomorrow, pushed the fix through to the older branches for now. |
| 22:57 |
pinesol_green |
bshum: The operation succeeded. |
| 22:57 |
pinesol_green |
Launchpad bug 1444514 in Evergreen "Amnesty Mode doesn't work correctly with Backdating" (affected: 2, heat: 10) [Medium,Confirmed] |
| 23:05 |
bshum |
Calling 0927 |
| 23:06 |
jeff |
bshum++ |
| 23:07 |
kmlussier |
bshum++ |
| 23:08 |
bshum |
I just get nervous about bugs which only work on newer PostgreSQL versions. |
| 23:08 |
bshum |
Mostly in that I only run the newer PG 9.3 now, and so I don't test on PG 9.1 anymore :\ |
| 23:08 |
bshum |
Anyways... |
| 23:08 |
pinesol_green |
[evergreen|Dan Wells] LP#1419172 Optimize full_circ_count view to avoid seq scans - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=54eb62a> |
| 23:08 |
pinesol_green |
[evergreen|Ben Shum] LP#1419172: Stamping upgrade script for optimizing full circ count - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0cbc35b> |
| 23:10 |
pinesol_green |
[evergreen|Dan Scott] LP1431541: SRU UTF8 encoding issues - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=81e6929> |
| 10:34 |
Dyrcona |
With BOM, of course. |
| 10:36 |
|
RoganH joined #evergreen |
| 10:38 |
jboyer-laptaupe |
Dyrcona, I'm trying to output something that won't make yaz-marcdump throw up, I don't think that would do it. ;) |
| 10:39 |
Stompro |
testing multiple bugs display, sorry for the spam, bugs 1485240, 1485240 |
| 10:39 |
pinesol_green |
Launchpad bug 1485240 in Evergreen "Remove last vestiges of script-based circ rules" (affected: 1, heat: 6) [Undecided,Confirmed] https://launchpad.net/bugs/1485240 |
| 10:39 |
Stompro |
testing multiple bugs display, sorry for the spam, bugs 1485240, 1484655 |
| 10:39 |
pinesol_green |
Launchpad bug 1484655 in Evergreen 2.8 "ftp://ftp.mozilla.org has moved to http://archive.mozilla.org" (affected: 1, heat: 6) [High,Fix committed] https://launchpad.net/bugs/1484655 |
| 10:40 |
Stompro |
Hmm, that didn't work. |
| 10:40 |
Stompro |
Unless it watches what it just did, and doesn't repeat bugs that were recently displayed. |
| 10:43 |
Dyrcona |
jboyer-laptaupe: Fun thing, is a lot of MARC are actually ISO-8859-1 or some MS encoding when they should be MARC-8. |
| 10:44 |
Dyrcona |
jboyer-laptaupe: Good luck! :) |
| 10:44 |
bshum |
Stompro: pretty sure it doesn't repeat bugs for X time where X is beyond my recollection. |
| 10:45 |
Stompro |
I'm testing over at #openils-evergreen, and the multiple bug display worked fine there, so it was just refusing to display the same bug again immediatly. |
| 10:46 |
bshum |
Indeed |
| 10:48 |
jboyer-laptaupe |
Dyrcona: Hah! looks like what I'm seeing isn't my problem anyway. Just trying to use yaz-marcdump to break records into line mode and then rebuild them as marc doesn't work (at least not with these Overdrive records...) |
| 10:50 |
mmorgan |
Anyone seen anything like this: |
| 11:08 |
Dyrcona |
I have a local ticket that I made about it in June of last year, but never made a launchpad bug. |
| 11:08 |
jeff |
and indeed, this bucket has four items, but one of the items is there 15 times and the other is there 41 times. |
| 11:09 |
Dyrcona |
I started working on a script to clean them up and a possible solution in the UI, but other things came up. |
| 11:10 |
Stompro |
testing git integration, looking at commit 0f8ec1 |
| 11:10 |
pinesol_green |
[evergreen|Bill Ott] LP#1394989: Do not include deleted users when retrieving for Collections - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=0f8ec14> |
| 11:10 |
|
ericar_ joined #evergreen |
| 11:10 |
Dyrcona |
By "started working on," I probably mean just thinking about an implementation. |
| 11:14 |
* jeff |
nods |
| 11:14 |
Dyrcona |
There is a launchpad bug about the lack of feedback on that interface. |
| 11:14 |
Dyrcona |
Fixing that would go some way toward helping. |
| 11:15 |
Dyrcona |
My testing didn't reveal any scenarios other than a patron clicking the button 41 times that would cause it to get added 41 times. |
| 11:16 |
Dyrcona |
The dates on the bucket entries also ruled out an older bug. |
| 11:17 |
jeff |
looks like about three dupes per second on this example here. |
| 11:18 |
Dyrcona |
That sounds a bit fast for a human, but not impossible. |
| 11:40 |
Dyrcona |
jeff: I'll see if I can condense the stuff from the links about into a lp bug today. |
| 11:40 |
Dyrcona |
s/about/above/ |
| 11:41 |
Dyrcona |
"kilometers" of paper....I'm curious: how many kilometers has it printed? |
| 11:42 |
jeff |
0.044 km, 1249 cuts. |
| 11:42 |
jeff |
this particular model has mostly been used for testing. |
| 11:42 |
jeff |
and printing names for a hat for summer reading drawings. |
| 11:42 |
jeff |
so, lots of short jobs. |
| 11:42 |
Dyrcona |
ok. not as interesting as one from a circ. desk. |
| 11:43 |
jeff |
right. |
| 11:43 |
jeff |
now i wonder about the printer embedded in the self checkout kiosks. |
| 16:53 |
mrpeters |
ah yes, it is -- config.org_unit_setting_type |
| 16:56 |
mrpeters |
so i'd propose a simple UPDATE config.org_unit_setting_type SET description = 'Regular expression defining the required password format when resetting passwords. Note: Adjust description in config.tt2 to suit your requirements.' WHERE name='global.password_regex'; if that kind of database change is permitted at this stage in the game |
| 16:58 |
Stompro |
yboston, the subject of your email to the dig list about the irc practice has a different date & time than the body. Subject says 26th 3pm eastern, body says June 24th 2pm est. |
| 17:01 |
yboston |
Stompro: that is what I get for copy pasting |
| 17:06 |
yboston |
Stompro: I also has the date wrong from the text I pasted |
| 17:07 |
yboston |
Stompro: BTW, we shoudl coordinate to sign-off on each other's PGTAP tests at soem point this week |
| 17:08 |
|
mmorgan left #evergreen |
| 17:10 |
pinesol_green |
Incoming from qatests: Test Failure - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:12 |
jeff |
Additional error details: |
| 17:12 |
jeff |
fatal: remote error: |
| 17:12 |
jeff |
Storage server temporarily offline. See https://status.github.com for GitHub system status. |
| 17:26 |
Stompro |
yboston, yes to the pgtap signoffs, later this week works for me. |
| 19:01 |
|
jacobsd joined #evergreen |
| 19:03 |
|
jacobsd joined #evergreen |
| 21:16 |
pinesol_green |
[evergreen|Liam Whalen] LP1483509: tests for xml_famous5_to_text - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ff8d9d1> |
| 21:16 |
kmlussier |
Does bug 1331174 meet the criteria of requiring a new test before it can be merged? |
| 21:16 |
pinesol_green |
Launchpad bug 1331174 in Evergreen "Long Overdue processing needs org unit settings separate from Lost Processing" (affected: 5, heat: 22) [Wishlist,Confirmed] https://launchpad.net/bugs/1331174 |
| 21:17 |
kmlussier |
I'm probably addressing the question to an empty room, but I see from my email that gmcharlt is still working. :) |
| 21:20 |
gmcharlt |
kmlussier: if nothing else, it meets the condition of being in a functional area where clear unit tests would be very, very nice :) |
| 21:20 |
kmlussier |
gmcharlt: Thanks! |
| 21:34 |
pinesol_green |
[evergreen|Bill Erickson] LP#483502 PGTAP test for evergreen.xml_escape(TEXT) - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7fec477> |
| 21:46 |
pinesol_green |
[evergreen|Josh Stompro] LP#1478123: fix leak of file descriptors by Apache workers - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ded781a> |
| 22:02 |
pinesol_green |
[evergreen|Josh Stompro] LP#1463097 - eg_db_config.in help text fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fa312e5> |
| 22:08 |
pinesol_green |
[evergreen|Josh Stompro] LP#1468404: Fix typo and ommissions in action_trigger_aggregator.pl help - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=88ae6a4> |
| 09:56 |
berick |
i think you can also configure rsyslog to drop new messages when its outbound queueu fills up instead of throttling the message submitter |
| 09:57 |
berick |
as a last layer of defense |
| 10:01 |
* berick |
puts on his test-writing pants |
| 10:04 |
ldw |
How do we want to work on tests today? Do people want to take a bug and work on it idependently? Do we need to discuss pgTap or test writing in general? |
| 10:04 |
ldw |
s/idependently/independently/ |
| 10:10 |
|
Christineb joined #evergreen |
| 10:13 |
|
Shae joined #evergreen |
| 10:14 |
Stompro |
I think I understand what needs to be done for the evergreen.lowercase test, I just have to get things setup so I can test it. I'll let you know if I run into anything. |
| 10:18 |
berick |
i'm going off-script a little bit and doing a perl live test. will return to pgtap after that. |
| 10:18 |
jboyer-isl |
I’ll be pretty in and out as far as test writing day goes ( :( ) but I would like to recommend that tests include things expected to fail. I don’t mean tests that fail, I mean writing the tests so that they basically say “This sql/function/etc. should fail and that’s ok. If it doesn’t fail, fail this test.” |
| 10:20 |
ldw |
jboyer-isl: do you mean pass in data to the function that should fail it and check for the fail? |
| 10:21 |
jeff |
that's how i interpreted his statement. |
| 10:22 |
jboyer-isl |
ldw: Yes. It depends on what’s be tested of course, it doesn’t make sense for every test. The thinking is that if the test starts failing, something has broken in the function. (it’s not validating arguments correctly, it’s breaking a contract that it will never return NULL, etc.) |
| 10:36 |
Stompro |
Debian Wheeze has a package for pgtap 0.90 released in 2011... I wonder if that will work? I'm getting errors " ERROR: function isnt_empty(unknown, unknown) does not exist" |
| 10:37 |
ldw |
Stompro: you need to run CREATE EXTENSION pgtap; on your database. |
| 10:37 |
ldw |
I am running into issues with pgTap and Postgres 9.4. I am going to fall back to 9.1 for today. |
| 10:40 |
Stompro |
I'm just running pg_prove, "pg_prove -U evergreen -d egdb -h localhost t" |
| 10:45 |
Stompro |
Do you install the pgtap extension for just your Evergreen db, or globally, for template1? |
| 10:46 |
ldw |
Stompro: your own database |
| 10:46 |
Stompro |
Running \dx shows "pgtap | 0.90.0 | evergreen | Unit testing for PostgreSQL |
| 10:46 |
Stompro |
" |
| 10:47 |
jboyer-isl |
Stompro: I believe things added to template1 only affect databases created after template1 is changed. Existing dbs are unaffected. |
| 10:47 |
Stompro |
jboyer-isl, makes sense, thanks. |
| 10:48 |
jboyer-isl |
The answer appears to be that pgtap .90 does not include isnt_empty, only is_empty: https://github.com/theory/pgtap/blob/v0.90.0/sql/pgtap.sql.in |
| 10:48 |
jboyer-isl |
That’s unfortunate. :( |
| 10:50 |
Stompro |
I'll switch to a debian jessie test system with a newer version, thanks for finding the answer jboyer-isl++ |
| 10:50 |
Dyrcona |
Stompro: You could try installing a more recent pgtap from source, just sayin'. |
| 10:52 |
Stompro |
I know, I just want to get going on writing the tests and not mucking with building pgtap today. |
| 11:01 |
Stompro |
Sigh, no debian package for pgtap in Jessie, I guess I will be building it. |
| 11:06 |
jeff |
looks like the pgtap package in debian is not well maintained. as such, it was removed from testing back in 2013. |
| 11:06 |
* berick |
grabs 1483508 |
| 11:06 |
dbs |
http://apt.postgresql.org/pub/repos/apt/pool/main/p/pgtap/ may be an option |
| 11:07 |
csharp |
I don't mean to distract from all the test-writing awesomeness, but can someone confirm this behavior on a 2.7+ system using built-in selfcheck?... |
| 11:07 |
* jeff |
waits for csharp's question to be about usernames/barcodes |
| 11:07 |
csharp |
jeff: yep ;-) |
| 11:07 |
dbs |
but then you're into the whole "use postgresql's apt repos instead of debian/ubuntu's" thing |
| 11:08 |
csharp |
with the Patron Barcode Format YAOUS set to ^[0-9]+$, when I enter a barcode or username, it appears to accept it, but doesn't accept the password after it's typed |
| 11:08 |
dbs |
http://wiki.postgresql.org/wiki/Apt fwiw |
| 11:08 |
csharp |
the web console shows that the regex works |
| 11:08 |
csharp |
testing <barcode#> ... barcode |
| 11:08 |
berick |
did we decide we can stop adding all of the \pset boilerplate at the top of these tests, since it's not needed with pg_prove ? |
| 11:09 |
csharp |
I see the ****** (dots) appear for the password, but Enter doesn't work |
| 11:10 |
csharp |
if I remove the regex from the YAOUS, it works fine |
| 11:10 |
Stompro |
Ok, building pgtap is about as simple as installing the package... I'm going to add a note to the qa wiki page. |
| 11:59 |
|
bmills joined #evergreen |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:07 |
Stompro |
Is there a trick to pasting unicode characters into putty? I can view them fine, but I cannot copy them. |
| 12:07 |
pastebot |
"yboston" at 64.57.241.14 pasted "first pgTAP test attempt" (42 lines) at http://paste.evergreen-ils.org/24 |
| 12:08 |
yboston |
I was wndering if I could get some feedback on my first pgtap test. I am testing a function called public.first_agg from Open-ILS/src/sql/Pg/002.functions.aggregate.sql |
| 12:08 |
yboston |
LP 1483506 |
| 12:08 |
pinesol_green |
Launchpad bug 1483506 in Evergreen "public.first_agg needs test" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1483506 - Assigned to Yamil (ysuarez) |
| 12:08 |
yboston |
what file name should I use? |
| 12:10 |
berick |
yboston: file name for the test? |
| 12:10 |
yboston |
berick: yes |
| 12:11 |
yboston |
also, not sure how the actual function is being used |
| 12:11 |
berick |
yboston: something like Open-ILS/src/sql/Pg/t/lp1483506-first-agg.pg should do |
| 12:11 |
yboston |
to help me test it better |
| 12:11 |
berick |
see other examples in Open-ILS/src/sql/Pg/t/ |
| 12:11 |
yboston |
OK, was not sure if I shuld put the LP number or not |
| 12:12 |
berick |
doesn't really matter, but may as well |
| 12:13 |
yboston |
the LP bug was created for todays "test day," the LP bug does not have any significant content |
| 12:13 |
berick |
so, first_agg() is a very simple function. pass in 2 things, it returns the first one that's not NULL. if they're both null, it returns NULL |
| 12:14 |
yboston |
sorry, I meant I was havign a hard time finding it used int he code. Might have grepped wrong |
| 12:14 |
yboston |
I am not sure if I shuld be testing with more than simple data types. not sure if I should test with passing arrays(?) |
| 12:14 |
berick |
hm, don't think it is used in the code. |
| 12:14 |
berick |
see no references to it |
| 12:15 |
yboston |
berick: thanks, I feel less crazy now |
| 12:15 |
yboston |
maybe in the past it was used, but with all the cleanign that has been done it is no longer needed |
| 12:16 |
berick |
maybe |
| 12:17 |
yboston |
berick: thanks for the feedback, I feel less crazy now. |
| 12:21 |
dbs |
berick: yboston: maybe no lp number in the filename, so that we can add more tests to the same file later? |
| 12:21 |
yboston |
dbs: makes sense |
| 12:22 |
yboston |
what about file name structure, shoudl I prepend the SQL file name then add the fucntion name? |
| 12:22 |
berick |
yeah, that makes sense. perhaps we should clean up the existing ones too |
| 12:22 |
berick |
re: no lp number |
| 12:23 |
berick |
yboston: hm, i would just do the function name |
| 12:23 |
yboston |
berick: good idea |
| 12:24 |
yboston |
can we use subfolders> |
| 12:24 |
yboston |
? |
| 12:24 |
yboston |
berick: I think first_agg gets used by calls to first() |
| 12:24 |
yboston |
if so, I have more ideas of how to test it |
| 12:25 |
berick |
yes, in fact it does |
| 12:25 |
yboston |
may add a test for first() too |
| 12:25 |
berick |
good catch |
| 12:27 |
Stompro |
Hmm, evergreen.lowercase doesn't seem to handle the two turkish I's correctly. |
| 12:28 |
yboston |
so the two ideas are soemthing like 1) 002.functions.aggregate.sql_first_agg.pg 2) first_agg.pg |
| 12:30 |
ldw |
I like subfolders. But pg_prove needs to be run with --recurse for that to work. |
| 12:30 |
yboston |
berick: makes sense |
| 12:30 |
yboston |
ldw: good to know |
| 12:30 |
berick |
i mean, if we're going to use the file name, we just need to also change the test name, if we're going to include the file name in the test |
| 12:30 |
berick |
should a function move |
| 12:31 |
berick |
maybe that's very rare, not worth worrying about |
| 12:31 |
berick |
anyway, it popped in my head, and i blurted sans filter :) |
| 12:31 |
yboston |
I think we don't have to come up with a solid decision right now, I just wanted to run it by soem folks to get the cnversation started |
| 12:32 |
berick |
hm, i should add an aggregate test to my text_concat test as well |
| 12:33 |
csharp |
okay - I can confirm the same "set Patron Barcode Format setting and bork selfcheck" issue on a test server running master |
| 12:33 |
* csharp |
runs off to open the bug report |
| 12:34 |
yboston |
BTW, since pg_proves needs --recurse for subfolders to work, I will avoid using a subfolder |
| 12:34 |
yboston |
I look forward tpo having so many tests that we need to start using subfolders |
| 12:35 |
berick |
yboston++ # fixing problems before they become problems |
| 12:37 |
yboston |
berick for your feedback |
| 12:37 |
yboston |
berick++ |
| 13:53 |
dbwells |
Right, it only affects circs where there is an ungenerated fine at checkin, and the balance was zero before checkin. |
| 13:53 |
bshum |
Oh nevermind, I see you assigned yourself. |
| 13:53 |
bshum |
You're on top of it |
| 14:39 |
phasefx |
dbwells: unrelated, but in the same area, it looks like that having that lost/zero setting could prevent fines from being generated at all during checkin |
| 14:40 |
* phasefx |
hasn't actually tested that yet though |
| 14:41 |
dbwells |
phasefx: Thanks. I've got a fix for the first part (just writing a test), but I'll need to think more on that. The idea there is to purposely not generate fines if it is a lost checkin with currently zero fines, as that is what I understand the setting to mean. |
| 14:42 |
bshum |
dbwells: yeah I think that's the new setting that miker added for keeping stuff at zero. Stop gap for negative balance stuff :P |
| 14:43 |
phasefx |
dbwells: I did put some logging statements in testing the reported bug, and the handle_fines that gets called is the one inside if (!$dont_change_lost_zero) { |
| 14:44 |
* phasefx |
squints, okay, it's probably safe, since !$dont_change_lost_zero isn't just based on the setting, but looks like it considers the actual copy status, etc |
| 14:45 |
|
buzzy joined #evergreen |
| 14:45 |
dbwells |
right. It tries to just short-circuit the whole thing, and I think it's right, or at least close ;) |
| 14:53 |
bshum |
Okay... |
| 15:00 |
bshum |
Now of course, I have more users than the list i was given, but I can work with that. |
| 15:00 |
bshum |
dbwells++ # thanks! |
| 15:01 |
dbwells |
money.billable_xact is the "parent" table of action.circulation, money.grocery, and booking.reservation, so they all share a pool of ids. |
| 15:04 |
bshum |
After we remove or void those entries, part of me thinks I should do something to refresh the user summaries |
| 15:05 |
bshum |
Ah, there's a trigger on money.billing for that sort of thing, maybe... |
| 15:06 |
* bshum |
checks |
| 15:06 |
bshum |
(and tests) |
| 15:14 |
bshum |
Oh happy day. |
| 15:21 |
jboyer-isl |
Bmagic: if you are still looking into ways to relieve rsyslog congestion, look up the $ActionQueueType, $ActionQueueFileName, $SystemLogRateLimitInterval, and $SystemLogRateLimitBurst directives. |
| 15:22 |
jboyer-isl |
On a related note, fulling turning on that firehose for our database is yielding about 20%+ larger logs than letting the rate limiter eat thousands of what are likely 0ms queries. |
| 15:25 |
ldw |
jboyer-isl: I am writing negative tests, but I am using the isnt function to make sure they pass. This results in all tests passing. Does this seem reasonable to you, or is there a specific reason you had for wanting a test to fail? |
| 15:26 |
jboyer-isl |
ldw: that’s exactly what I meant. if you just run pg_prove it should say all tests pass. A test that passes because it’s expecting a function to fail still passes. :) |
| 15:26 |
ldw |
ok cool :) |
| 15:39 |
Stompro |
ldw, I'm looking at the pgtap test for change_db_setting , which calls alter database... but it looks like changes to alter database only take effect for new sessions. Which would be outside the testing transaction, so I don't think that is testable. What do you think? |
| 15:39 |
Bmagic |
jboyer-isl: thanks! for now, I am going to leave at local logging. I am afraid of bringing it all down again. Makes for an unpleasant day! |
| 15:39 |
ldw |
Stompro: you should enclose your tests in a BEGIN and ROLLBACK block, so the changes take effect for the duration of the test, but are not permanent. |
| 15:40 |
|
jlitrell joined #evergreen |
| 15:40 |
ldw |
Stompro: I see what you are saying |
| 15:40 |
ldw |
hmmm |
| 15:40 |
jeff |
evergreen.change_db_setting is involved in the search_path mess. |
| 15:40 |
Stompro |
jeff, that is the only thing it is used for that I can see. |
| 15:41 |
jeff |
i believe it is only used to change the db search_path, and potentially in a way that doesn't account for the fact that such changes are not immediate. i haven't dug into it further/recently. |
| 15:41 |
jeff |
but i remember it from my search_path digging. |
| 15:41 |
Stompro |
So I was trying to change the search path, and then show the search path, but if you want to change the search_path for the current session you use 'set' , not alter db. |
| 15:41 |
* jeff |
nods |
| 15:42 |
jeff |
if pg_tap supports disconnecting and reconnecting between test steps, that might be useful. if not, then this might not be a great function to test Right Now. |
| 15:43 |
Stompro |
But would the transaction persist across connections? |
| 15:43 |
jeff |
no. |
| 15:44 |
ldw |
could it be SELECTed from the SCHEMA instead of specifying a value to expect, specify a SQL statement? I am not sure if you can do that. |
| 15:44 |
Stompro |
and the change would rollback at the disconnect. So lets skip that one. |
| 15:45 |
Stompro |
Maybe, I'll dig and see where those values are stored. |
| 15:47 |
ldw |
Stompro: I am not sure if the second paramter from the tests can be a SQL statement. I might be wasting your time if you are digging through the schema. I am trying to see if I can get a SELECT statement to run as the second paramter. But, no luck so far. |
| 15:47 |
Stompro |
I was using results_eq Which takes a query and what the results should match. |
| 15:48 |
ldw |
you could run a \set after the alter to set a variable to the value of a select statement and use that value in your test. |
| 15:59 |
ldw |
Stompro: hmm, I cannot get \set to equal a value of a SELECT statement either. |
| 16:00 |
ldw |
Stompro: you can run a query as the first paramter to a pgTap test if it is enclosed in (). |
| 16:01 |
ldw |
So, if you know where that value is stored, you could check it that way. |
| 16:01 |
Stompro |
All I can find is the pg_settings virtual table, but that doesn't reflect changes made by alter database, since they only take effect for new connections after the change. |
| 16:08 |
ldw |
Stompro: you could try this SELECT pg_reload_conf(); |
| 16:09 |
ldw |
We need some no-op command for pgTap though |
| 16:10 |
Stompro |
pg_reload_conf cannot be run in a transaction. |
| 16:10 |
jeff |
i don't think that pg_reload_conf is what you want here. |
| 16:11 |
jeff |
``pg_reload_conf sends a SIGHUP signal to the server, causing configuration files to be reloaded by all server processes.'' |
| 16:11 |
Stompro |
Do we really need to test to make sure Alter Database works... can't we leave that to the postgresql guys. |
| 16:11 |
ldw |
Stompro: no |
| 16:11 |
ldw |
no we do not need to test it |
| 16:12 |
jeff |
i repeat my earlier: "this might not be a great function to test Right Now" :-) |
| 16:13 |
ldw |
I like to battle with the computer some days :/. |
| 16:16 |
Stompro |
jeff++, got it, I'm moving on. ldw++ thanks for the suggestions. |
| 16:23 |
|
dkyle left #evergreen |
| 16:28 |
ldw |
How should we go about including these tests in a release? |
| 16:31 |
Stompro |
From reading the pgtap docs, we could include the pgtap.sql file with Evergreen, and the tests could run during eg_db_config. |
| 16:34 |
Stompro |
Are the pgtap tests part of the current QA run? |
| 16:34 |
ldw |
Stompro: I am more thinking about the EG release process. Presumably we will have a number of tests attached to LP bugs, I should then target them to a release, but I am not sure which release. |
| 16:34 |
ldw |
Stompro: I do not know about the current QA run. |
| 16:36 |
Stompro |
A LP targeted test would be proving that the fix for that bug works, correct? So the test would need the fix applied before it would work? |
| 16:37 |
Dyrcona |
Stompro: Usually. I could also see a test that could reveal the problem before it is fixed being useful, but that could be the same thing. |
| 16:38 |
Dyrcona |
Most of the pgTAP tests I've written for LP bugs have been to make sure new indexes and fields exist after the upgrade script is run, for instance. |
| 16:40 |
ldw |
In this case though, we are writing tests for functions tha alread exist. To prevent against regression. But we still need the tests to get commited to the master branch at somepoint. Dyrcona: is a pull request enough for that? |
| 16:41 |
Dyrcona |
Yes it is. Someone will merge it, usually after running the tests, themselves. |
| 16:42 |
ldw |
Stompro: do you know how to add a pullrequest tag to LP bugs? |
| 16:42 |
Stompro |
Yep, I added it to the one that I completed today. |
| 16:42 |
ldw |
awesome. I have added one to mine as well. |
| 16:43 |
Stompro |
yboston, did you get yours done today? |
| 16:44 |
Stompro |
Just checked bug log, yes he did. |
| 16:47 |
ldw |
I have 6 tests listed with test-writing-day-0 and a pullrequest tag. Not a bad first showing. Hopefully, we can get more participation during the next one. Does a test writing day every three months sound too onerous? |
| 16:48 |
Stompro |
Not to me, that sounds just fine. |
| 16:54 |
dbwells |
ldw: I did write a test today for bug #1484989, if that counts :) Would have liked to do more. |
| 16:54 |
pinesol_green |
Launchpad bug 1484989 in Evergreen "Fines are not calculating until after circulation is closed" (affected: 1, heat: 6) [Medium,Incomplete] https://launchpad.net/bugs/1484989 |
| 16:54 |
ldw |
dbwells: that counts! Thank you. |
| 17:00 |
yboston |
lwd & Stompro there was a question earlier about running a select on the second parameter, if you mean the second param of is(), I am doing it in my test. |
| 17:01 |
yboston |
just had to wrap it in parens |
| 17:01 |
yboston |
see here... http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/t/public.first.pg;h=31941b3b21f2c69d8e3125fd6e34b8f74954d437;hb=3bcef83d5438fee4355c7eaa3ea304f271cac9b5 |
| 17:04 |
Stompro |
Thanks yboston, have a good weekend. |
| 17:10 |
|
mmorgan left #evergreen |
| 17:14 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:53 |
|
vlewis joined #evergreen |
| 18:39 |
|
mrpeters left #evergreen |
| 18:40 |
|
bmills joined #evergreen |
