| Time |
Nick |
Message |
| 03:04 |
|
Hello joined #evergreen |
| 03:04 |
|
Hello left #evergreen |
| 05:25 |
|
troy__ joined #evergreen |
| 06:01 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 07:19 |
|
rjackson_isl_hom joined #evergreen |
| 08:36 |
|
mmorgan joined #evergreen |
| 08:45 |
|
Dyrcona joined #evergreen |
| 08:58 |
|
Stompro joined #evergreen |
| 09:07 |
* mmorgan |
wants to search Launchpad for bugs released in 3.6.0. Seems like there should be a way to do that. |
| 09:10 |
|
collum_ joined #evergreen |
| 09:23 |
csharp |
rhamby: we never got back to the YAOUS UI stuff - can't do it right now, but wanted to keep it on the radar |
| 09:38 |
|
nfBurton joined #evergreen |
| 09:41 |
csharp |
mmorgan: huh - I guess we're removing milestones as we target the next ones? |
| 09:48 |
mmorgan |
csharp: The milestone still shows when looking at a bug, but there doesn't seem to be a way to search it. 3.6-beta is a better example, like in bug 1850547 |
| 09:49 |
pinesol |
Launchpad bug 1850547 in Evergreen "Angular Acquisitions Sprint 3: Acquisitions Search" [Wishlist,Fix released] https://launchpad.net/bugs/1850547 |
| 09:51 |
Dyrcona |
Inactive milestones still show up if they are set, but they cannot be used to target bugs. |
| 09:51 |
Dyrcona |
They can be made active again by someone with the correct permissions. |
| 09:51 |
mmorgan |
Dyrcona: Right, but is there a way to search for them? |
| 09:52 |
Dyrcona |
mmorgan: Just a moment. |
| 09:54 |
Dyrcona |
mmorgan: From here https://launchpad.net/evergreen click on the milestone you want to see. You can expand the tabular list if the milestone you want doesn't show up. |
| 09:56 |
mmorgan |
Dyrcona: Thanks! That's just what I needed! |
| 09:56 |
mmorgan |
Dyrcona++ |
| 10:31 |
miker |
mmorgan: re your stalling question yesterday, yes, it's intended behavior. stalling means "op capture at pickup lib, and allow EXACTLY the targeted copy (if not at pickup lib) to be captured)" |
| 10:35 |
mmorgan |
miker: Thanks! So is that *always* op capture at the pickup lib, even if there's a targeted copy not at the pickup lib? |
| 10:35 |
miker |
yes |
| 10:36 |
mmorgan |
Ok, that's good! What's the reasoning behind only allowing the EXACT foreign copy to be captured? |
| 10:37 |
mmorgan |
Our libraries are finding that piece problematic. |
| 10:41 |
miker |
I suspect, and will look at the code in a moment, that the practical reason we allowed the further restriction was, in fact, performance. but, think about it this way, too: it's really the "accident" that pull-list-driven hold capture allows adjacent copy capture (because of op-capture) and not the other way around. a better restatement of my "definition" (such as it is) would be "turn off op capture EXCEPT at the pickup library" |
| 10:48 |
Dyrcona |
That's how I interpreted jeff's comment about it being "accidental" yesterday. |
| 10:49 |
mmorgan |
The "accident", seamless capture of equivalent copies, is a much preferred behavior. Without the op-capture, staff members find it hugely time consuming to match barcodes, and frustrating to not be able to fill a hold when they can't find the exact copy. |
| 10:49 |
Dyrcona |
One person's bug is another's feature. :) |
| 10:51 |
miker |
confirmed that there are significant performance implications. I can see a way to make it work, maybe, but lots of testing on various sized data sets would be needed ... the change is small in lines of code (probably 2) but big in terms of potential impact |
| 10:53 |
miker |
mmorgan: I can absolutely understand that! the baseline expectations today are much different than 2004 ... op-capture /at all/ was unthinkably magical back then (to staff used to ... a certain proprietary ILS) :) |
| 10:56 |
csharp |
also, PINES was in the middle of courier paralysis at the time that feature was added (if I know my history) |
| 10:57 |
csharp |
after the courier delays were improved, the need for stalling disappeared (we just this summer turned it off) |
| 10:59 |
mmorgan |
And now we have COVID quarantines, causing long delays with items needing to travel to fill holds, so we just recently turned it on, never having used it before :) |
| 11:01 |
* mmorgan |
is happy to open a bug, and would be happy to test 2-ish lines of code on a large data set :) |
| 11:02 |
csharp |
yeah, some of the courier delays have definitely returned |
| 11:03 |
Dyrcona |
csharp: While you're here, can I ask a couple of questions about Quipu? |
| 11:08 |
|
stompro_ joined #evergreen |
| 11:16 |
miker |
mmorgan: having looked, it's going to be a lot more than 2 lines ;) |
| 11:21 |
miker |
the main problem is, when you're capturing holds you're not saying "here's a hold, capture any copy at this location" you're saying "here's a copy, give me holds it could fill in proximity order". when stalling is enabled what you're really saying is "the PL-to-copy proximity must be 0". the current copy part is separate. here's what the code does: |
| 11:22 |
miker |
1) first look for holds that target the copy in hand. hold onto that list for later |
| 11:23 |
miker |
2) sort holds the copy in hand could fill by "best-ness" per best-hold-sort-order and proximity adjustment rules |
| 11:23 |
miker |
3) run the permit tests on the "best" ordered holds, and return the first permitted |
| 11:25 |
miker |
4) if no "best" ordered holds passed the permit tests, look at that first directly-targetted, stashed list and run the permit tests on those, returning the first that passes |
| 11:29 |
mmorgan |
Hmm. More -ish, than 2, then ;-) |
| 11:29 |
miker |
and (2) is where we run into problems. we're sorting holds-for-this-copy, and stalling specifically says "only look at holds for this copy where the proximity is 0". The directly-targeted hold test comes later and, again, is only about this copy in hand. |
| 11:30 |
|
stompro__ joined #evergreen |
| 11:30 |
miker |
(note, there are some short cuts / optimizations in the actual code -- we merge the lists, we don't do 2 separate loops -- but that's just code ordering stuff) |
| 11:33 |
mmorgan |
Maybe 0) could identify equivalent copies and proceed to 1) for that set of copies? Just brainstorming... |
| 11:33 |
miker |
we never actually see the desired hold in either list, because ALL the info we have is 1) the copy in hand 2) the stalling interval for this location. everything else is derived. adjacent copies are never seen because we're never looking from the point of view of the /holds/ on the pull list, we're looking from the point of view of the copy in hand |
| 11:33 |
|
stompro_ joined #evergreen |
| 11:33 |
miker |
well, right, that's the goal, but using what information that we have in front of us /right now/ |
| 11:34 |
miker |
where "right now" is "standing at the shelf, looking at copies" |
| 11:35 |
mmorgan |
Copies that are attached to the same call_number? |
| 11:37 |
miker |
but what do you do with that? I mean, we have a copy that's /not/ going to give us the hold we want. so .. get same-CN copies, and then look for holds that target those, and then see if the copy in hand is on the hold_copy_map for those holds? that would logically get us there... |
| 11:39 |
mmorgan |
Right... ? |
| 11:40 |
miker |
I'll see what that'd look like as a fallback |
| 11:41 |
miker |
would same-CN be THE rule, or would it be "copies on this bib with the same circ_lib"? |
| 11:42 |
mmorgan |
The latter would be more accurate (for T type holds) |
| 11:42 |
mmorgan |
Would it be practical to check the hold_copy_map for items that are at the same circ_lib? |
| 11:43 |
miker |
right. we'd still miss M-type cross-record. and we'd do useless work for V, C, R, F, I, P ... |
| 11:44 |
miker |
re same-circ_lib, no, we've been in a long battle to get the "best" ordered output down as small as possible (timeouts at checkin, etc) |
| 11:53 |
mmorgan |
Same circ_lib and other criteria, like status? |
| 11:53 |
* mmorgan |
went ahead and opened wishlist bug 1903749 |
| 11:53 |
pinesol |
Launchpad bug 1903749 in Evergreen "Holds stalling should capture equivalent items at targeted library" [Undecided,New] https://launchpad.net/bugs/1903749 |
| 11:59 |
|
sandbergja joined #evergreen |
| 12:06 |
|
jihpringle joined #evergreen |
| 12:07 |
mmorgan |
miker++ # walking through the code |
| 12:13 |
rhamby |
charp: yeah, I'm in the same boat, my plate is full but I want to come back to it when we have time |
| 12:14 |
csharp |
rhamby: 10-4 |
| 12:14 |
csharp |
Dyrcona: sorry - missed you - yes, feel free to ask |
| 12:15 |
Dyrcona |
csharp: Cool! I'll ask. These questions are aslo for berick if you're around. |
| 12:16 |
Dyrcona |
What level of validation do you use? |
| 12:22 |
csharp |
on the quipu end I think it's just valid address checking |
| 12:23 |
Dyrcona |
Have you had many issues? Duplicate patrons, for instance? |
| 12:24 |
csharp |
the code berick wrote that we implemented checks first name, last name, dob, then if there's a match it checks the address street name |
| 12:24 |
csharp |
if those match it sends back a DUPLICATE message |
| 12:25 |
Dyrcona |
Are you satisfied with the service? |
| 12:25 |
csharp |
yes, it's been very useful for us |
| 12:25 |
csharp |
patrons are happy |
| 12:26 |
Dyrcona |
Thanks! I'm sorry that the questions are so vague, but someone else asked me to ask them. |
| 12:27 |
csharp |
Dyrcona: https://git.evergreen-ils.org/?p=evergreen/pines.git;a=shortlog;h=refs/heads/rel_3_4_1 beginning with "KCLS Quipu integration bits" and some forward is what we're running |
| 12:28 |
csharp |
https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/pines-quipu-ecard-integration is where I was originally working - need to backport some of the stuff we did to it |
| 12:28 |
Dyrcona |
csharp++ |
| 12:28 |
csharp |
goal is to make a genericized branch we can all work from |
| 12:28 |
Dyrcona |
Thanks for the git links. Right now, we're looking at options. |
| 12:28 |
csharp |
berick++ |
| 12:29 |
csharp |
Dyrcona: understood |
| 12:29 |
csharp |
Quipu's team has been super helpful and willing to work with us |
| 12:29 |
Dyrcona |
Yeah, these questions came about because of bug 1902937. |
| 12:29 |
pinesol |
Launchpad bug 1902937 in Evergreen "Wishlist: Quipu eCard Integration" [Wishlist,New] https://launchpad.net/bugs/1902937 |
| 12:29 |
csharp |
flexible |
| 12:29 |
Dyrcona |
That's good to know, too. |
| 12:33 |
|
Cocopuff2018 joined #evergreen |
| 12:40 |
|
collum joined #evergreen |
| 12:40 |
|
jihpringle joined #evergreen |
| 13:11 |
miker |
mmorgan: I have a WIP / example I'll push for eyeballs that does the following: if stalling is in use and a new setting called circ.holds.adjacent_target_while_stalling is true, gather the record-adjacent copies at the same circ lib with a status of 0 (available), get the holds that target them directly, and then filter those holds to the ones where copy-in-hand is also on the hold-copy-map. take that filtered hold list and add it to the end of the |
| 13:11 |
miker |
list of holds to try. |
| 13:12 |
mmorgan |
miker++ # Awesome!! |
| 13:18 |
Cocopuff2018 |
thank you for your help guys |
| 13:36 |
|
collum joined #evergreen |
| 13:42 |
jeffdavis |
seeing recurring zombie storage processes chewing up CPU today, seems due to bug 1901191 |
| 13:42 |
pinesol |
Launchpad bug 1901191 in Evergreen "open-ils.storage.actor.org_unit.closed_date.overlap can hang and gives inconsistent results" [High,Confirmed] https://launchpad.net/bugs/1901191 |
| 13:43 |
|
nmalacarne joined #evergreen |
| 13:43 |
Dyrcona |
jeffdavis: You see the corresponding queries in the database, too? |
| 13:43 |
Dyrcona |
Well, before you kill the zombie processes, anyway.... |
| 13:44 |
jeffdavis |
Dyrcona: usually only 1-2 such queries, but they have bizarre dates like 1650-04-09 and 1412-02-27 |
| 13:45 |
Dyrcona |
Yeahp, that's more or less what I saw. |
| 13:47 |
Dyrcona |
I have been meaning to get back to looking into it more, documenting the behavior, and then figuring out a fix. |
| 13:53 |
jeffdavis |
Seems like the open-ils.storage.actor.org_unit.closed_date.overlap API is declared twice, and the one with API level 0 includes "WHERE close_end > ?" in the SQL query it generates, which is (a) wrong and (b) certain to cause problems with these garbled long-ago timestamps |
| 13:54 |
jeffdavis |
The queries I'm seeing use the query form from API level 1 which does "WHERE ? BETWEEN close_start AND close_end" which should work better, but I wonder if the drones are due to the level 0 API being used somehow |
| 14:03 |
Dyrcona |
jeffdavis: It's supposed to only use the level 1 API, but I think there may be a bug somewhere related to getting the implementation. Also, this is the only place where I've noticed an API level other than 1 being specified. |
| 14:04 |
Dyrcona |
You can specify an API level when setting up an OpenSRF session/connection, but I've not found anywhere in Evergreen that explicitly does so. |
| 14:06 |
jeffdavis |
strongly considering ripping out the level 0 version on prod servers, this problem is not going away |
| 14:08 |
Dyrcona |
We made it stop by deleting a closed date that was causing the problem. It seems to happen when it latches onto a closed date as an open date or something. |
| 14:09 |
Dyrcona |
I'm not sure how to explain it, really. |
| 14:10 |
Dyrcona |
One thing I noted in testing is that it didn't matter if it was a multi-day closing or a single day closing that fell on the particular date. |
| 14:11 |
jeffdavis |
hm, noticing that the apparent problem libraries have no open hours at all in actor.hours_of_operation |
| 14:12 |
Dyrcona |
jeffdavis: That's one thing that will do it. In our case it was a library open only 1 day/week. |
| 14:13 |
jeffdavis |
These libraries are doing circs but have no open hours, seems like that is going to be a problem for setting a due date. |
| 14:13 |
Dyrcona |
I plan to look through the code again to see how that code is used. My hunch is we'd be better off looking for the next open date in most cases. |
| 14:14 |
Dyrcona |
Yes. I think there's ad adjacent bug about libraries with no open hours. |
| 14:15 |
Dyrcona |
Not finding what I thought was there. |
| 14:18 |
Dyrcona |
On circulation, I think a library is considered open if there are no hours of operation found. |
| 14:42 |
|
mmorgan left #evergreen |
| 14:46 |
miker |
api_level=0 is a way to hide an implementation of an api method. the client would have to set itself to use api_level 0 at session creation time to see that. explicitly. default is 1 |
| 14:46 |
|
shulabear joined #evergreen |
| 14:47 |
|
terranm joined #evergreen |
| 14:47 |
miker |
so... what Dyrcona said :) |
| 14:48 |
|
mmorgan joined #evergreen |
| 14:49 |
|
nfBurton joined #evergreen |
| 14:49 |
Dyrcona |
miker: I thought I saw somewhere in OpenSRF where it was indexing into an an array to get the API to call and I thought that could possibly lead to the wrong API being called in the case where there is more than 1 level, but a lot has happened since I opened the bug. I'll have to look again. |
| 14:50 |
miker |
Dyrcona: it goes in descending api_level order from the client's declared level (if thunking is enabled, which it is by default). or, that's what the design is |
| 14:51 |
Dyrcona |
Yeah, and I could be misremembering. |
| 14:51 |
miker |
also, bugs happen :) |
| 14:52 |
|
sandbergja joined #evergreen |
| 14:53 |
miker |
and there's exactly 1 place where EG uses api_level: the staff client can say "I'm api_level 2" and it'll get the new-copy-alerts behavior from Circ's uber-run_method. or it can just ask for new-copy-alerts :) |
| 14:53 |
JBoyer |
FYI, Dev meeting in ~7 mins: https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10 |
| 14:57 |
|
shulabear left #evergreen |
| 14:57 |
|
shulabear joined #evergreen |
| 14:57 |
jeffdavis |
Transactions are still failing (and leaving behind spinning storage drones) on open-ils.storage.actor.org_unit.closed_date.overlap, so if it's not using the wrong API level then it's something else. I don't see obvious problems in closed dates for affected libraries, but there were some overlapping closure intervals before - could that be cached somehow? |
| 14:59 |
Dyrcona |
miker: The code that I remembered seeing in the instrospect method of OpenSRF/Application.pm, and it is likely OK. |
| 14:59 |
Dyrcona |
jeffdavis: It might be, but that didn't seem to be an issue. Once I deleted the offending date, everything was OK. |
| 15:00 |
Dyrcona |
Withouth any restarts. |
| 15:00 |
JBoyer |
What time is it? |
| 15:00 |
Dyrcona |
Time for a meeting. |
| 15:00 |
* berick |
rings the bells |
| 15:00 |
JBoyer |
It's Peanut butter, jelly - oops, no. |
| 15:01 |
Dyrcona |
"It's Hammer Time!" |
| 15:01 |
Dyrcona |
ha! |
| 15:01 |
JBoyer |
DEV MEETING BEGINS |
| 15:01 |
JBoyer |
#startmeeting 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10 |
| 15:01 |
pinesol |
Meeting started Tue Nov 10 15:01:11 2020 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:01 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:01 |
|
Topic for #evergreen is now (Meeting topic: 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10) |
| 15:01 |
pinesol |
The meeting name has been set to '2020_11_10___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2020_11_10' |
| 15:01 |
JBoyer |
#topic Introductions |
| 15:01 |
|
Topic for #evergreen is now Introductions (Meeting topic: 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10) |
| 15:01 |
JBoyer |
Give me your hashtag-infos |
| 15:01 |
JBoyer |
#info JBoyer = Jason Boyer, Equinox |
| 15:01 |
|
nfBurton joined #evergreen |
| 15:01 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CW MARS |
| 15:01 |
berick |
#inf berick Bill Erickson, KCLS |
| 15:02 |
sandbergja |
#info sandbergja = Jane Sandberg, Linn-Benton Community College |
| 15:02 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:02 |
gmcharlt |
#info gmcharlt = Galen Charlton, Equinox |
| 15:02 |
nfBurton |
#info nfBurton = Chris Burton, NFPL |
| 15:03 |
terranm |
#info terranm = Terran McCanna, PINES |
| 15:03 |
JBoyer |
Infinite bericks, I guess Evergreen should be finished next month. :D |
| 15:03 |
miker |
#info miker = Mike Rylander, EOLI |
| 15:03 |
JBoyer |
Ok, feel free to introduce yourself as we move along |
| 15:03 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:03 |
|
Topic for #evergreen is now Action Items from Last Meeting (Meeting topic: 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10) |
| 15:03 |
shulabear |
#info shulabear = Shula Link, GCHRL |
| 15:03 |
JBoyer |
#info jeffdavis to gather information re:current Syrup users |
| 15:04 |
JBoyer |
jeffdavis, you around? |
| 15:05 |
csharp |
#info csharp = Chris Sharp, GPLS |
| 15:05 |
jeffdavis |
JBoyer: IIRC NOBLE and Calvin College are the only ones |
| 15:06 |
JBoyer |
That's what I was thinking. (and taking entirely too long to type out_ |
| 15:06 |
JBoyer |
So while Course Reserves may not be 100% there yet, "everybody" using it knows we're planning to drop Python support in the future. |
| 15:06 |
JBoyer |
Which can be planned for / around. |
| 15:07 |
JBoyer |
Any other discussion to be had about Syrup? |
| 15:07 |
dluch |
#info dluch = Debbie Luchenbill, MOBIUS |
| 15:08 |
JBoyer |
ok. |
| 15:08 |
JBoyer |
#topic OpenSRF Release Info |
| 15:08 |
|
Topic for #evergreen is now OpenSRF Release Info (Meeting topic: 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10) |
| 15:08 |
JBoyer |
#info OpenSRF 3.3?: Removing Python & Java |
| 15:08 |
JBoyer |
If memory serves this is Dyrcona's topic? |
| 15:09 |
Dyrcona |
I thought with the imminent removal of Java and Python that we should consider an OpenSRF 3.3 release. |
| 15:09 |
gmcharlt |
agreed |
| 15:09 |
Dyrcona |
This would coincide with adding Ubuntu 20.04 support. |
| 15:09 |
JBoyer |
Reasonable. It would be odd for a point release to be where new OS support happens. |
| 15:10 |
Dyrcona |
Right, or the removal of Python and Java. |
| 15:10 |
JBoyer |
True. |
| 15:10 |
gmcharlt |
nothing in Evergreen requires Java support or python support to my knowledge, so there's nothing stopping us from making osrf 3.3 the minimum required version for _new_ installations, with a note to the effect that 3.2.x won't break 3.6 and earlier |
| 15:11 |
Dyrcona |
That was my thought make OSRF 3.3 and Evergreen 3.7. |
| 15:12 |
Dyrcona |
I'm not sure what "make" is doing in there, but you get the idea, I hope. |
| 15:13 |
sandbergja |
make -f Makefile.install fossa? |
| 15:13 |
Dyrcona |
:) |
| 15:14 |
Dyrcona |
So, I guess the question is when to merge the branches and fork the rel_3_3 and rel_3_7 branches, and maybe we don't need an answer today. |
| 15:14 |
JBoyer |
Looks like some more testing is needed to get those branches in, but that should easily be achievable by the ~3.7 timefram.e |
| 15:15 |
JBoyer |
"Looks like" meaning they're not all signed off yet, but I imagine they'll be no trouble. |
| 15:15 |
gmcharlt |
yeah, and easy enough to get OpenSRF 3.3 out the door sooner than EG 3.7 |
| 15:16 |
JBoyer |
#agreed The removal of Python and Java will be a part of the 3.3 OpenSRF and 3.7 Evergreen releases |
| 15:16 |
Dyrcona |
I think it's worth mentioning again that if you test the Focal Fossa branches, you are effectively testing all 3, since the Focal branches depend on the Python and Java branches. |
| 15:16 |
abowling |
#info abowling = Adam Bowling, Emerald Data Networks |
| 15:17 |
JBoyer |
Do all 3 need to be applied manually or does the fossa branch basically include the others? |
| 15:17 |
* JBoyer |
goes to look after lazygoogling |
| 15:18 |
Dyrcona |
JBoyer: The Fossa branch includes the other two, yes. |
| 15:18 |
JBoyer |
Excellent, ok. So easy to test then. |
| 15:18 |
berick |
good summary http://list.evergreen-ils.org/pipermail/evergreen-dev/2020-October/000053.html |
| 15:19 |
JBoyer |
berick++ |
| 15:19 |
JBoyer |
ok, hopefully some Ubuntu VMs will be spun up and those branches taken for a spin. Any further OpenSRF discussion? |
| 15:20 |
JBoyer |
on to Evergreen |
| 15:20 |
JBoyer |
#topic Evergreen Release Info |
| 15:20 |
|
Topic for #evergreen is now Evergreen Release Info (Meeting topic: 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10) |
| 15:21 |
csharp |
point releases scheduled for next Wednesday = 3.4.5, 3.5.2, & 3.6.1 |
| 15:21 |
csharp |
lots of hackaway goodness |
| 15:21 |
JBoyer |
It doesn't look like I was complete off on my recollection of the 3.7 release team volunteers; have you had a chance to get together and discuss timelines? |
| 15:21 |
JBoyer |
csharp++ |
| 15:21 |
berick |
no timeline discussion yet on 3.7. on my mind, though |
| 15:22 |
JBoyer |
berick++ |
| 15:22 |
berick |
for release team coordination, ##eg-release a reasonable place for that, to start anyway? |
| 15:23 |
JBoyer |
It certainly can be. whatever method works best for the group should be fine. |
| 15:23 |
csharp |
yeah |
| 15:23 |
csharp |
https://docs.google.com/spreadsheets/d/1gZayHfF7qK0zwLMEAXt-PbKBMiAM_F6EZguqzIYceBY/edit#gid=0 - spreadsheet for volunteer roles |
| 15:24 |
berick |
k, i'll put feelers out soon for how we want to manage the roles, etc. |
| 15:24 |
berick |
team++ |
| 15:24 |
csharp |
@eightball is there an "I" in team? |
| 15:24 |
pinesol |
csharp: No. |
| 15:24 |
JBoyer |
and to make sure csharp's reminder hits the brief minutes |
| 15:25 |
JBoyer |
#info 3.4.5, 3.5.2, & 3.6.1 point releases scheduled for next Wednesday |
| 15:25 |
|
Core4997 joined #evergreen |
| 15:25 |
JBoyer |
If there's no further Evergreen release info I'll move along |
| 15:25 |
sandbergja |
This is the last 3.4 release, right? |
| 15:26 |
sandbergja |
(I haven't been following irc much lately, unfortunately) |
| 15:26 |
csharp |
sandbergja: sounds right - should pretty much be security only now that 3.6 is out |
| 15:26 |
Dyrcona |
It somehow seem appropriate to end it on 3.4.5, but I'm not sure if it really is the last 3.4 release. |
| 15:27 |
csharp |
we're so squishy on release dates - we're really more like Fedora than Ubuntu release-cycle-wise |
| 15:27 |
JBoyer |
I mean, if people would just stop finding security bugs I suppose we could leave it there, heh. |
| 15:27 |
gmcharlt |
per https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:schedule, making 3.4.5 end of life for general bugfixes would be OK |
| 15:27 |
sandbergja |
JBoyer: hahaha |
| 15:27 |
JBoyer |
gmcharlt++ |
| 15:27 |
csharp |
gmcharlt++ |
| 15:27 |
gmcharlt |
I'm editing that page now to add 3.6 |
| 15:28 |
sandbergja |
gmcharlt++ |
| 15:28 |
gmcharlt |
and done |
| 15:29 |
JBoyer |
Ok, now we can move on to |
| 15:29 |
JBoyer |
#topic Old Business |
| 15:29 |
|
Topic for #evergreen is now Old Business (Meeting topic: 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10) |
| 15:29 |
JBoyer |
#info PostgreSQL 10+ support - 9.6 EOL is 2021-11-11 |
| 15:30 |
JBoyer |
Does anyone have any further information to bring to the table re: Pg10+ ? |
| 15:30 |
JBoyer |
I know there are a couple production upgrades in the planning phases, but haven't heard anything else. |
| 15:31 |
csharp |
we won't be moving to it until late winter/early spring at this point |
| 15:31 |
Dyrcona |
We're sticking with 9.6 for now. I have a test server with 9.6 through 12 installed. |
| 15:31 |
csharp |
Dyrcona++ # pioneering |
| 15:31 |
Dyrcona |
Um, 9.6 through 13, now. I installed 13 last month. |
| 15:32 |
Dyrcona |
I'm not sure how we should go about benchmarking things, but I can say that performance seems to change quite a bit on 12 versus 9.6 and 10. |
| 15:33 |
JBoyer |
odd benchmarking aside, you haven't noticed anything like the changes in Pg10 where things we were doing in 9.6 and below would just blow up anywhere, correct? |
| 15:34 |
Dyrcona |
Not so far. It looks like we've caught those. I haven't seen anything just blow up on 12, either, and I've been using it as my main test db. |
| 15:34 |
JBoyer |
That's promising. |
| 15:35 |
|
jihpringle joined #evergreen |
| 15:36 |
JBoyer |
Ok. If there's no more discussion to be had about Pg10 I feel like we've already covered the Fossa / -Python / -Java discussions, does anyone have any new business that didn't hit the agenda? |
| 15:37 |
JBoyer |
in that case |
| 15:37 |
JBoyer |
#topic Announcements |
| 15:37 |
|
Topic for #evergreen is now Announcements (Meeting topic: 2020-11-10 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-11-10) |
| 15:37 |
JBoyer |
#info Next Meeting is 2020-12-01 |
| 15:38 |
JBoyer |
What luck, this meeting is ending in a reasonable timeframe, heh. |
| 15:38 |
JBoyer |
Thanks everyone. |
| 15:38 |
JBoyer |
#endmeeting |
| 15:38 |
|
Topic for #evergreen is now Welcome to the #evergreen library system channel! | We are publicly logged: http://irc.evergreen-ils.org/evergreen | Large pastes at http://paste.evergreen-ils.org | Can't speak? Make sure your nickname is registered and that you are identified to freenode services: https://freenode.net/kb/answer/registration |
| 15:38 |
pinesol |
Meeting ended Tue Nov 10 15:38:39 2020 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 15:38 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-11-10-15.01.html |
| 15:38 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-11-10-15.01.txt |
| 15:38 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2020/evergreen.2020-11-10-15.01.log.html |
| 15:38 |
gmcharlt |
JBoyer++ |
| 15:38 |
csharp |
JBoyer++ |
| 15:38 |
sandbergja |
JBoyer!! |
| 15:38 |
dluch |
JBoyer++ |
| 15:38 |
sandbergja |
oops |
| 15:38 |
sandbergja |
JBoyer## |
| 15:39 |
sandbergja |
argh |
| 15:39 |
csharp |
also JBoyer!! |
| 15:39 |
berick |
JBoyer++ |
| 15:39 |
mmorgan |
JBoyer++ |
| 15:39 |
* JBoyer |
senses a phone keyboard. :D |
| 15:39 |
sandbergja |
JBoyer++ |
| 15:39 |
sandbergja |
finally got there :-) |
| 15:39 |
Dyrcona |
JBoyer++ |
| 15:39 |
gmcharlt |
sandbergja++ # persistence |
| 15:39 |
|
shulabear left #evergreen |
| 15:40 |
miker |
JBoyer++ |
| 15:55 |
|
sandbergja joined #evergreen |
| 16:25 |
Dyrcona |
Oh well, issues with my O/S... Gonna sign out. |
| 16:26 |
devted |
if anybody can answer an emergency_closing question, I'm wondering if the action.emergency_closing_stage_{1,2,3} functions can be called manually with the emergecy_closing ID found in actor.org_unit_closed? I have an emergenc_closing listing I'm trying to remove from the Closed Dates Editor. Everything shows 0/0 processed except for holds, which is 1/34 processed. These are for Covid holds that hit their shelf_exipre_time back many |
| 16:26 |
devted |
months ago in May, so could I just delete those respective holds out of the action.emergency_closing_hold table? Then I'm wondering how to remove this ancient Emergency Closing from the Closed Dates Editor, if that's wise. Thanks |
| 16:36 |
Bmagic |
berick: I think I found the issue from several weeks ago where we were talking about how edi_fetcher was downloading and processing the same EDI file over and over and over again. Like thousands of times. |
| 16:37 |
Bmagic |
get this: acq.edi_message.account for these messages are not linked to the account in which the file is downloaded..... how is that poossible? Evergreen is inserting the rows into edi_message with an account ID != the account where the FTP file came from |
| 16:39 |
Bmagic |
I think I've uncovered a bug somewhere... the logic for assigning the account ID must not be matching on ALL of the fields. Because the account that it's assigning has all the same fields except the host field |
| 16:55 |
berick |
Bmagic: take a look at EDI.pm process_message_buyer(). there's logic in there for pulling the account from the EDI content which can replace the presumed account |
| 16:55 |
Bmagic |
right, I was reading that code |
| 16:56 |
Bmagic |
I can't square that logic against what I am seeing. In theory, if the "host" column is different, it should't be matching the one that it's matching. Line 129 ..... my $hits = $e->search_acq_edi_message( |
| 16:57 |
Bmagic |
"ftp://ftp.ingramtest.com" vs. "ftp://ftp.ingramcontent.com" |
| 16:58 |
Bmagic |
the rest of the columns are the same between the two. But that difference should* keep it from matching the wrong account... wait... what if ftp://ftp.ingramtest.com is a real site? Then that would make sense |
| 17:00 |
Bmagic |
these two edi_accounts point to the same provider.... getting closer to the answer |
| 17:01 |
Bmagic |
oh, I see what you are saying. there is code in process_message_buyer that will overwrite the account ID that was arrived at by the other logic? |
| 17:03 |
Bmagic |
found this in the logs: Not changing edi_account because we found (2) matching vendacct(s), one of which being on the edi_account we already had |
| 17:03 |
Bmagic |
followed by: changing edi_account from 104 to 103 based on vendacct 'xxxxxx' (2 match(es)) - there we go! That's the smoking gun |
| 17:05 |
|
mmorgan left #evergreen |
| 18:13 |
pinesol |
News from qatests: Testing Success <http://testing.evergreen-ils.org/~live> |
| 18:23 |
|
jihpringle joined #evergreen |
| 18:46 |
devted |
Closed Dates Editor question: question: Is it normal to see past emergency closings with unprocessed portions in the Closed Dates Editor? (ie, 1/34 holds) |
| 18:47 |
devted |
Closed Dates Editor question #2: Also, is it normal to see past emergency closings with 0/0 processed portions in the Closed Dates Editor? |
| 20:44 |
|
sandbergja joined #evergreen |
| 20:56 |
|
Cocopuff2018 joined #evergreen |
