| 02:46 |
|
mtcarlson joined #evergreen |
| 04:58 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:42 |
|
berick_ joined #evergreen |
| 05:44 |
|
jeffdavi1 joined #evergreen |
| 05:44 |
|
jcamins_ joined #evergreen |
| 14:47 |
bshum |
Generally I don't agree to support anything less than 1024x768 in my consortium. But that's just our practices here. |
| 14:48 |
jeff |
"responsive XUL" isn't really a thing. |
| 14:49 |
Dyrcona |
It's not really usable at less than 1920x1080, cause some wider screens don't get horizontal scroll bars when they should. |
| 14:49 |
csharp |
trying to install/test the web client, but it looks like I'm missing something |
| 14:49 |
bshum |
@quote add <jeff> "responsive XUL" isn't really a thing. |
| 14:49 |
pinesol_green |
bshum: The operation succeeded. Quote #87 added. |
| 14:49 |
Dyrcona |
I'm looking at you Item Status. |
| 14:53 |
Dyrcona |
csharp: It's often a lack of eyesight, not funds. |
| 14:53 |
bshum |
kmlussier: I think idle starting footprint for the Evergreen client is more like 900 MB or so |
| 14:53 |
Dyrcona |
At 800x600 on a larger monitor stuff looks bigger. |
| 14:53 |
bshum |
I'd have to refer back to all the testing notes that was done during the memory leak. |
| 14:53 |
csharp |
whew - that's bad |
| 14:53 |
kmlussier |
But we also have options for increasing font size. |
| 14:54 |
csharp |
it's a bad workaround |
| 15:31 |
kmlussier |
I don't know. tspindler said he got rid of all of his unnecessary stat cats, but it didn't make a huge difference. |
| 15:31 |
csharp |
that seemed to be the factor when krmvga and I were comparing a couple weeks back |
| 15:31 |
csharp |
it loads fine for us, but we barely use patron stat cats |
| 15:33 |
eeevil |
kmlussier: another thing to remember is that, while anecdotal, /everything/ seems to run faster (dojo included) in chrome than in xulrunner, because of the different js engine. again, anecdotal, but something that folks should also look into testing |
| 15:33 |
berick |
eeevil: good point |
| 15:33 |
csharp |
yeah - we tested chrome and firefox |
| 15:33 |
tsbere |
I think another issue was number of permission groups that the permission to edit had to be checked for |
| 15:33 |
csharp |
both were *way* faster, especially chrome |
| 15:34 |
|
tspindler joined #evergreen |
| 15:40 |
jeff |
heh |
| 15:40 |
jeff |
old habit |
| 15:40 |
tsbere |
berick: That is the workflow of the javascript in register.js file. As in client-side. |
| 15:40 |
berick |
kmlussier: and that's different data, too, so not a wholly accurate test. |
| 15:41 |
berick |
tsbere: gotcha. do you think that API call takes too long or processing the results? |
| 15:42 |
kmlussier |
berick: Sure, not that the code is in LP, I think we'll look at loading it with some production data. But it still won't be the same data, so it may not be the best test either. |
| 15:42 |
kmlussier |
That is, now that the code is in LP. |
| 15:42 |
tsbere |
berick: Unless the has_work_perm_at.batch function filters dupes I imagine we are getting a backend dance for each permission group with a perm attached, instead of for each permission (I haven't checked the actor code to see though). Other than that massive playing with the tree of permissions may slow down things when there are a lot of them. |
| 15:43 |
phasefx |
semi-related aside, the xul side of things used to share data with the patron editor to save some network requests, but I don't think that is any longer the case |
| 15:43 |
berick |
kmlussier: another test.. you can go to .. https://YOUR-DOMAIN/eg/actor/user/register |
| 15:44 |
berick |
tsbere: gotcha, yeah, not sure about the api |
| 15:44 |
tsbere |
berick: Actually, now having looked at Actor.pm, it doesn't look like it filters dupes. So if you have 50 groups that use the same permission I think we verify that permission 50 times, instead of just once. Not sure which end we should be filtering it on, though. |
| 15:44 |
|
Shae joined #evergreen |
| 15:44 |
* tsbere |
suspects the backend is a good place though |
| 16:33 |
berick |
s/the/they/ |
| 16:33 |
berick |
they flow on my phone OK, but this freakin' nexus is 1280x768 |
| 16:38 |
eeevil |
fwiw, the overlap there is not dojo's fault, it's simply suboptimal layout |
| 16:38 |
kmlussier |
Sorry, I just walked away to test on my son's phone. It's overlapping there. The phone is a few years old, but it's there. |
| 16:39 |
kmlussier |
berick: No, I haven't looked at much at that level. I try to stay away from 800x600 when I can. :) |
| 16:39 |
berick |
eeevil: yeah, dojo is def. not to blame for a lot of stuff we're throwing around. at this point, I think "dojo" really just means "those interfaces" |
| 16:39 |
berick |
kmlussier: i hear ya |
| 16:41 |
eeevil |
berick: I understand. I want to make sure it's clear that making the pages flow better is not necessarily dependent upon completely replacing them with alternate implementations. and could be done by anyone, not just you, without harming the browser-client target, as long things like element ids and classes don't get blown away |
| 16:42 |
eeevil |
(more or less) |
| 16:42 |
berick |
eeevil: absolutely. that's good to reiterate |
| 16:42 |
|
tspindler left #evergreen |
| 16:43 |
eeevil |
if someone feels like removing floats and tables and moving the /containers/ to divs and whatnot, that should not have an impact on the logic (ideally ... testing would tell, obv) |
| 16:48 |
kmlussier |
eeevil: Sure, I understand that. I was just trying to make the point that it might not be a bad idea to keep that specific bug open. |
| 16:49 |
kmlussier |
If anyone's interested, this is what the patron registration screen looked like on my son's phone. http://www.screencast.com/t/GaEAqcYw |
| 16:49 |
eeevil |
kmlussier: I agree with keeping it open |
| 00:50 |
|
mcarlson joined #evergreen |
| 02:37 |
|
tsbere__ joined #evergreen |
| 02:59 |
|
tsbere_ joined #evergreen |
| 04:28 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:05 |
|
mnsri joined #evergreen |
| 05:12 |
|
book` joined #evergreen |
| 07:27 |
|
collum joined #evergreen |
| 15:14 |
kmlussier |
As part of this action item and the next one, I haven't had a chance to review the most recent code or pull together my summary. The negative balance was 1 of 4 billing projects MassLNC was working on. We decided a few weeks ago to really focus on the other three so that we can get them out of the way before we get back to negative balances, which is a harder nut to crack. |
| 15:14 |
jeff |
(for rounding up scarce tuits) |
| 15:15 |
kmlussier |
But just glancing at dbwells' most recent comment, it looks like there is still a bit of work to be done before this branch is ready to be merged? |
| 15:15 |
dbwells |
Testing at the very least, but like I mentioned, I think a few hours spent on display side would be time well spent for me. |
| 15:16 |
kmlussier |
dbwells: I'm having a hard time picturing what you suggested in your comment, but I also had some concerns on the display side. |
| 15:18 |
kmlussier |
I also don't think I'll have a chance to test the most recent code until we finish working on our two remaining billing projects. Having two dev branches loaded on the test server at the same time causes confusion over which one might be causing a problem. |
| 15:19 |
Dyrcona |
Well, when they're related to the same part of the system, anyway. |
| 15:21 |
dbwells |
kmlussier: If you have a testing timeline in mind, I can try to work on my display ideas so you can test it at the same time. Feel free to get in touch after this meeting if needed. |
| 15:21 |
kmlussier |
So I guess we need some kind of action item for me to test the current branch and provide feedback? I don't know if anyone else wants to take a look at it. |
| 15:21 |
jeff |
I've interest but cannot guarantee that I can make time for it in the next month. |
| 15:22 |
kmlussier |
dbwells: Will do. I'll have to consult with Dyrcona regarding a testing timeline, but we can figure it in short order. |
| 15:22 |
jeff |
I'll see what I *can* do, though. |
| 15:22 |
kmlussier |
jeff++ Thanks! |
| 15:22 |
kmlussier |
#action kmlussier and others to make time to test the latest branch. |
| 15:23 |
kmlussier |
#action dbwells to work on display ideas for negative balance branch |
| 15:23 |
kmlussier |
dbwells and remingtron: Thanks for taking a look at it! |
| 15:23 |
kmlussier |
Anything else before we move on? |
| 15:23 |
jeff |
reducing the number of cases where we deviate from stock is a goal, and our own branch to avoid negative balances is ripe for elimination if we can assist in testing this one. |
| 15:23 |
Dyrcona |
dbwells++ remingtron++ |
| 15:24 |
kmlussier |
#topic OpenSRF release |
| 15:24 |
kmlussier |
Anything to report one OpenSRF? |
| 15:24 |
gmcharlt |
I'm looking for volunteers to test the websockets work submitted by berick |
| 15:24 |
gmcharlt |
any takers? |
| 15:24 |
bshum |
Further down in the agenda, there's some notes about websockets |
| 15:25 |
bshum |
Sorry, juggling between meetings |
| 15:25 |
jeff |
I can test, assuming berick or others are available for questions when I reach that point. |
| 15:25 |
berick |
anything I can do to make testing easier? |
| 15:25 |
berick |
jeff: yes |
| 15:25 |
jeff |
berick++ thanks! |
| 15:25 |
eeevil |
gmcharlt: re your 3 options, I'm strongly in favor of merging what's there and getting the release out |
| 15:25 |
gmcharlt |
likewise |
| 15:26 |
gmcharlt |
jeff: can you put some testing time into this week? |
| 15:26 |
* csharp |
can test, but has not had the time lately to keep up with development, so may need assistance ;-) |
| 15:26 |
jeff |
gmcharlt: yes. i was just about to ask what timeline you had in mind. |
| 15:26 |
kmlussier |
berick: How many testers do you need? |
| 15:26 |
kmlussier |
Sorry, that was for gmcharlt. |
| 15:26 |
gmcharlt |
jeff: let's shoot for by the end of this week, if you can |
| 15:27 |
eeevil |
berick: is it true that anyone whose tested your dev on your demo server has tested the websockets code? |
| 15:27 |
berick |
eeevil: they have, indeed |
| 15:27 |
jeff |
gmcharlt: i will shoot for that. thanks! |
| 15:27 |
gmcharlt |
ok |
| 15:28 |
csharp |
then Terran has definitely been testing |
| 15:28 |
eeevil |
csharp: :) |
| 15:28 |
dbs |
They all haven't installed it locally though :) |
| 15:28 |
kmlussier |
So for an action item, that's jeff and csharp? Do we need more testers or is that good? |
| 15:29 |
berick |
bshum: it does not interract, but code the staff client uses is touched, like the JS opensrf libs |
| 15:29 |
bshum |
Just making sure that present stuff continues to function I guess over what's coming next too. |
| 15:29 |
eeevil |
bshum: only insofar as its part of opensrf ... the current SC does not attempt to make use of it |
| 15:29 |
bshum |
Okay. |
| 15:29 |
bshum |
So that's something we ought to test as well. |
| 15:29 |
berick |
bshum: definitely |
| 15:29 |
bshum |
To make sure that it doesn't break any existing functionality |
| 15:29 |
kmlussier |
#action jeff and csharp to test websockets work by the end of this week. |
| 15:30 |
kmlussier |
#action gmcharlt to cut alpha of OpenSRF the middle of next week (week of Aug. 4th) |
| 15:30 |
kmlussier |
Anything else on OpenSRF? |
| 15:31 |
kmlussier |
#topic Evergreen maintenance releases |
| 15:31 |
kmlussier |
dbwells? |
| 15:31 |
dbwells |
#info 2.6.2 and 2.5.6 were released on 7/7 |
| 15:32 |
dbwells |
I would also like to ask about the next round, which was due last Friday. |
| 15:32 |
dbwells |
There is only one actual code change: https://bugs.launchpad.net/evergreen/+milestone/2.6.3 |
| 15:42 |
kmlussier |
eeevil: Yes, an on-time release. :) |
| 15:42 |
bshum |
gmcharlt: That's something I wanted to have some debate on actually. |
| 15:43 |
bshum |
The scheduled date for 2.7.0 beta freeze and presumably soon thereafter cutting is next Thursday, August 7 |
| 15:43 |
csharp |
so we're talking about for testing purposes? or for general usage? |
| 15:43 |
dbwells |
I can be flexible if we want to coordinate OpenSRF 2.4, 2.7-beta, 2.6.3, and 2.5.7 to all roughly coincide for dependency reasons. |
| 15:43 |
eeevil |
dbwells: looks like we there's no rest for the wicked this month ;) |
| 15:43 |
gmcharlt |
well, we can sequence things like this: opensrf 2.4 alpha => EG 2.6 beta => EG 2.5/2.6 pint releases => opensrf 2.4.0 |
| 15:48 |
bshum |
That sounds reasonable. |
| 15:48 |
bshum |
The next date for 2.7 after beta is the RC date, which is Sept 4 |
| 15:49 |
dbwells |
I'd like to plan the point releases for Aug. 7 as well, if nobody minds. |
| 15:49 |
bshum |
So that gives us time to do tests, etc. with the new OpenSRF |
| 15:50 |
kmlussier |
#agree next round of point releases will be scheduled for August 7 |
| 15:50 |
kmlussier |
Anything else before we move on? |
| 15:50 |
bshum |
Just an info |
| 15:52 |
bshum |
Well, I learned how to use the make_release script tools |
| 15:52 |
bshum |
And the first alpha tarball is up on the downloads page now. |
| 15:52 |
kmlussier |
bshum++ |
| 15:52 |
bshum |
mceraso is actually testing the alpha tarball for me right now, but if anyone else has good or bad things to say about it, please let me know. |
| 15:53 |
bshum |
#info 2.7.0 alpha1 was cut and available from downloads page on Evergreen website |
| 15:53 |
bshum |
#info 2.7.0 beta1 cutoff date is August 7, 2014 (next Thursday) |
| 15:53 |
kmlussier |
Any questions for bshum before we move on? |
| 15:54 |
bshum |
Speaking on the beta deadline, if there's any specific things that people are working on that they really want in 2.7, this is the time to get action on LP for them. |
| 15:54 |
kmlussier |
bshum: What kind of action? |
| 15:57 |
bshum |
I've been saying it in IRC and I think I mentioned it in the last email, but perhaps I should write a more dedicated, "HEY PUSH THINGS" email to developers so that we can get as much work done as possible. |
| 15:57 |
vlewis |
tsbere Thanks |
| 15:57 |
Dyrcona |
Well, that brings up something that I thought of earlier today: lp1347774. |
| 15:58 |
kmlussier |
I have some code I plan to test over the next week, but I don't have the power to push, just sign off. I don't know if that helps expedite the process. |
| 15:58 |
bshum |
Given our general reliance on a week's time to review new features before push, perhaps the cutoff for new LP pullrequest targets ought to be this Thursday, July 31 |
| 15:58 |
kmlussier |
https://bugs.launchpad.net/evergreen/+bug/1347774 |
| 15:58 |
pinesol_green |
Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" (affected: 2, heat: 12) [Wishlist,New] |
| 16:03 |
eeevil |
blockers to attacking this problem, I mean |
| 16:03 |
pinesol_green |
Launchpad bug 1208875 in Evergreen "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" (affected: 5, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/1208875 |
| 16:04 |
Dyrcona |
Well, I like using CStoreEditor, for one thing. :) |
| 16:04 |
bshum |
It was on my list of things to test and include for alpha but I missed my own deadline that week, fwiw. |
| 16:04 |
eeevil |
Dyrcona: that's totally fair. if I can adjust that to fit, would that be a fair compromise? |
| 16:04 |
eeevil |
Dyrcona: you'll get to keep using cstore editor |
| 16:05 |
eeevil |
that's a big part of the plan |
| 16:05 |
Dyrcona |
eeevil: Sure, but I'm willing to rework it if necessary. |
| 16:05 |
eeevil |
(minus json_query) |
| 16:05 |
Dyrcona |
OK. I'll keep an eye out for branches. |
| 16:06 |
kmlussier |
#info any new features for 2.7 should have a pullrequest tag by July 31. |
| 16:06 |
kmlussier |
#help We need volunteers to test and push code for 2.7 |
| 16:06 |
jeff |
eeevil: are you saying you'll adjust the code for bug 1208875 to work under the new reality of bug 1347774? |
| 16:06 |
pinesol_green |
Launchpad bug 1208875 in Evergreen "OPAC: My Account: Download Checkout History CSV breaks when there are a large number of items in the history" (affected: 5, heat: 26) [Medium,Confirmed] https://launchpad.net/bugs/1208875 |
| 16:06 |
pinesol_green |
Launchpad bug 1347774 in Evergreen "Backend logic has leaked into the TPAC (and friends)" (affected: 2, heat: 12) [Wishlist,New] https://launchpad.net/bugs/1347774 |
| 16:13 |
kmlussier |
gmcharlt: Do you have any insights to offer? |
| 16:13 |
gmcharlt |
the lack of sandboxes is a problem |
| 16:13 |
yboston |
kmlussier: I would like to help one way or another. One way I would like to help is put together a tutorial to gelp first time voluneteers, like creating tips for installing EG through Git |
| 16:13 |
gmcharlt |
at least with respect to including as many people as possible who can test but who aren't necessarily in a position to apply particular fixes |
| 16:14 |
hopkinsju |
MOBIUS could provide one or more sandboxes, gmcharlt |
| 16:14 |
gmcharlt |
a possible mitigation would be to arrange for folks to claim bugs before the big day |
| 16:14 |
gmcharlt |
and set up environments before hand |
| 16:16 |
kmlussier |
It seems like branches might conflict if everything happened on one? |
| 16:16 |
gmcharlt |
yep, multiples would help |
| 16:16 |
jeff |
kmlussier: one per bug/branch would be what i was thinking |
| 16:16 |
gmcharlt |
so to expand my suggestion... I think lining up volunteers in advance would really help |
| 16:16 |
gmcharlt |
both for hosting test envs, and for doing testing |
| 16:17 |
kmlussier |
To speed things along, maybe we can move the Sandbox discussion to the dev list to see if we can make this happen. |
| 16:18 |
kmlussier |
#action kmlussier to move Sandbox discussion to dev list |
| 16:18 |
jeff |
+1 |
| 16:19 |
kmlussier |
hopkinsju++ #Volunteering a MOBIUS test server |
| 16:19 |
* kmlussier |
will move forward with bug squashing plans. |
| 16:19 |
kmlussier |
#topic Web client's circulation module preview for Evergreen and websockets for OpenSRF |
| 16:19 |
kmlussier |
bshum: Was this your topic? |
| 16:20 |
bshum |
kmlussier: Yes, but we covered a lot of it earlier with the websockets talk just now. |
| 16:20 |
jeff |
of the three options presented in the agenda, i like the first option best, and i'm almost certain that it is actually what was agreed upon earlier with regard to opensrf alpha scheduling. :-) |
| 16:20 |
bshum |
I think the only outstanding part of it is whether berick thinks we'll want to include the web client circ module preview for 2.7 beta |
| 16:21 |
berick |
It’s tracking Evergreen master, so I’m not expecting any merge conflicts |
| 16:21 |
berick |
or other oddities |
| 16:21 |
jeff |
if it were included without changes to the 2.7 beta timeline, do you think that it would be a useful representation of the web-based features? |
| 16:22 |
kmlussier |
By adding it as a preview, will it make it easier for more people to test? |
| 16:22 |
berick |
jeff: yes; kmlussier: i would think yes |
| 16:22 |
berick |
Assuming web sockets is merged, there’s one other bit of testing we would need to merge the browser client. |
| 16:23 |
berick |
There are a couple of places where existing (non-browser client) code had to be modified for integration (e.g. opac). Affected areas will need to be tested in the XUL client to make sure nothing was broken. |
| 16:23 |
berick |
I could create a list. There aren’t very many of these. |
| 16:24 |
berick |
otherwise, it should go unnoticed for anyone not looking for it |
| 16:24 |
jeff |
process-wise, would a lp bug for the circ-bits with notes on pre-reqs (websockets in opensrf) and a list of things to pay attention to when testing (berick's "list" just now) be the way to get it targeted for 2.7 beta in time for thursday? |
| 16:25 |
kmlussier |
The possibility of breakage in the existing client makes me a little nervous. On the other hand, I would love to make it available for wider testing. |
| 16:26 |
berick |
it occurs to me the build/install process might need some more work, too |
| 16:26 |
berick |
it's been a while since I've looked at that |
| 16:27 |
berick |
if the requiremetn for 2.7 is basically "don't break anything", then I think this is very doable |
| 16:54 |
|
mtcarlson joined #evergreen |
| 16:54 |
Dyrcona |
eeevil: Cool. |
| 16:55 |
* Dyrcona |
was AFK. |
| 17:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:02 |
|
mcarlson joined #evergreen |
| 17:10 |
|
mmorgan left #evergreen |
| 17:32 |
jeff |
Firefox can't find the server at git.evergreen-. |
| 09:05 |
* Dyrcona |
now has to remember how to use yaz-client to check something. |
| 09:07 |
kmlussier |
Good morning! |
| 09:07 |
kmlussier |
tspindler: Chrome Vox was never a problem with autosuggest. |
| 09:08 |
tspindler |
kmlussier: ok, is there something free we can test it with then we have it on ou a dev server |
| 09:15 |
tspindler |
@coffeee |
| 09:15 |
pinesol_green |
tspindler: Zoia knows how to make fusilli. |
| 09:15 |
kmlussier |
Heh |
| 09:16 |
kmlussier |
Shouldn't that say pinesol_green instead of zoia? |
| 11:17 |
kmlussier |
I like what jeff's library does with the whitespace http://catalog.tadl.org/eg/opac/home |
| 11:17 |
|
bmills joined #evergreen |
| 11:18 |
krvmga |
kmlussier: yes, a good example of what i meant. |
| 11:24 |
jeff |
two other approaches that we have been experimenting with can be seen here: https://dev.tadl.org/responsive-web/ and here: http://dev.kalkaskalibrary.org/books/ |
| 11:27 |
jeff |
both of those are very much experiments and/or work-in-progress, hopefully as hinted at by the "dev" hostnames, robots.txt, and content like: "* just testing some things" :-) |
| 11:28 |
krvmga |
jeff: i particularly like the responsive-web one. |
| 11:29 |
krvmga |
jeff: do you have many academic libraries in your consortium? |
| 11:31 |
jeff |
krvmga: no academic libraries in our catalog. we're also not a "consortium", per se. we are a district library, plus we're contracting with a neighboring county library to provide ILS/website/etc services (going live in Aug). |
| 14:33 |
kmlussier |
eeevil++ |
| 14:34 |
krvmga |
jeffdavis: just read death-to-the-website-carousel , interesting read |
| 14:34 |
krvmga |
jeffdavis++ |
| 14:35 |
eeevil |
kmlussier: :) ... I have a followup to that that's in testing ... I'll pull the pullrequest for the ... nonce (that'll be funnier later) |
| 14:36 |
jeffdavis |
krvmga: glad you found it worthwhile! |
| 14:37 |
jeffdavis |
it seems that TADL's carousels/sliders/whatever avoid a lot of the accessibility issues that article raises, which is cool |
| 14:37 |
jeff |
jeffdavis: my intent wasn't to defend them, just to comment on how i've used slider/carousel to mean different things over time. :-) |
| 16:50 |
phasefx |
gmcharlt: we can go ahead and use cluster on the QA server to put everything in backwards orders |
| 16:50 |
mmorgan |
In our experience on Evergreen thus far, the permission group list in the edit screen has been badly sorted, and pretty consistently so from day one. If clustering can sort it better even for a short time, it's a win for us :) |
| 16:50 |
eeevil |
back when all the selinux extensions were first being designed |
| 16:50 |
phasefx |
gmcharlt: well, s/QA/demo/ or manual test server |
| 16:51 |
phasefx |
not quite the same, but partway there for finding bad assumptions in the code |
| 16:52 |
eeevil |
Dyrcona: that's, IIRC, index organized tables, where the heap tuples live on the leaf pages of the index ... yes, similare purpose, but not possible in pg in the broadest sense |
| 16:52 |
eeevil |
Dyrcona: however, for stable dataset and a covering index, you can get an index-only scan |
| 16:52 |
Dyrcona |
yep. |
| 17:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 17:11 |
mmorgan |
good weekend all! don't have nightmares about clustering... |
| 17:11 |
|
mmorgan left #evergreen |
| 17:11 |
kmlussier |
mmorgan: Have a nice weekend! |
| 00:36 |
|
mmorgan1 joined #evergreen |
| 03:39 |
|
mtcarlson joined #evergreen |
| 04:26 |
|
remingtron joined #evergreen |
| 05:06 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:49 |
|
b_bonner joined #evergreen |
| 05:52 |
|
mtcarlson_away joined #evergreen |
| 05:53 |
|
mnsri joined #evergreen |
| 14:11 |
|
RoganH joined #evergreen |
| 14:13 |
tspindler |
bshum: does Dan need to do something more with this https://bugs.launchpad.net/evergreen/+bug/1099979 |
| 14:13 |
pinesol_green |
Launchpad bug 1099979 in Evergreen "Merge Parts" (affected: 4, heat: 18) [Wishlist,Confirmed] |
| 14:16 |
bshum |
tspindler: I don't think so. The changes worked for me enough in my initial testing that I felt comfortable picking in the commit pretty soon |
| 14:16 |
bshum |
I was just getting all the t's crossed and i's dotted |
| 14:17 |
tspindler |
thank bshum, I just wasn't sure if you were looking for more testing from us |
| 14:18 |
tspindler |
i think we need to return the favor and do some testing of others code ;) |
| 14:18 |
RoganH |
bshum: you still need testing on the merge parts? |
| 14:19 |
bshum |
tspindler: There's always welcome room for further testing :) |
| 14:19 |
bshum |
RoganH: If you feel interested to take a look, that'd be great to have an extra pair of eyes look it over. My own light testing seemed fine, but I don't mind the extra checks. |
| 14:20 |
RoganH |
bshum: I've been meaning to dig around launchpad for another commit to test to help out if another signoff is needed. I just hadn't done so yet. |
| 14:20 |
RoganH |
bshum: Move from our old servers to Sequoia was last night so it's been busy. |
| 14:20 |
bshum |
I hear that |
| 14:32 |
Dyrcona |
tspindler: Keep an eye on your launchpad bug email this afternoon. |
| 14:49 |
|
muddles17 joined #evergreen |
| 14:51 |
|
muddles17 left #evergreen |
| 14:51 |
|
muddles17 joined #evergreen |
| 15:06 |
tspindler |
Dyrcona: okee dokee |
| 15:09 |
tspindler |
I had a question about testing, does everyone test with concerto data or do you also test with production (I think I know the answer for Dyrcona) but I was wondering about others? |
| 15:09 |
tspindler |
not on production but with production data that is |
| 15:11 |
RoganH |
tspindler: varies a bit, if it's a UI thing I will test on a VM with concerto data, but something like the 856 testing a while back I did on a test box with production data because I didn't feel test data would find issues |
| 15:11 |
csharp |
tspindler: we pretty much *only* test with production data |
| 15:12 |
RoganH |
If you're talking about broader testing like testing upgrades it's always with production data. |
| 15:12 |
csharp |
the default OU setup and concerto don't feel "real" enough for our end user testers, so we haul around our huge dataset from server to server |
| 15:13 |
csharp |
testing for bugfix signoffs and the like, I use default setup/concerto on current master |
| 15:13 |
tspindler |
RoganH: I was thinking more about new development and not upgrade, we ahve been testing upgrade with production data |
| 15:24 |
dbwells |
bshum: I think I may have hit that jump bug once in a custom script. I've at least targetted it for 2.5 and 2.6 now. Thanks for asking. |
| 15:24 |
Dyrcona |
I only test with production data. |
| 15:25 |
Dyrcona |
tsbere uses concerto and production depending. |
| 15:26 |
bshum |
I tend to use a mixture of both depending on what I happen to have most readily available at the time. |
| 15:26 |
bshum |
Though nominally everything eventually gets tested with production data. |
| 15:26 |
bshum |
I guess I like testing OPAC features using concerto data actually. |
| 15:32 |
Dyrcona |
bshum: In the case of dpearl's branch referenced in the lp bug above, it was handy know I had a patron with 500 or entries in their circ history. |
| 15:33 |
bshum |
True that. |
| 15:33 |
Dyrcona |
Guess my brain is still faster than my fingers. |
