| 04:59 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 07:11 |
|
BigRig_ joined #evergreen |
| 07:46 |
|
rjackson-isl joined #evergreen |
| 07:55 |
|
jboyer-isl joined #evergreen |
| 09:49 |
dbwells |
So, on Google's guide page linked above, looking at the Do/Don't "Travel stream" example, does anyone agree with Google that the raised buttons here are more "heavy" than necessary? |
| 09:50 |
dbwells |
It's about a third of the way down the page. |
| 09:50 |
|
pmurray_away joined #evergreen |
| 09:52 |
phasefx |
dbwells: I don't have a strong opinion there, but I think I'm used to what Google is doing, and I'm very adaptable. Presumably they've done actual user testing (I'd pretty much bet on it) |
| 09:52 |
dbwells |
I'm presuming that as well. |
| 09:53 |
phasefx |
I think the words being verbs and all caps invite them to be interpreted as actions |
| 09:53 |
dbwells |
But even with zillions of dollars, there is always going to be a certain subjectivity to really subtle design choices which is hard to measure, so I'm not going to go all in on Google, either :) |
| 09:55 |
phasefx |
dbwells: and also potential bureaucratic craziness/bias |
| 09:55 |
|
Shae joined #evergreen |
| 09:55 |
phasefx |
I doubt any company is purely rational and numbers driven |
| 09:55 |
jboyer-isl |
My issue with that example (took me a while to find it) is they are comparing completely flat with raised. There’s a level in between, which is just the color border, no shadow. That’s the one I’d prefer in that situation. |
| 09:56 |
jboyer-isl |
phasefx: Google may be as close as can be on that front. (Que stories about the 47 shades of blue A/B testing, etc.) |
| 09:56 |
phasefx |
mmm |
| 09:57 |
gmcharlt |
I also think we can't dismiss that firms like Google, while I do believe that they can and do more actual UX testing... are also under a marketing impetus to refresh their look periodically |
| 09:57 |
phasefx |
as opposed to Yahoo with the CEO changing colors at the last minute :) |
| 10:00 |
dbwells |
jboyer-isl: So do you think you would generally support the idea of a "lighter" button style for cases where button-ness is easily identifiable from context, but a "heavier" style when you need a button to stand out due to placement or generally screen busy-ness? |
| 10:01 |
dbwells |
That question is for everyone else too, of course. |
| 11:56 |
csharp |
hopefully we'll be closer to a browser based client by the time Windows 10 is in common usage, though |
| 11:56 |
mrpeters |
it was working fine |
| 11:56 |
bshum |
mrpeters++ |
| 11:56 |
mrpeters |
i used it for a day to test our standalone debs for Evergreen |
| 11:56 |
bshum |
Testing the future. |
| 11:56 |
mrpeters |
win 10 is going to be pretty solid i think |
| 11:56 |
mrpeters |
may get me to upgrade from win 7 |
| 11:57 |
Jake___ |
Thats great to hear |
| 12:38 |
gmcharlt |
just need somebody to contact me or bshum when they're ready to say go |
| 12:38 |
mrpeters |
i'd probably need someone to tell me when one is needed, and then i'd upload the file and let someone update the downloads page when they update the rest of the clients |
| 12:38 |
gmcharlt |
and for that matter... I'm happen to simply be sent the clients, and I can put them in place |
| 12:59 |
csharp |
gmcharlt: testing your fix now |
| 12:59 |
gmcharlt |
csharp: did you all run into the issue? |
| 12:59 |
* csharp |
recalls running into NOHEADING several months ago |
| 12:59 |
gmcharlt |
snap |
| 13:05 |
kmlussier |
#info kmlussier is Kathy Lussier, MassLNC |
| 13:05 |
gmcharlt |
:) |
| 13:06 |
kmlussier |
Small meeting? :) |
| 13:06 |
gmcharlt |
appears so... |
| 13:06 |
gmcharlt |
#topic Updates |
| 13:06 |
gmcharlt |
#action gmcharlt will install (or verify that it was installed) the libc6 fixes for the "GHOST" vulnerability today on the evergreen-ils.org boxes |
| 13:08 |
gmcharlt |
#action after ALA Midwinter, gmcharlt will get the documentation test VM provisioned |
| 13:08 |
gmcharlt |
kmlussier: any quick updates from you? |
| 13:08 |
kmlussier |
gmcharlt: No, I haven't done anything for the web site this month. |
| 13:08 |
gmcharlt |
I saw that ericar has sent out a query about updated the roster |
| 13:09 |
gmcharlt |
I believe she's on the road today, though |
| 13:28 |
kmlussier |
I would argue that since there wasn't a quorum, the meeting didn't actually take place. ;) |
| 13:28 |
csharp |
one_screenful_meetings++ |
| 13:29 |
tsbere |
kmlussier: Ah, but to discuss things we didn't need a quorum. Just to actually vote on stuff. Our decision was more along the lines of "why discuss things if we can't vote on them anyway?" :P |
| 13:29 |
csharp |
#vote ulitmate power to the web team: Yes |
| 13:30 |
csharp |
er.. ultimate power, even |
| 13:30 |
csharp |
gmcharlt: I tested your branch - signoff branch on the way |
| 13:31 |
bshum |
For fun, http://evergreen-ils.org/irc_logs/evergreen/2011-07/%23evergreen.08-Fri-2011.log was when I thought I had the shortest meeting ever for the community meetings (back when we were doing those). The timestamps put it at14 minutes. So yes, that meeting I missed was shorter :) |
| 13:31 |
bshum |
gmcharlt: Apologies for missing things, I was stuck talking while retrieving my lunch :( |
| 13:32 |
|
vlewis joined #evergreen |
| 12:06 |
pinesol_green |
[evergreen|Dan Wells] Remove unwanted index recreation - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c3c8b74> |
| 12:07 |
goood |
make that 4ffa62207 |
| 12:07 |
pinesol_green |
[evergreen|Ben Shum] LP#1253163: stamping upgrade for authority.in-line-headings - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=4ffa622> |
| 12:09 |
bshum |
Honestly, I don't remember what I was testing that day when I merged that. Wasn't that related to the PG 9.3 weirdness and function breakage? |
| 12:11 |
|
jihpringle joined #evergreen |
| 12:11 |
bshum |
Wait, I'm confused by those two commits you linked now. |
| 12:11 |
bshum |
Are you saying the index should be there or shouldn't be there? |
| 12:11 |
pastebot |
"Dyrcona" at 64.57.241.14 pasted "MVLC WWW diff with master" (40 lines) at http://paste.evergreen-ils.org/27 |
| 12:12 |
bshum |
Dyrcona: That doesn't look too unusual to me. |
| 12:18 |
bshum |
Or to put it another way, what did I break now? 10+ months later :( |
| 12:41 |
goood |
berick: thanks. are there any instructions for installing on windows or mac? |
| 12:45 |
berick |
goood: no instructions. same concepts for both, though, just different commands |
| 13:03 |
|
bmills joined #evergreen |
| 13:05 |
csharp |
goood: I'm attempting to apply the fix for bug 1414112 on a test server and getting this error: http://pastie.org/9865951 ... it looks like it should work, though :-/ |
| 13:05 |
pinesol_green |
Launchpad bug 1414112 in Evergreen 2.7 "Audience filter no longer searching blank spaces" (affected: 2, heat: 12) [Medium,Confirmed] https://launchpad.net/bugs/1414112 |
| 13:09 |
Dyrcona |
berick: After comparing notes wth bshum, I really think it is something under EGCatloader, probably doing xact_begin followed by xact_commit or xact_rollback, but no disconnect. |
| 13:09 |
Dyrcona |
He sees the messages in his logs, also, just not as many. |
| 13:19 |
csharp |
Dyrcona++ |
| 13:23 |
dbwells |
Hey all. Just a quick double-check: is PG 9.1 still the minimum version for EG 2.7? |
| 13:23 |
csharp |
dbwells: from my understanding, 9.1 has not been deprecated yet for any EG version |
| 13:24 |
bshum |
dbwells: PG 9.1 is the minimum version, but personally I only tested with PG 9.3 and recommend that to everyone who goes up to EG 2.7 :) |
| 13:24 |
dbwells |
csharp++ Thanks. I thought that to be true, but didn't want to find out mid-upgrade that I was wrong :) |
| 13:25 |
csharp |
dbwells: I'll mention that we're on 9.3, so I can speak from experience upgrading to 2.7 on 9.1 ;-) |
| 13:25 |
dbwells |
bshum: That's probably good advice, but my upgrade window is a little tight this time around. We'll get there eventually. |
| 15:12 |
Stompro |
Wireshark says it is trying to use tls1.0, which is enabled, so maybe the problem is with the ciphers enabled. Apache logs show nothing so it is't getting past the ssl negotiation phase. |
| 15:12 |
dbs |
Stompro: umm. works pretty great for me |
| 15:12 |
dbs |
https://www.ssllabs.com/ssltest/analyze.html?d=laurentian.concat.ca&latest anyways |
| 15:13 |
Stompro |
dbs: would you mind sharing your SSLCipherSuite line? I also just loaded a non self signed cert.. I should probably not change too many things at once before testing :) |
| 15:13 |
* dbs |
using https://wiki.mozilla.org/Security/Server_Side_TLS (intermediate support) |
| 15:14 |
|
Shae joined #evergreen |
| 15:14 |
dbs |
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-R |
| 15:14 |
jeff |
Stompro: i'd be interested in your config and in your failure mode / errors, but purely for selfish reasons -- i'd like to know how it can break. doesn't help you fix it right now. |
| 15:14 |
Stompro |
Firefox can connect just fine to the catalog... just not the staff client. |
| 15:14 |
* dbs |
also redirecting everything from HTTP to HTTPS |
| 15:19 |
Stompro |
jeff: The error mode is that the server status check fails with a red "There was an error testing this hostname". The other issue that could be related is that the cert is so new that the OCSP info hasn't been updated, so maybe the staff client is trying to validate the cert against the OCSP list and failing because of that? |
| 15:19 |
Stompro |
And it has nothing to do with the cipher suites. |
| 15:19 |
jeff |
What OCSP issue do you think you're running into? |
| 15:22 |
Stompro |
I think I was supposed to wait an hour or two before using the new cert for the OCSP info to get added. I think a negative reply is cached now on the OCSP server so I have to wait for 24 hours for it to time out. ssllabs does give me an "OCSP ERROR" so they are seeing it also. |
| 16:40 |
Dyrcona |
We got two feet plus, all right. |
| 16:52 |
Dyrcona |
Well, I'm signing off. |
| 16:53 |
Dyrcona |
TTYL, #evergreen! |
| 17:17 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:21 |
gmcharlt |
goood: bug 1415234 |
| 17:21 |
pinesol_green |
Launchpad bug 1415234 in Evergreen "uncontrolled attribute values that consistent only of spaces are normalized away" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1415234 |
| 21:26 |
|
csharp joined #evergreen |
| 09:00 |
pinesol_green |
Launchpad bug 1386347 in Evergreen 2.6 "Speed up hold copy map deletion for clear shelf process, etc." (affected: 1, heat: 6) [Undecided,New] |
| 09:05 |
csharp |
dbs: or eeevil: for bug 1206936, does the suggested change in comment #7 supercede my "use window functions" branch and solve the original problem? |
| 09:05 |
pinesol_green |
Launchpad bug 1206936 in Evergreen "money.transaction_billing_summary view displays incorrect billing_type and billing_note for the actual last transaction" (affected: 1, heat: 6) [High,Triaged] https://launchpad.net/bugs/1206936 |
| 09:05 |
* csharp |
hasn't tested, jsyk |
| 09:07 |
tsbere |
jeff: Regarding differences in default notification formats: TPac (pipe, prefers email, then phone, then sms) vs old JSPac entries (dunno) vs Patron Editor (colon, prefers phone, then email, then sms) |
| 09:10 |
jeff |
tsbere: thanks. i had suspected as such, and started to compare new/old patron editors vs tpac -- thought i saw in tpac that it was colon-delimited, just with a different order. guess i'll have to re-look. |
| 09:14 |
bshum |
csharp: On bug 1386347, I was leaning towards removing the milestone from that, since nobody seems to be championing it for backport presently. |
| 14:00 |
pinesol_green |
[sipserver|Thomas Berezansky] LP#1227273: Clear account info at start and end of connection - <http://git.evergreen-ils.org/?p=SIPServer.git;a=commit;h=cd45513> |
| 14:01 |
bshum |
That's the last commit our SIPServer is up to running apparently. |
| 14:01 |
bshum |
It was before the timeout stuff and the multiplex stuff |
| 14:25 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 14:46 |
Stompro |
Is creating read only postgres access really as difficult as it seems to be? Needing to run a command for every schema individually? |
| 14:50 |
bshum |
Stompro: I believe that's how we had to do it in the past. |
| 14:50 |
bshum |
And actually I think we even went further and specified it table by table in some cases. |
| 15:28 |
kmlussier |
bshum: It shouldn't take me long to look at it again. The problem is all of the other stuff I have on my plate today. |
| 15:30 |
kmlussier |
But if you wait until tomorrow, I can also look at that Lost and Paid bug too. |
| 15:31 |
Dyrcona |
kmlussier: I've loaded the branch on my dev system already, so feel free to toggle settings on there if you want. |
| 15:31 |
dbwells |
kmlussier: rats, sorry. Probably a merge error I made of some kind when getting it into the branch. I loaded the branch earlier on my test box, but haven't gotten back to it yet. I'll get it fixed. |
| 15:31 |
Dyrcona |
The lost and paid fix branch, that is. |
| 15:31 |
kmlussier |
dbwells++ Great, thanks! |
| 15:32 |
bshum |
kmlussier: That's fine, I can wait to cut tomorrow. |
| 15:41 |
bshum |
Damn, missed the # in the previous commits |
| 15:41 |
jeff |
but not as many wasted characters as LP#number - Commit description here |
| 15:41 |
bshum |
I need to finish poking at the ilbot config |
| 15:43 |
Dyrcona |
I need to test phasefx_'s marc_export changes. Probably won't get to it today. |
| 15:44 |
Dyrcona |
They won't go into 2.7 anyway. |
| 15:48 |
pinesol_green |
[evergreen|Bill Erickson] LP#1407171 Avoid DEFLATEing fm_IDL.xml - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=112b270> |
| 15:50 |
pinesol_green |
[evergreen|Ben Shum] LP#1373594: Also ignore subfield 7 in get_graphics_880s - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67999a6> |
| 15:57 |
bshum |
It's cause that's already the default, but should we keep that in the help info for people who might have it live elsewhere for some reason? |
| 16:12 |
|
mrpeters left #evergreen |
| 16:12 |
|
mrpeters joined #evergreen |
| 16:14 |
dbwells |
kmlussier: Dyrcona: I missed one added and two deleted lines in my merging (or unmerging, as the case may be). It seems happier now at my end, so I force pushed over the same branch (collab/dbwells/1198465_cstore_fines_gen). Thanks for the early testing! |
| 16:14 |
kmlussier |
dbwells++ |
| 16:18 |
Dyrcona |
kmlussier: I can load the revised branch if you want to look at it tomorrow. |
| 16:18 |
remingtron |
bshum: I think the help info should be enough as is, since the config setting is the first option listed. But I don't have strong feelings either way. |
| 16:30 |
bshum |
Dyrcona: Most of the things I end up pushing to 2.7 tend to be either tiny or broken things. I usually save dbwells the trouble of pushing it to rel_2_6 on his behalf, but I could change that if he'd prefer to push it himself :) |
| 16:31 |
kmlussier |
Dyrcona++ Thank you! |
| 16:31 |
jeff |
bshum: so trying to install debian-wheezy-packager target after installing debian-wheezy-developer results in an error because it tries to clone the node git repo a second time. |
| 16:31 |
bshum |
If it was me, I wouldn't hold off on backporting if it's indeed a bug fix. |
| 16:32 |
bshum |
jeff: Ahh..... I primarily tested the Ubuntu side of things, and those are all packages. |
| 16:32 |
bshum |
So it doesn't usually clobber itself, it'll just add whatever packages it's still missing. |
| 16:32 |
* jeff |
nods |
| 16:32 |
bshum |
jeff++ # may want to file that a new bug then for 2.8 series. |
| 16:33 |
bshum |
Darn Wheezy |
| 16:44 |
bshum |
Hmm |
| 16:45 |
bshum |
Maybe like the install_libdbi thing before install_nodejs_from_source |
| 16:45 |
bshum |
Where we look for the folder, if not present, get it, etc. |
| 16:45 |
dbwells |
I think whoever does the testing should go ahead and push to all applicable branches. The fact that bshum is an RM and also tests a bunch of things just confuses the situation ;) |
| 16:46 |
* bshum |
either has lots of hats or lots of heads. |
| 16:46 |
bshum |
Possibly both. |
| 16:47 |
bshum |
jeff: That's of course all from Makefile.common I'm curiously looking at. |
| 16:55 |
Dyrcona |
I'll just build a new vm on Saturday or Monday. |
| 16:55 |
kmlussier |
Dyrcona: Thanks for trying! |
| 16:55 |
* kmlussier |
calls it a day |
| 16:56 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:01 |
berick |
tsbere: re: bug 1413624, if you hope to get it merged into 2.8, go ahead and target 2.8-beta |
| 17:01 |
pinesol_green |
Launchpad bug 1413624 in Evergreen "New AccessHandler Module" (affected: 1, heat: 8) [Undecided,New] https://launchpad.net/bugs/1413624 |
| 17:02 |
eeevil |
dbwells: I've been terribly remiss in not looking at your cstore-fine-gen code ... I'm wondering what the reason for that is? (the use of cstore instead of dbi in the storage app, in particular) ... but, I think I've found a problem in any case. it looks like penalty calculation is being called before the cstore->commit is called |
| 10:31 |
wsmoak |
this is a fairly fresh Yosemite install, and I haven't customized FF at all |
| 10:33 |
wsmoak |
will be interesting to see what another osx user sees. Norton might be to blame, it sticks its nose where it isn't wanted all the time. |
| 10:34 |
wsmoak |
anyway... the search works fine now that I know what I'm looking at. :) minor issue. |
| 10:48 |
dbs |
http://i.imgur.com/dbmZDa9.png is what mine looks like |
| 10:48 |
dbs |
(highlighting PINES obscures the icon sadly, oh well) |
| 10:53 |
|
julialima_ joined #evergreen |
| 10:54 |
* dbs |
wonders idly why Browse catalog by title works in one library in our instance but not in another |
| 10:54 |
dbs |
(returns a server 500 error, yikes) |
| 10:58 |
* dbs |
peers at egweb: Context Loader error: Can't use an undefined value as a HASH reference at WWW/EGCatLoader/Browse.pm line 271. |
| 11:00 |
dbs |
suggests its a database error, and the there's no $self->editor->event member that was returned I guess. |
| 11:03 |
* dbs |
opts to stop testing defensive code in production after making every page request return 500 :) |
| 11:21 |
|
yboston joined #evergreen |
| 12:00 |
|
Dyrcona joined #evergreen |
| 12:09 |
dbs |
my defensive code is simply offensive |
| 12:12 |
dbs |
even weirder, that browse works on our test instance where we haven't reingested all of the records. hrm. |
| 12:18 |
|
jihpringle joined #evergreen |
| 12:23 |
eeevil |
dbs: any chance the osrf translator memcache instance is misconfigured in the apache configs? I've seen that break browse and just a couple other things in the past. A/T event def editor would also break, for instance |
| 12:24 |
dbs |
eeevil: definitely possible |
| 12:37 |
Dyrcona |
But then, I'm "off" today. |
| 12:38 |
|
sandbergja joined #evergreen |
| 12:47 |
julialima_ |
Hello evergreeners!!! The web client is not working, at least for me. In the patron search I can´t perform any search, I have no feedback so I don´t know what is going on. Anyone know if there is a problem? |
| 12:47 |
bshum |
Dyrcona: I've seen that too actually. |
| 12:47 |
bshum |
Also "off" :) |
| 12:51 |
bshum |
julialima_: I'm probably not the best person to answer you (I'm not sure how many folks have off today in the US). Anywho, which server are you using to test with? |
| 12:52 |
dbwells |
julialima_: Some folks might be at lunch, which is where I am headed. Also, just to clarify, are you talking about webby.evergreencatalog.com, or some other test site? |
| 12:52 |
bshum |
Maybe there might be a hint in the browser console |
| 12:53 |
gmcharlt |
julialima_: try webby now; I've restarted services there and it's now working for me |
| 12:54 |
julialima_ |
gmcharlt: It is working now, thank you very much! :) |
| 07:34 |
|
sarabee joined #evergreen |
| 07:53 |
|
ericar joined #evergreen |
| 08:06 |
|
_bott_ joined #evergreen |
| 08:15 |
kmlussier |
eeevil: I'll see if I can get some end user testing here on webby for those web client fixes. |
| 08:26 |
|
rjackson-isl joined #evergreen |
| 08:31 |
|
Shae joined #evergreen |
| 08:34 |
|
abowling joined #evergreen |
| 10:20 |
* csharp |
laughs evilly |
| 10:20 |
jboyer-isl |
It's particularly fun to use cores-1, provided it has the RAM to pull it off. |
| 10:20 |
csharp |
jboyer-isl: daredevil! |
| 10:21 |
jboyer-isl |
I like to test ACID compliance, keep postmaster on it's toes, etc. :D |
| 10:21 |
* berick |
waits for a 'top' screenshot |
| 10:22 |
csharp |
ERROR: not enough room on screen |
| 10:22 |
berick |
says it all |
| 12:09 |
dbs |
We are still using scripts though! Which is always fun. |
| 12:09 |
|
julialima_ joined #evergreen |
| 12:16 |
|
mtcarlson joined #evergreen |
| 12:39 |
kmlussier |
berick/eeevil: For commit b577d39, is there a specific bug with dates being fixed that we should be testing for? |
| 12:39 |
kmlussier |
Hmm...I thought that would bring up the commit if I typed it that way. |
| 12:39 |
|
buzzy joined #evergreen |
| 12:39 |
berick |
kmlussier: it's not a bug |
| 12:39 |
berick |
it's part of the noncat circ display |
| 13:41 |
mrpeters |
what is current reccomended xulrunner for 2.72? (building a mac client) |
| 13:45 |
berick |
mrpeters: 14.0.1 |
| 13:45 |
mrpeters |
thanks berick! |
| 13:45 |
eeevil |
kmlussier++ # testing! :) |
| 13:57 |
|
nhilton_ joined #evergreen |
| 13:59 |
|
Sally joined #evergreen |
| 14:21 |
dbs |
julialima++ # great stuff |
| 14:45 |
Dyrcona |
kmlussier: OK. I likely haven't read that one yet. |
| 14:47 |
jeff |
kmlussier: thanks for calling that out. i've been reading that thread but apparently am not current. |
| 14:49 |
|
nhilton joined #evergreen |
| 14:52 |
kmlussier |
eeevil / berick: If you're still around, there were 4 bug fixes mentioned in Mike's most recent bug repairs comment that I was unsure on what to test for. http://pastebin.com/r21hv2ke |
| 14:53 |
kmlussier |
Some may be related to other fixes to be tested there, but I just want to make sure I'm not missing anything. |
| 14:53 |
berick |
kmlussier: for "Repair browser client dropdown buttons" -- it's an issue that would only appear on a fairly new server |
| 14:54 |
|
mrpeters left #evergreen |
| 14:54 |
berick |
in the grids, the Actions drop-down buttons don't work w/o the patch |
| 14:54 |
berick |
making sure they still work on older servers would be helpful, thoug |
| 14:54 |
berick |
h |
| 14:54 |
kmlussier |
berick: Ok. So the 1st isn't something I can really test for on webby? |
| 14:55 |
berick |
checking Actions dropdowns in Webby to make sure the change didn't introduce a problem would be good |
| 14:55 |
kmlussier |
berick: Sure, that we can do. :) |
| 14:55 |
berick |
kmlussier: for "Avoid org tree retrieval race condition on patron app" -- without this patch, pages would sometimes fail to load with a JS error. if you never saw the problem before, it's not really testable, apart from "hey, pages load!" |
| 09:37 |
|
RoganH joined #evergreen |
| 09:42 |
|
mllewellyn joined #evergreen |
| 09:44 |
|
BigRig joined #evergreen |
| 09:52 |
berick |
eeevil: ideally w/ an LP listing what to test. i'm happy to review, test, sign-off |
| 09:53 |
eeevil |
berick: you mean you want an lp bug for each bug/fix, or a listing of what's fixed on one bug |
| 09:53 |
berick |
i think one bug is fine |
| 09:57 |
eeevil |
k |
| 10:37 |
jboyer-isl |
It depends on how much (and how directly) misc_util is pulled into a module. I'm probably not giving it the necessary level of thought myself. (I came across that bug while looking for another bug that I apparently never filed) |
| 10:40 |
jboyer-isl |
display fields would probably take care of any potential issues I have with misc_util going away, I was just thinking of all of the hard-coded tags and fields from that file being pulled behind the scenes, which I suppose isn't really the intent. |
| 11:34 |
|
RoganH_ joined #evergreen |
| 11:37 |
abowling |
i'm trying to test changes on the place_hold.js script that affects the place_hold.xul template. i clear my cache, restart apache, and restart services, but it seemingly has no effect. i looked to see if the javascript exists on my local machine, and it doesn't. any ideas? |
| 11:40 |
bshum |
abowling: So to be clear, you're making changes to that file in the server side installed version? |
| 11:40 |
bshum |
Somewhere in /openils/var/web/xul/server/... |
| 11:40 |
abowling |
bshum: yes. |
| 11:42 |
bshum |
Are you sure that the staff client version of your client is matching to where server links to for the files server-side? |
| 11:42 |
abowling |
didn't think i'd need to restart apache. just making sure it wasn't cached on the server somewhere. |
| 11:43 |
bshum |
Or did you try editing the specific version's installed folder content |
| 11:43 |
abowling |
bshum: yes. it's the EDN master we use for testing. |
| 11:43 |
bshum |
Well, it sounds like you got all your bases covered to me. Maybe the change you're expecting to happen isn't happening. |
| 11:44 |
abowling |
bshum: i'm editing the specific installed version file, fwiw |
| 11:44 |
abowling |
it's confounding |
| 11:45 |
bshum |
patron? |
| 11:45 |
bshum |
Hmm |
| 11:45 |
bshum |
Oh right |
| 11:45 |
abowling |
bshum: just for testing, i've commented out this line just for a simple test: |
| 11:45 |
abowling |
//$('hold_usr_textbox').value = au_obj.card().barcode(); |
| 11:45 |
bshum |
My mind's not on XUL stuff :) |
| 11:46 |
abowling |
understood. i'm pretty good with the perlmods and OPAC, but my XUL history is limited, and that's understating it |
| 11:47 |
abowling |
upon restarting the staff client, $('hold_usr_textbox') is still getting a value set |
| 12:09 |
bshum |
berick: Right, I know |
| 12:09 |
jeff |
abowling: worth noting that your apache log line is NOT requesting the javascript file you stated you were editing. |
| 12:10 |
bshum |
If so, he's probably looking for /openils/var/template/opac/place_hold.tt2 (or ../parts/place_hold.tt2 actually) |
| 12:10 |
abowling |
i'm pulling up test records, clicking "Place Hold", and then selecting "Advanced Options" |
| 12:10 |
jeff |
abowling: i think you want to be looking at /openils/var/web/opac/skin/default/js/holds.js and such. |
| 12:10 |
abowling |
bshum: that now seems likley |
| 12:10 |
bshum |
Ah, yeah, wrong place. |
| 16:03 |
rangi |
they do 2 weeks, first week is learning |
| 16:03 |
rangi |
2nd week is project work |
| 16:04 |
rangi |
its been Koha, Drupal, Mahara, Silverstripe and Piwik |
| 16:09 |
* jeff |
returns from digging |
| 16:10 |
jeff |
vandelay functions were in a bad state on my test instance. |
| 16:10 |
Dyrcona |
rangi: Cool. |
| 16:10 |
jeff |
fixed, all's well. |
| 16:11 |
jeff |
and this is a good reminder that i need to do some more research with regard to better ways to schema-only diff postgres databases :-) |
| 14:19 |
gmcharlt |
ok, hearing no questions, moving on |
| 14:19 |
gmcharlt |
#topic New business - quality assurance |
| 14:19 |
gmcharlt |
kmlussier? |
| 14:20 |
kmlussier |
Sure. The folks at MassLNC were revisiting the QA report done a little over a year ago. |
| 14:21 |
kmlussier |
Since the report was issued, the community has come together to agree to do PGTap tests. But there are other recommendations that haven't been implemented yet. |
| 14:21 |
kmlussier |
So I thought it would be good to start a discussion among all of you to get a sense of what you think is needed to implement some of those other recommendations. |
| 14:22 |
jeff |
especially relevant since we're looking at a soon-to-be era where xulrunner is no more for Evergreen: ``there may be areas where improvements will be limited until Evergreen moves away from XULRunner'' |
| 14:23 |
kmlussier |
jeff: Are you thinking testing will become easier when we are off XULRunner? |
| 14:24 |
dbs |
Even on the PGTap side of things, we haven't really kept up with our commitment to add tests as we change the SQL |
| 14:24 |
jeff |
I was just quoting the part of the report that asserted (now I'm paraphrasing) that a move away from xulrunner would open the door for more improvements to QA and testing. |
| 14:25 |
bshum |
So, I admittedly haven't read the full report in awhile, but I'm not seeing any specific approaches being suggested. So the question on the floor is whether we would like to plan on finding some specifics and applying them towards say, the web client (as it's being created) |
| 14:25 |
kmlussier |
Is part of the issue the fact that we don't have people with the expertise and/or time to take charge of QA? |
| 14:26 |
eeevil |
kmlussier: I think that's The(tm) perpetual challenge ;) |
| 14:26 |
gmcharlt |
time in particular |
| 14:26 |
dbs |
But we kind of don't have the time to not do QA either |
| 14:27 |
gmcharlt |
also true |
| 14:27 |
kmlussier |
I also think testing goes beyond the client. For example, there were recommendations for a test suite to test for performance, for example. |
| 14:27 |
dbs |
Lacking at least one person with expertise + time, though, yeah, it's a problem. |
| 14:28 |
kmlussier |
So, I know there are people in the community who would be willing to put resources into bringing on a person to manage that process if it were needed. |
| 14:29 |
kmlussier |
First, I think it would be good to know if that is, indeed, what is needed. |
| 14:29 |
kmlussier |
Also, I didn't know if it would be worthwhile to look at other projects to see how QA is done. And, then, maybe pull the best from those projects to see what would work best for Evergreen. |
| 14:30 |
jeffdavis |
What would "bringing on a person" entail? |
| 14:30 |
berick |
well, there are some things we already have a good handle on (e.g. pgtap tests, perl unit tests, perl live tests). for those types of things, i think we just have to make ourselves do it. |
| 14:31 |
berick |
there's a lot we could do we're just not doing. |
| 14:31 |
dbs |
amen |
| 14:31 |
kmlussier |
berick: Does everyone contributing code have a good handle on that? |
| 14:31 |
berick |
having someone whose job it is to think about it for big picture stuff would be great, but we shouldn't let that slow us down |
| 14:32 |
jeff |
berick: during sprint 1 of the web client, you had some unit tests in place (correct me if i'm wrong) -- could you hazard a guess as to what percentage of interfaces have unit tests? |
| 14:32 |
berick |
kmlussier: well, no, because we don't do it regularly enough for everyone of have templates to work from |
| 14:32 |
gmcharlt |
a somewhat stricter attitude about requiring pgTap tests and Perl unit tests to accompany patches would be a step forward for the 2.8 cycle |
| 14:32 |
berick |
jeff: those unit tests were almost entirely focused on the services (i.e. the stuff under the interfaces) |
| 14:33 |
berick |
jeff: so, very little UI coverage |
| 14:33 |
berick |
gmcharlt: agreed |
| 14:34 |
jeff |
berick: got it. thanks. |
| 14:35 |
phasefx |
jfyi, one notion I encountered was to not focus on testing "services" through the UI, but the test the UI itself (widgets, etc.) if testing the UI, and test the services more closely to where they live if testing the services |
| 14:35 |
kmlussier |
I think my group would be in favor of stricter requirements for tests and whatever else you can do now. |
| 14:35 |
gmcharlt |
as far as I'm concerned personally, providing pgTap + perl tests for the stuff I'm slated to do for 2.8 is easy enough |
| 14:36 |
kmlussier |
But if the developers, as a group, told me, "we really need somebody to manage this process," I would do what I could to make that happen. |
| 14:37 |
dbs |
I imagine the developers are trying to imagine how such a person dropped into our midst could actually manage the process. |
| 14:37 |
kmlussier |
I'm mostly concerned that there is still more testing beyond pgTap and perl tests that we need to be doing. |
| 14:37 |
dbs |
Buy-in would be tough. |
| 14:38 |
jeff |
I consider myself a novice with regard to Perl tests, and moreso with regard to pgTap tests. I'd be willing to extract knowledge and experience from others and formulate something of a reference / set of guidelines for contributors in the hope that it would help myself and others include appropriate tests in contributions. |
| 14:38 |
gmcharlt |
on the other hand -- somebody who had an explicit committment to review patches (and who could come up the speed) might be an easier dose of medicine, as it were |
| 14:38 |
kmlussier |
Yes, well, that's why I'm raising the questions here. |
| 14:39 |
* dbs |
would like to automatically test the TPAC for basic accessibility compliance, ensuring RDFa comes out right, ensuring data is displayed as expected (which would be hella useful if we move misc_util.tt2 into Perl module land) |
| 14:39 |
jeff |
dbs++ good job putting words to what I was thinking ("dropped into our midst" comment above) |
| 14:40 |
kmlussier |
Well, any new developer is essentially "dropped into our midst," right? |
| 14:40 |
berick |
jeff: i'd be happy to help review/edit any such guidlines |
| 14:40 |
dbs |
Unfortunately most of those tests would require python for RDFLib and I'm not keen on introducing more dependencies |
| 14:40 |
gmcharlt |
dbs: does that translate to "you are willing to help set up such testing"? I'd be happy to collaborate with you on that |
| 14:41 |
jeff |
berick++ sounds good. |
| 14:41 |
dbs |
kmlussier: yes, but the mindset is often such that a new developer == "yay they're helping build this thing" vs "this person is getting in the way" |
| 14:41 |
gmcharlt |
vs "this stranger is TELLING US WHAT TO DO. OH NOES!" |
| 14:43 |
berick |
i would welcome someone whose job it was to research and present ideas, proofs-of-concept, etc. on QA stuff. |
| 14:43 |
berick |
"manage" and "take charge" may not be the right words |
| 14:43 |
berick |
"drive" maybe |
| 14:43 |
jeff |
berick: as 2.8 RM how do you feel about gmcharlt's proposal of "a somewhat stricter attitude about requiring" tests? |
| 14:43 |
dbs |
"Hey, look at what you can do with a few lines of additional code" |
| 14:43 |
kmlussier |
Yes, "drive" is a good word. :) As gmcharlt said, somebody with an explicit commitment. |
| 14:44 |
gmcharlt |
berick: and "review patches"... I really think it does need to be grounded |
| 14:44 |
berick |
jeff: +1 from me for bumping to strictness level 2 |
| 14:44 |
berick |
gmcharlt: ah, yes, that would ideal |
| 14:45 |
jeff |
gmcharlt: am i correct in thinking that koha has an explicit "QA" signoff? Is that a mostly automatic (tests passed!) signoff, or is that a human signing off with a specific eye toward QA? |
| 14:46 |
jeff |
(deja vu -- i may have asked this question before) |
| 14:46 |
gmcharlt |
jeff: the Koha process seeks two signoffs |
| 14:46 |
gmcharlt |
1st signoff is from essentially anybody who can install the patch and run it through its paces |
| 14:47 |
dbs |
#link One accessibility checking API: http://wave.webaim.org/api/ (costs $$$ but it's an option) |
| 14:47 |
gmcharlt |
the 2nd, QA signoff is based on an inspection by a human member of the QA team + the patches passing a set of extra, mostly static source-code level tests |
| 14:47 |
berick |
as far as 2.8 goes, we'll need some guidelines for building tests, what the minimal requirements are. I can build/collaborate on that. i'll obviously need input, though. |
| 14:47 |
berick |
and since it's late in the game, we'll have to be pretty forgiving |
| 14:48 |
jeff |
sure. nobody's proposing FESTIVITY^WSTRICTNESS LEVEL 4. |
| 14:49 |
gmcharlt |
so we have, to sum up, the following concrete suggestions at th emoment |
| 14:49 |
gmcharlt |
1. incrementing the strictness level |
| 14:49 |
gmcharlt |
2. berick et al writing up some guidelines and templates for pgTAP and perl unit tests |
| 14:49 |
gmcharlt |
3. dbs and galen putting together some automatic testing of TPAC and RDFa output |
| 14:50 |
gmcharlt |
and less concretely, some fuzzy input on desiderata for a "QA person" |
| 14:50 |
dbs |
#link another accessibility checking API: https://github.com/inclusive-design/AChecker (GPL v2) |
| 14:50 |
* gmcharlt |
has used AChecker in the past, FWIW |
| 14:51 |
kmlussier |
gmcharlt: Would it be helpful if someone (I can volunteer) do an environmental scan of other projects and who they handle these issues? |
| 14:52 |
gmcharlt |
kmlussier: I haz thoughts on the matter and would be interested in working with you on it |
| 14:53 |
kmlussier |
jeff: The who is part of it, but the overall process too. |
| 14:53 |
kmlussier |
gmcharlt: Thanks! |
| 14:55 |
gmcharlt |
so, just to double-check -- are folks (particularly committers) OK with stricter enforcement of providing pgTAP & perl unit tests for the 2.8 cycle? |
| 14:55 |
eeevil |
may I as that followups happen on the -dev list? (rather than -general, not to exclude folks, but to avoid pulling in -dev help) |
| 14:55 |
eeevil |
the kmlussier + gmcharlt + dbs + berick + others followups, I mean |
| 14:56 |
kmlussier |
eeevil: That's fine with me |
| 14:56 |
gmcharlt |
agreed |
| 14:56 |
jeff |
It will make some things harder, but those things may well be the things that would most benefit from unit tests. |
| 14:57 |
jeff |
(or pgTAP tests) |
| 14:57 |
eeevil |
gmcharlt: for my part (re agreement), yes, where applicable and reasonable (that is, not useless for lack of context), stricter enforcement of tests |
| 14:57 |
* eeevil |
does not plan to write tests that require a mock env that emulates all of Evergreen ... fwiw ;) |
| 14:57 |
gmcharlt |
eeevil: indeed - I can point to some examples in recent memory of cases where some testing-for-the-sake-of-following-the-rules was in play |
| 14:58 |
jeff |
eeevil: I don't think that any of our employers have enough time that tests for the sole sake of tests will be a common thing. :-) |
| 14:58 |
phasefx |
are we excluding or including integration tests here against live test systems? |
| 14:58 |
gmcharlt |
but I will emphasize that at the moment, Evergreen is in no danger of that! |
| 14:58 |
eeevil |
gmcharlt: fair ;) |
| 14:58 |
berick |
phasefx: I was hoping to encourage the use of live tests for changes that can't be tested in a vacuum, if that's what you're asking |
| 14:58 |
gmcharlt |
OK, I'm going to summarize, then move on to the next agenda item |
| 14:59 |
phasefx |
berick: sounds good to me, and I just saw eeevil's desire not to build huge mock environments :) |
| 14:59 |
gmcharlt |
#item There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests |
| 14:59 |
gmcharlt |
#info There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests |
| 14:59 |
gmcharlt |
#info berick will write some guidelines on writing Perl and pgTAP tests |
| 15:00 |
gmcharlt |
#info dbs and gmcharlt will work on automating accessibility and RDFa tests of TPAC |
| 15:00 |
jeff |
berick: see what i did there, how that turned from you reviewing/editing to writing those from scratch? ;-) |
| 15:00 |
gmcharlt |
#info kmlussier will do an environement scan of QA practices and experts in other project, with help from gmcharlt and others |
| 15:00 |
* jeff |
ducks |
| 15:21 |
gmcharlt |
#topic Negative blances / billing improvements |
| 15:21 |
gmcharlt |
#link https://bugs.launchpad.net/evergreen/+bug/1198465 |
| 15:21 |
pinesol_green |
Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 66) [Wishlist,Confirmed] |
| 15:21 |
dbwells |
I'm already late for another meeting, so I'll make this quick. |
| 15:21 |
dbwells |
Basically, I'm just fishing for help in testing some or all of the billing changes which have grown on that bug. |
| 15:22 |
dbwells |
As I stated in the agenda, I think separating out the root-level stuff and getting that tested/committed first would be a good strategy. Any takers for testing? |
| 15:22 |
berick |
dbwells: +1 to the idea of breaking out cstore billing to its own LP. I would help poke at that. |
| 15:22 |
jeff |
I'm interested in testing. |
| 15:22 |
berick |
it's much more digestable... |
| 15:22 |
kmlussier |
I'm interested in testing too. |
| 15:22 |
dbwells |
sweet, thanks all |
| 15:22 |
jeff |
I hate to ask, but... are there tests in the root-level stuff at this point in time? |
| 15:23 |
dbwells |
I've been working this morning on getting the cstore stuff separated, it wasn't too bad. |
| 15:23 |
dbwells |
jeff: Only in that it doesn't (or mightn't) break the existing billing tests. |
| 15:24 |
dbwells |
At least that portion isn't meant to do anything new. Not that we couldn't always use more tests, of course. |
| 15:24 |
jeff |
In some ways, that's enough! Always nice when there are existing relevant tests. :-) |
| 15:24 |
gmcharlt |
#action dbwells will separate the cstore billing code into a separate bug; jeff and berick will help with testing |
| 15:25 |
gmcharlt |
and I suggest follow-up to open-ils-dev |
| 15:25 |
dbwells |
I am out for now. Thanks again to those who volunteered; expect to be bugged by me soon. |
| 15:25 |
jeff |
dbwells++ |
| 15:26 |
kmlussier |
dbwells++ |
| 16:59 |
|
berick joined #evergreen |
| 16:59 |
|
Bmagic joined #evergreen |
| 16:59 |
bshum |
Calling 0903 |
| 17:03 |
pinesol_green |
Showing latest 5 of 6 commits to Evergreen... |
| 17:03 |
pinesol_green |
[evergreen|Jason Stephenson] LP#980296: Add void of lost processing fee on claims returned. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=806ecaa> |
| 17:03 |
pinesol_green |
[evergreen|Jason Stephenson] LP#980296: Update void on claims returned for longoverdue status. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=fc361aa> |
| 17:03 |
pinesol_green |
[evergreen|Jason Stephenson] LP#980296: pgtap tests for the void on claims returned org settings. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=a98eac1> |
| 17:03 |
pinesol_green |
[evergreen|Kathy Lussier] LP#980296: Release notes entry for voiding lost on Claims Return - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=db91d15> |
| 17:03 |
pinesol_green |
[evergreen|Ben Shum] LP#980296: Stamping upgrade script for void lost on claims returned, etc. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=e75501d> |
| 17:06 |
|
graced joined #evergreen |
| 17:06 |
|
bshum joined #evergreen |
| 17:06 |
|
kmlussier joined #evergreen |
