| Time |
Nick |
Message |
| 07:23 |
|
rjackson_isl_hom joined #evergreen |
| 07:46 |
|
kworstell-isl joined #evergreen |
| 07:54 |
|
BDorsey joined #evergreen |
| 08:38 |
|
mantis1 joined #evergreen |
| 08:38 |
|
mmorgan joined #evergreen |
| 09:05 |
|
rjackson_isl_hom joined #evergreen |
| 09:05 |
|
Dyrcona joined #evergreen |
| 09:18 |
|
rjackson_isl_hom joined #evergreen |
| 09:20 |
|
jvwoolf joined #evergreen |
| 09:32 |
jeff |
I'm wondering (perhaps not for the first time) about the logic of "fixing" a checksum to match the data when the checksum is invalid. Specifically, use of Business::ISBN::fix_checksum. Is there a common reason why some large number of ISBN values have an invalid checksum, and the checksum is actually the problem? |
| 09:34 |
|
rjackson_isl_hom joined #evergreen |
| 09:35 |
jeff |
docs don't mention specifics, just a warning in the example "BEWARE: the error might not be in the checksum!" and "Despite the disclaimer in the discussion of that method, the author has found it extremely useful." |
| 09:38 |
|
collum joined #evergreen |
| 09:39 |
Dyrcona |
jeff: Are you asking about our use of the fix_checksum method or the reason for it's existence in the first place? |
| 09:40 |
jeff |
both! :-) |
| 09:40 |
jeff |
Is there some common thing / process / software / practice that mangles or miscalculates the checksum, and only the checksum? |
| 09:41 |
Dyrcona |
Well, I'd ask bdfoy about the latter question. There are a lot of misprinted ISBNs that get entered into databases, though. When I worked at the University Press of Kentucky, I recall at least two books that made it to distribution with incorrect ISBNs. |
| 09:42 |
Dyrcona |
Sometimes the dust jacket disagrees with the copyright page. |
| 09:43 |
Dyrcona |
The official ISBN (at the time, anyway, late '90s) is the one entered in the ISBN log book, not what's printed on the copy. |
| 09:44 |
Dyrcona |
So, misprints is one way this happens, and it's frequently the check digit that's wrong. |
| 09:47 |
Dyrcona |
Human error is the main culprit. |
| 09:57 |
Dyrcona |
Right. I'm going to switch laptops. I should have just used the other to begin with. |
| 10:02 |
|
stephengwills joined #evergreen |
| 10:10 |
|
Dyrcona joined #evergreen |
| 10:21 |
* Dyrcona |
shakes his head at what Last Pass password manager thinks it a "secure" password versus what it thinks isn't a secure password. |
| 11:05 |
|
rjackson_isl_hom joined #evergreen |
| 11:20 |
Dyrcona |
First time I've ever had a site ask me to solve a captcha in order to log out. |
| 11:42 |
|
jvwoolf joined #evergreen |
| 11:58 |
Bmagic |
lol, that is messesd up |
| 12:01 |
|
jvwoolf joined #evergreen |
| 12:10 |
Bmagic |
I'm having fun with triggers. It seems that once a year we see a spike in pending triggers, which result in "no children available" eventually. It seems that the highest number of triggers that I can bite off and chew is 30k at a time. I've been watching the lifecycle like a hawk and I've noticed that behavior. I've increased the number of cstore children to 250. Another weird thing is that opensrf won't even start if that number is |
| 12:10 |
Bmagic |
over 275ish. So 250 seems to be the max before the whoel server won't start. But that's ok, I'm working around that. It doesn't seem like the number of cstore children matters anyway. |
| 12:11 |
Bmagic |
I witness the no children errors after (it seems) the action_trigger_runner process dies for some other reason. So I'm thinking that I need a way to prevent the action trigger running from collecting more than 20-30 at a time. Is there some way to do that other than dividing up the granularity? |
| 12:12 |
Bmagic |
20-30k that is |
| 12:14 |
stephengwills |
Dyrcona: hotel_california.com? |
| 12:14 |
stephengwills |
You can logout anytime you’ld like, but you can never leave.. |
| 12:15 |
Bmagic |
I'm dreaming of another wrapper script that controls the number of action_trigger.event rows that action_trigger_runner can have. I would also like to automate re-running of non-finished triggers. Those that were abandoned during it's life, like "collected", "reacting", "found" etc. Those that never moved on because action_trigger_runner was killed. |
| 12:15 |
Bmagic |
stephengwills: I bought a chicken and and egg on Amazon. I'll let you know. |
| 12:22 |
Dyrcona |
Bmagic: Any particular trigger? |
| 12:23 |
Dyrcona |
stephengwills: It was a travel-related site. |
| 12:23 |
Dyrcona |
...and I had just changed my password. |
| 12:24 |
Bmagic |
wouldn't it be cool if the utility server didn't need so much administration to time out the cron jobs for the action triggers, but rather, a single cron that ran forever in a sleep loop (and checked to see if it was already running and not start again). the sleep loop would checkout the set of active definitions, and spawn action_trigger_runner's as needed, based up on a new column in the definition called "frequency" with an interval |
| 12:24 |
Bmagic |
data type? So that the "one script" knew when to spawn new runners compared to the last time it ran. And be smart enough not to dogpile another one if the first one were still running... etc. |
| 12:24 |
Dyrcona |
Bmagic: you've basically described clark-kent.pl in daemon mode. |
| 12:24 |
Bmagic |
yep, exactly |
| 12:26 |
Dyrcona |
It would work if another process could schedule the triggered events, so we're still likely stuck with something running --process-hooks in cron. |
| 12:27 |
Bmagic |
I was thinking that action_trigger.event_definition needed two new columns: frequency INTERVAL, max_triggers INT |
| 12:27 |
Dyrcona |
Or a total redesign of how triggers work. |
| 12:28 |
Bmagic |
those columns could informm the wrapper software about when to start another runner, and keep the running from running more than max_triggers at a time so that it plays nice on the OpenSRF stack |
| 12:28 |
Bmagic |
the software would run 24x7 and spawn as needed, smartly |
| 12:29 |
Dyrcona |
I'm not so sure I'd call it a wrapper. I'm imagining a replacement for at least part of the a/t system. |
| 12:30 |
Bmagic |
process-hooks is needed/not needed based upon the definition behind whatever is set for "hook" right? If' it's a passive hook or not? |
| 12:31 |
Dyrcona |
There'd be a daemon running all the time that handles the heavy lifting. When an active event is created, the trigger system could signal the daemon (either via a signal, a message over a domain socket, etc.). It would spawn a process to do what is required. |
| 12:31 |
Bmagic |
right! It sure seems doable |
| 12:31 |
Dyrcona |
Yeah, passive events would need something to run to create the events and then signal the daemon. |
| 12:31 |
Bmagic |
then we could reduce all of those cron entries into a single entry |
| 12:32 |
Bmagic |
* * * * /openils/bin/run_trigger_daemon.pl |
| 12:32 |
Dyrcona |
I suppose the daemon could take over passive events, too. |
| 12:32 |
Bmagic |
to ensure it get's turned on, it might as well have a cron, but it checks itself so that it doesn't run over itself. No biggie |
| 12:33 |
Dyrcona |
Nope. I'm thinking of a real service that could be added to systemctl, etc. |
| 12:33 |
Bmagic |
even better |
| 12:38 |
jeffdavis |
As an aside, the hard-coded limit of 256 children for C services is determined by the ABS_MAX_CHILDREN constant in osrf_prefork.c. I ran into that with parallel requests for pcrud, the feeling was that would be better to reduce the number of calls rather than raise the limit. |
| 12:39 |
Dyrcona |
Yeahp. I knew that sounded familiar. jeffdavis++ |
| 12:40 |
Dyrcona |
If I were to implement such a daemon, I'd rather write it in C than in Perl. |
| 12:40 |
jeffdavis |
horrifying to think that without chat logs I'd have to *remember* stuff like this |
| 12:41 |
Dyrcona |
:) |
| 12:41 |
Dyrcona |
I saw this on 9gag this morning with a picture of an old rotary phone: "I wonder what the part of my brain that used to memorize phone numbers is doing now?" |
| 12:42 |
Bmagic |
Dyrcona: Do you think this could be reality? Or just a dream that no one will want to get behind? Should I make an official LP? |
| 12:43 |
Dyrcona |
Bmagic: Yes, yes, and also yes. :) |
| 12:44 |
Bmagic |
It's something that no one will get behind and* it's something that could be reality. Those seem mutually exclusive? |
| 12:44 |
Dyrcona |
Not in this community. :) |
| 12:44 |
Bmagic |
haha |
| 12:44 |
Bmagic |
If you write it they will come |
| 12:44 |
Dyrcona |
or not. |
| 12:45 |
Dyrcona |
Bmagic: I think if we replace granularity with an interval setting (similar to what you suggested before), then it would work. |
| 12:45 |
|
jihpringle joined #evergreen |
| 12:46 |
Bmagic |
I'm less certain about my C skills. If I were making this thing up, I'ld probably use Perl, and probably something that looks more like clark_kent. So, it seems that we need some kind of ent-moot |
| 12:47 |
Bmagic |
the frequency interval seems to me more like what granularity is trying to get at. And frequency is more concise IMO |
| 12:47 |
Dyrcona |
I am not as fond of Perl as I used to be. |
| 12:47 |
Bmagic |
If Evergreen didn't already ahve so much Perl, I'd probably go for whatever Evergreen was doing |
| 12:48 |
Dyrcona |
Well, granularity is more...granular...ahem. With a/t runners, you can have different daily granularities that run at different times of the day, like "daily," daily-noon, daily-200am, etc. |
| 12:48 |
Dyrcona |
Evergreen is kind of what has put me off Perl, unfortunately. |
| 12:50 |
Bmagic |
When i was thinking about this yesterday, I had the same thought. I was thinking "well, ok, what about admin's that break the triggers up in cron with complicated things like * 1-5,9,13,16 * * *" - so I googled for some already-written software that could parse a crontab frequency syntax. Long story short: there's not much out there that implements timing the same as cron does |
| 12:51 |
Bmagic |
so the question becomes: with this new brain running things, is there really a need for that type of frequency? Or is an interval clause good enough? Given the smarts of this new thing? |
| 12:51 |
Dyrcona |
Yeahp, just different implementations of cron, mostly. |
| 12:52 |
Dyrcona |
Maybe. My first thought was keep a/t runner just to create the events and tell the daemon to wake up and do something. |
| 12:53 |
Bmagic |
one of the requirements I think this thing needs: is to understand where* in the lifecycle each of it's spawned runners are. And "know" if it's at the pending->collected stage |
| 12:54 |
Dyrcona |
We could invent our own frequency syntax if needed. |
| 12:54 |
Dyrcona |
If we keep the a/t runner, it would create pending events, tell the daemon that there are new pending events, and the daemon would do the rest. |
| 12:55 |
Dyrcona |
It could have some smarts to check for "stuck" events, too. |
| 12:55 |
Bmagic |
that's wehere my thoughts took me. I was thinking, ok, then, let's add a column for minute, hour, day, month, dow. Just like cron, and mesh that together... then things got complicated and I went back to the single frequency interval idea with the KISS principles |
| 12:57 |
Dyrcona |
I imagine a single field with human friendly values like "daily: 05:00," "weekly: Monday 05:00," "monthly: 15th 00:00" and so on.... Be nice if it could understand different human languages, too. |
| 12:57 |
Bmagic |
another question that came to mind was: why doesn't action_trigger_runner update all* of the rows from pending->collected in one query? |
| 12:57 |
Dyrcona |
It does each event as it collects them, so they are not all collected at once. |
| 12:57 |
Bmagic |
and I guess the reason is update_process column needs to know the PID of opensrf.trigger drone |
| 12:59 |
Dyrcona |
Or it could be done with a schedule, like reports, and the schedule is update each time the events are processed. This way, the a/t runner could be eliminated. |
| 13:00 |
Bmagic |
unless it's the best way, I don't think we need to entirely rewrite this system. It works as-is for the most part. There seems to be some boiling points where it fails and I want to cut that out |
| 13:02 |
Dyrcona |
We could always start with a hybrid approach and move to a schedule if the hybrid approach doesn't work out. |
| 13:04 |
|
mantis1 joined #evergreen |
| 13:04 |
Bmagic |
I'm not seeing much fundamental difference between a "schedule" and action_trigger.event run_time > now() |
| 13:06 |
Dyrcona |
Passive events need a way to be checked for and created. That's where I see the schedule being useful. If w do away with the a/t runner, the daemon would add a schedule entry to check for that event "granularity" at a certain time. |
| 13:07 |
Dyrcona |
clark-kent.pl runs a report and if it is schedule to recur, it adds it to the schedule for next time, so something like that with passive events. |
| 13:07 |
Bmagic |
for exacmple, at circulation time, the code would insert all of the relative schedule checks into the table? |
| 13:09 |
Dyrcona |
That's not quite what I was thinking. |
| 13:10 |
Bmagic |
A/T is flexible. Any number of reactors and re-reactors are possible. Predicting them and creating a future schedule for each of them.... |
| 13:10 |
Dyrcona |
Let me use an example. Take a 7-day overdue notice event. It gets triggered when an item is 7 days overdue. Let's say it has a daily granularity. |
| 13:13 |
Dyrcona |
Now that I'm trying to explain what I was thinking by way of example, it seem like keeping a/t runner in cron to just do process-hooks make more sense. |
| 13:13 |
Bmagic |
:) |
| 13:13 |
Dyrcona |
I was thinking the daemon would do the daily jobs and add a schedule entry to remind it to check for those events again later. |
| 13:14 |
Bmagic |
right, I understand |
| 13:15 |
Dyrcona |
Seems redundant, but it would be nice to figure out a neat way to maintain the flexibility of granularity without requiring a/t runner. |
| 13:15 |
Bmagic |
jeff: you've got an action item: make action triggers better |
| 13:15 |
Dyrcona |
Ha! |
| 13:15 |
Bmagic |
done, we'll check back with jeff next week |
| 13:15 |
Dyrcona |
Bmagic++ jeff++ also, stephengwills++ |
| 13:19 |
Bmagic |
Dyrcona++ |
| 13:23 |
|
rjackson_isl_hom joined #evergreen |
| 13:34 |
|
jvwoolf1 joined #evergreen |
| 13:52 |
|
jvwoolf joined #evergreen |
| 14:38 |
Bmagic |
Dyrcona jeff jeffdavis: bug 1989498 |
| 14:38 |
pinesol |
Launchpad bug 1989498 in Evergreen "WISHLSIT: Smart Action Triggers" [Undecided,New] https://launchpad.net/bugs/1989498 |
| 14:46 |
JBoyer |
Dev meeting in T-15 |
| 14:46 |
JBoyer |
Well, 14, but whatevs. |
| 14:54 |
|
shulabear joined #evergreen |
| 14:56 |
|
tlittle joined #evergreen |
| 14:57 |
|
terranm joined #evergreen |
| 14:58 |
|
sandbergja joined #evergreen |
| 15:00 |
JBoyer |
The third bell tolls! Meet! Meet! Meet! |
| 15:00 |
JBoyer |
#startmeeting 2022-09-13 - Developer Meeting |
| 15:00 |
pinesol |
Meeting started Tue Sep 13 15:00:35 2022 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. |
| 15:00 |
pinesol |
Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. |
| 15:00 |
pinesol |
The meeting name has been set to '2022_09_13___developer_meeting' |
| 15:00 |
JBoyer |
#info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2022-09-13 |
| 15:00 |
|
smorrison joined #evergreen |
| 15:00 |
JBoyer |
#topic Introductions |
| 15:00 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CWMARS |
| 15:00 |
gmcharlt |
#info gmcharlt = Galen Charlton, Equinox |
| 15:01 |
JBoyer |
#info JBoyer = Jason Boyer, EOLI |
| 15:01 |
jeffdavis |
#info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) |
| 15:01 |
sandbergja |
#info sandbergja = Jane Sandberg, Evergreen enthusiast |
| 15:01 |
shulabear |
#info shulabear = Shula Link, GCHR in PINES |
| 15:01 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:01 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Equinox |
| 15:01 |
rhamby |
#info rhamby = Rogan Hamby, Equinox |
| 15:02 |
collum |
#info collum = Garry Collum, KCPL |
| 15:02 |
terranm |
#info terranm = Terran McCanna, PINES |
| 15:02 |
stephengwills |
#info stephengwills Maine Balsam Libraries |
| 15:03 |
JBoyer |
Others feel free to #info up as you filter in. |
| 15:03 |
JBoyer |
#topic Action Items from Last Meeting |
| 15:03 |
JBoyer |
#info Dyrcona will take a look at LP 1979357 |
| 15:03 |
pinesol |
Launchpad bug 1979357 in Evergreen "fixes for qatester failures" [Undecided,New] https://launchpad.net/bugs/1979357 - Assigned to Jason Stephenson (jstephenson) |
| 15:03 |
JBoyer |
I should probably have signed off on that already, I've already tested and verified most of it anyway. |
| 15:04 |
jeffdavis |
just as long as some Jason looks at it |
| 15:04 |
Dyrcona |
I have not had time to really look at it, so maybe I should remove myself from the bug? |
| 15:04 |
JBoyer |
Dyrcona, do you have time to investigate or should I grab that one |
| 15:04 |
JBoyer |
I'll take it then. |
| 15:04 |
JBoyer |
Dyrcona++ |
| 15:04 |
Dyrcona |
JBoyer++ |
| 15:04 |
JBoyer |
#action JBoyer will take a look at LP 1979357 |
| 15:04 |
pinesol |
Launchpad bug 1979357 in Evergreen "fixes for qatester failures" [Undecided,New] https://launchpad.net/bugs/1979357 - Assigned to Jason Stephenson (jstephenson) |
| 15:04 |
shulabear |
JBoyer++ |
| 15:05 |
JBoyer |
The other thing from last time, |
| 15:05 |
JBoyer |
#info JBoyer will propose LP users to trim from Drivers / Wranglers / etc. lists. |
| 15:05 |
JBoyer |
I did that, and Dyrcona cleaned them up. Hurrah. |
| 15:05 |
JBoyer |
Dyrcona++ |
| 15:05 |
|
dbriem joined #evergreen |
| 15:05 |
JBoyer |
Unless someone has pressing updates that did not hit the agenda ( o.O ) we'll move on to LP stats |
| 15:05 |
miker |
#info miker = Mike Rylander, EOLI, belated |
| 15:05 |
gmcharlt |
JBoyer: one moment |
| 15:05 |
JBoyer |
sure thing |
| 15:05 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:06 |
* Dyrcona |
thinks we still have some Lp groups to clean up. |
| 15:06 |
gmcharlt |
re 3.8 and 3.9 releases, I would like to declare a merge freeze for bugfixes by end of day tomorrow |
| 15:06 |
|
rfrasur joined #evergreen |
| 15:06 |
|
Guest338 joined #evergreen |
| 15:06 |
gmcharlt |
for finalization (at long last) of the branches for maintenance releases on Thursday |
| 15:07 |
Dyrcona |
gmcharlt++ and +1 even. |
| 15:07 |
JBoyer |
+1 |
| 15:07 |
JBoyer |
gmcharlt++ |
| 15:07 |
sandbergja |
gmcharlt++ |
| 15:07 |
* miker |
slowly backs away from the commit button |
| 15:07 |
miker |
gmcharlt++ |
| 15:07 |
shulabear |
gmcharlt++ |
| 15:07 |
Bmagic |
gmcharlt++ |
| 15:08 |
Dyrcona |
Should we have a formal vote or just say, "hearing no objections...." :) |
| 15:08 |
gmcharlt |
miker: no, sorry, you will have to wait until Friday to commit Evergreen/COBOL |
| 15:08 |
terranm |
gmcharlt++ |
| 15:08 |
JBoyer |
miker, It's like a yellow light when you drive like a Hoosier, it means speed up, not slow down! ;) |
| 15:08 |
mmorgan |
gmcharlt++ |
| 15:08 |
miker |
I'll have Evergreen/FORTRAN in by EOB today, though |
| 15:08 |
gmcharlt |
miker++ |
| 15:09 |
JBoyer |
Dyrcona, given the timeline and pace of recent commits I'm fine with "hearing no objections." |
| 15:10 |
Dyrcona |
Ok. |
| 15:11 |
abneiman |
is there a plan for release notes? |
| 15:12 |
JBoyer |
#info A merge freeze will be in effect EOB 9/14 so releases can be cut this week |
| 15:12 |
gmcharlt |
an initial draft will be posted this evening; I'm not anticipate a great many additional patches between now and Wednesday evening |
| 15:13 |
JBoyer |
abneiman++ |
| 15:13 |
JBoyer |
gmcharlt++ |
| 15:13 |
sandbergja |
release_notes++ |
| 15:13 |
shulabear |
release_notes++ |
| 15:14 |
JBoyer |
ok, we'll move on then if there are no other release updates |
| 15:14 |
JBoyer |
#topic Launchpad Status |
| 15:14 |
JBoyer |
#info Snapshot |
| 15:14 |
JBoyer |
#info Open Bugs - 2844 |
| 15:14 |
JBoyer |
#info Pullrequests - 95 |
| 15:14 |
JBoyer |
#info Signedoff - 62 |
| 15:14 |
JBoyer |
#info Updates Since Last Meeting |
| 15:14 |
JBoyer |
#info Bugs Added - 52 |
| 15:14 |
JBoyer |
#info Pullrequest tag Added - 28 |
| 15:15 |
JBoyer |
#info Signedoff tag Added - 7 |
| 15:15 |
JBoyer |
#info Fix Committed - 6 |
| 15:15 |
JBoyer |
mmorgan++ |
| 15:15 |
JBoyer |
That brings us to the new |
| 15:15 |
JBoyer |
#topic New Business |
| 15:15 |
JBoyer |
#topic 3.10 release manager / team / etc. Volunteer, Voluntell, or Voluntold; your choice! |
| 15:16 |
JBoyer |
Who would like to bend 3.10 to their will? |
| 15:16 |
sandbergja |
I'd be happy to be part of a release team |
| 15:16 |
JBoyer |
sandbergja++ |
| 15:16 |
JBoyer |
That's great |
| 15:16 |
Bmagic |
sandbergja++ |
| 15:16 |
mmorgan |
sandbergja++ |
| 15:16 |
gmcharlt |
sandbergja++ |
| 15:16 |
abneiman |
sandbergja++ |
| 15:17 |
collum |
sandbergja++ |
| 15:17 |
shulabear |
sandbergja++ |
| 15:17 |
mmorgan |
I feel like I've been hogging a seat, but I'd be happy to help also. |
| 15:18 |
gmcharlt |
mmorgan++ |
| 15:18 |
terranm |
I'm happy to continue organizing the BSW/FFs |
| 15:18 |
sandbergja |
mmorgan++ |
| 15:18 |
sandbergja |
terranm++ |
| 15:18 |
gmcharlt |
terranm++ |
| 15:18 |
mmorgan |
terranm++ |
| 15:18 |
JBoyer |
Much like a conference call for programs, I don't think the applications are overflowing mmorgan. :) |
| 15:18 |
JBoyer |
mmorgan++ |
| 15:18 |
JBoyer |
terranm++ |
| 15:18 |
gmcharlt |
and unofficially, there are some build things I can help codify and get out of my head for this release |
| 15:18 |
Bmagic |
mmorgan++ |
| 15:18 |
shulabear |
mmorgan++ |
| 15:18 |
shulabear |
terranm++ |
| 15:19 |
JBoyer |
gmcharlt++ |
| 15:19 |
|
lstratton joined #evergreen |
| 15:19 |
sandbergja |
gmcharlt++ |
| 15:19 |
collum |
mmorgan++ terranm++ |
| 15:19 |
JBoyer |
I've also meant to update a couple of the translation wiki pages for a while. |
| 15:19 |
collum |
gmcharlt++ |
| 15:20 |
gmcharlt |
so, sounds like a release team of sandbergja, mmorgan, terranm and me as a shadow |
| 15:20 |
|
jvwoolf joined #evergreen |
| 15:20 |
abneiman |
mmorgan++ terranm++ gmcharlt++ |
| 15:21 |
mmorgan |
gmcharlt++ |
| 15:22 |
gmcharlt |
with respect to 3.10, I've got a question |
| 15:22 |
gmcharlt |
the two biggest pieces I'm aware that are pending are the Angular patron/circ app and the Angular acquisitions blob |
| 15:22 |
gmcharlt |
(yes, that's right, Acquisitions Blob is the new official title) |
| 15:22 |
mmorgan |
:) |
| 15:23 |
gmcharlt |
I'm curious (terranm? berick?) how testing of the patron/circ app is going |
| 15:23 |
terranm |
There were a lot of small issues found during BSW that were tracked on a big ole spreadsheet. I'm not sure if any of those have been addressed yet. |
| 15:23 |
gmcharlt |
(and where I'm leading up to is the question about whether Angular patron/circ is a 3.10 thing, 3.10 "experimental" thing, or a 3.11 thing) |
| 15:24 |
gmcharlt |
(I'm partial, but I'm feeling generally pretty comfortable about Angular Acq Blob being suitable for 3.10) |
| 15:24 |
terranm |
IMO it could be experimental now, but it's not ready for prime time |
| 15:24 |
Bmagic |
Those interfaces get used a lot*. IMO the old and the new should be available for some number of releases |
| 15:25 |
terranm |
FYI: https://docs.google.com/spreadsheets/d/1PL04fcjom0l2xuum_Do-w04asn-ifAEHwuBY6yWIESQ/edit#gid=0 |
| 15:26 |
Bmagic |
nicew |
| 15:26 |
mmorgan |
+1 to having both available for a transition period |
| 15:26 |
sandbergja |
Was there a previous discussion of a longer release schedule for 3.10, so that the patron screens are totally ready? |
| 15:26 |
JBoyer |
I feel like a significant overlap has been brought up before and wasn't seen as desirable. Unfortunately I think berick had the most to say about it but appears to be unavailable. |
| 15:26 |
gmcharlt |
sandbergja: yeah, I recall there was a discussion a few meetings back |
| 15:27 |
|
mdriscoll joined #evergreen |
| 15:27 |
gmcharlt |
FWIW, I'm in the camp that some sort of overlap period is going to be a necessary evil, but I have significant concerns if such a period is allowed to go on too long |
| 15:29 |
mrussell |
I think it would be best if we had an overlap period so that people can test functionality/ workflow and give feedback on what features work best |
| 15:29 |
JBoyer |
I wonder how many of us are reading the last meeting's notes... :D |
| 15:30 |
gmcharlt |
so to spin a tale: maor testing in 3.10, possibly a non-default alt mode available in 3.10 (although I think I remember from berick that he doesn't think it would be easy to do that/) |
| 15:30 |
|
Guest4 joined #evergreen |
| 15:30 |
gmcharlt |
3.11 - fully relased; new interface is default but can switch back as needed |
| 15:30 |
gmcharlt |
3.12 - new interface only, the old one is actively removed |
| 15:31 |
gmcharlt |
(and I acknowledge that that is probably an aggressive timeline) |
| 15:31 |
terranm |
I seem to recall him saying that the code could be in there so that certain new elements could be available to other interfaces without the new patron interfaces being visible |
| 15:31 |
Bmagic |
That sounds pretty good to me |
| 15:31 |
JBoyer |
The first step proposed last time was non-ui stuff first since so many components have been updated, that could be 3.10 even if the alt-mode isn't available yet |
| 15:32 |
gmcharlt |
yeah, letting core component improvements in as early as possible would be good |
| 15:32 |
terranm |
+1 to that plan |
| 15:32 |
mmorgan |
+1 |
| 15:32 |
gmcharlt |
(and of course, calling out that Every. Last. One. Of. Us. would have to revamp circ desk training, directly or indirectly) |
| 15:33 |
terranm |
Yup |
| 15:34 |
Dyrcona |
+1 to the proposed timeline |
| 15:34 |
terranm |
Although, IMO the interfaces / workflows aren't all that different. I don't think they're as different as going from the embedded OPAC to the current staff client. |
| 15:34 |
JBoyer |
+1 |
| 15:35 |
shulabear |
terranm++ |
| 15:35 |
gmcharlt |
terranm: true, but the little differences can really catch folks, I suspect |
| 15:35 |
mmorgan |
gmcharlt++ |
| 15:35 |
terranm |
true |
| 15:35 |
terranm |
(And in the ways we least expect.) |
| 15:35 |
JBoyer |
terranm, yeah, the threat is that The Way Things are Done may be different enough between AngJS and Ang that this or that feature may not be 100% the same day one, even if present. |
| 15:36 |
mmorgan |
Practically everybody that works in a library will touch those screens, which is not necessarily true of other functions. |
| 15:36 |
gmcharlt |
and breaking people's muscle memory is a real concern |
| 15:37 |
mrussell |
As a cataloger I can attest that even the smallest change can completely throw us off our rhythm |
| 15:37 |
shulabear |
gmcharlt++ |
| 15:37 |
mmorgan |
mrussell++ |
| 15:37 |
mrussell |
gmcharlt ++ |
| 15:38 |
JBoyer |
I don't have a feel for how many frontline staff participate in BSW / FF, but maybe an extra callout to them would be a good idea |
| 15:38 |
terranm |
+1 |
| 15:38 |
gmcharlt |
hmm, and I just realized that Angular circ/app interesections with the next agenda item: standalone offline circ client |
| 15:38 |
JBoyer |
Depending on how that's handled it can be entirely separate and not intersect the client until the offline client is removed. |
| 15:39 |
gmcharlt |
i.e., either that the Angular patron/circ app needs to be taught how to work offline, else we're never getting rid of the AngularJS circ app, or we run with the standalone clinet idea |
| 15:39 |
JBoyer |
Oh, that angle, ok. |
| 15:40 |
shulabear |
I always try to get frontline staff in on BSW/FF, but depending on how busy they are impacts the feedback. |
| 15:40 |
terranm |
I'm in favor of whichever option allows us to download our blocked patrons list again. (No matter how limited we've tried to make it since moving to the web client, we've never been able to download it because it's too large.) |
| 15:41 |
shulabear |
terranm: That, yes. |
| 15:41 |
JBoyer |
Well, since we're discussing it, |
| 15:41 |
JBoyer |
#topic Should there be a standalone offline client? (see e.g. LP#1943486) |
| 15:42 |
JBoyer |
I'm basically landing at "Yes" |
| 15:42 |
JBoyer |
(unsurprisingly, given my comment) |
| 15:42 |
JBoyer |
hm, bot's on break. |
| 15:42 |
JBoyer |
LP1943486 |
| 15:43 |
terranm |
https://bugs.launchpad.net/evergreen/+bug/1943486 |
| 15:43 |
pinesol |
Launchpad bug 1943486 in Evergreen "Offline Circulation interface may not load under certain circumstances" [Undecided,Confirmed] |
| 15:43 |
mmorgan |
+1 to standalone, reliable client or app |
| 15:44 |
terranm |
See also: https://bugs.launchpad.net/evergreen/+bug/1727557 |
| 15:44 |
pinesol |
Launchpad bug 1727557 in Evergreen "Web Client: Download Block List causes unresponsive page with large file" [High,Confirmed] |
| 15:44 |
mmorgan |
Hmm. Also bug 1981841 |
| 15:44 |
pinesol |
Launchpad bug 1981841 in Evergreen "Offline Circulation Non-functional after Clearing Cache" [Undecided,Confirmed] https://launchpad.net/bugs/1981841 |
| 15:45 |
jeffdavis |
+1 to standalone here too. Current offline doesn't work for us in many scenarios - we didn't even point our libraries at it during our last upgrade. |
| 15:45 |
Bmagic |
berick had an interface somewhere |
| 15:45 |
JBoyer |
The question (quickly) becomes "Who has time to do this?" It's entirely possible that big chunks of the existing app can be dropped into an Electron container to get something started and the extra abilities it enables means that lovefield would be no longer necessary, but it's still a new thing for someone to build. |
| 15:46 |
Bmagic |
was it an extension of Hatch? IIRC |
| 15:46 |
JBoyer |
(The same could be said of a lot of things around here, but this seems fairly large.) |
| 15:47 |
Dyrcona |
I'm pretty sure berick's interface is its own thing, not related to Hatch. |
| 15:47 |
miker |
(I have to run away for a few minutes, bah!) |
| 15:47 |
gmcharlt |
does anybody have any experience with React Native? Asking because it might also address a potential need for a mobile-focused offline client |
| 15:49 |
|
jihpringle joined #evergreen |
| 15:49 |
jeffdavis |
If Bill or someone has the beginnings of something that's great, but even just agreeing as a community that we want to go in that direction would make it easier to arrange dev resources. |
| 15:50 |
Bmagic |
It seems like a desktop/native OS app (as opposed to a web app) is the clear way to go, as the web seems to still have some road blocks for offline (block list) |
| 15:50 |
JBoyer |
Sigh, haven't hit that key combo in a while... |
| 15:51 |
|
dbriem joined #evergreen |
| 15:51 |
Dyrcona |
Bmagic: I'm not so sure that a desktop application solves the blocklist download issue, but I'd have to take a closer look. |
| 15:52 |
Bmagic |
I thought it was a shortcoming of the lovefield local browser database capacity? |
| 15:52 |
Dyrcona |
#info berick's offline proof of concept: https://github.com/berick/eg-offline-jfx |
| 15:52 |
terranm |
We didn't used to have any problems downloading the blocklist in the old XUL offline client. I think it was just downloading it to a file back then? |
| 15:53 |
Dyrcona |
Bmagic: Could be. I haven't looked at the bug in a while. |
| 15:53 |
Bmagic |
me either :) |
| 15:53 |
Dyrcona |
terranm: Yes, that's correct. |
| 15:53 |
gmcharlt |
yeah, I would think that anything that can spin up a thread or background process to fetch what is just a text file, though sometimes a large one, should be OK |
| 15:54 |
terranm |
And not having it be subject to the vagaries of browser caching would be nice. |
| 15:55 |
|
Stompro joined #evergreen |
| 15:55 |
* Dyrcona |
imagined a user service that would run in the background and grab the offline block list automatically. |
| 15:55 |
terranm |
+1 |
| 15:56 |
terranm |
Getting library staff to remember to click the Download button back in the day was always a bit of a challenge. |
| 15:56 |
JBoyer |
To jeffdavis' point above before I screwed up my client again, it sounds like there is interest in this direction from the community. |
| 15:56 |
Bmagic |
we already have Hatch, whats another thing eh? My thinking was, why not piggy back on Hatch? Thereby preventing users from having to install two* things? |
| 15:56 |
JBoyer |
Which means we don't have to hash all of this out right now. |
| 15:57 |
gmcharlt |
Bmagic: a potential opportunity to try something that can remove the need to care about JVMs |
| 15:57 |
gmcharlt |
shall we move on to eslint? |
| 15:57 |
Bmagic |
sure |
| 15:57 |
JBoyer |
Does anyone have time to survey the landscape and report back next meeting? |
| 15:57 |
Bmagic |
(move on I mean) |
| 15:58 |
JBoyer |
If not we can always continue the discussion over email. |
| 15:58 |
JBoyer |
#topic Migrating away from the deprecated Angular linter (see LP#1959048) |
| 15:58 |
JBoyer |
(Requesting a review, and how to coordinate this with the large outstanding angular PRs?) |
| 15:58 |
sandbergja |
gmcharlt, thanks for your review! |
| 15:59 |
sandbergja |
it's the sort of branch that will go out of date quickly, so if anybody has the tuits for merging it, I would appreciate it |
| 15:59 |
gmcharlt |
yeah, from my POV it's ready to be merged; I don't anticipate much trouble adapting the angular acq branch to it |
| 15:59 |
sandbergja |
gmcharlt++ #that's good to hear! |
| 15:59 |
JBoyer |
sandbergja++ gmcharlt++ |
| 15:59 |
gmcharlt |
my only real question is whether we want to be brave and also backport it to 3.9 (though I don't think we want to be brave, honestly) |
| 16:00 |
sandbergja |
I was curious about the patron pieces (and other outstanding angular branches) |
| 16:00 |
sandbergja |
it feels kind of mean to change the goal post of how picky the linter is |
| 16:00 |
sandbergja |
after folks have put up a pullrequest |
| 16:01 |
sandbergja |
gmcharlt: I know that I'm not that brave :-) |
| 16:01 |
gmcharlt |
I think berick would be the main person not here who would be largely affected |
| 16:02 |
Dyrcona |
Given that berick is not here to comment, I'd say at a minimum we don't backport it. |
| 16:02 |
JBoyer |
Backporting to 3.9 may be unappealing, but there's not a good way to avoid existing PRs from being effected. I'm not sure it's run as often as it ought be anyway for many PRs. |
| 16:02 |
gmcharlt |
Dyrcona: yeah, I think the real question is timing of merging to the master branch |
| 16:03 |
gmcharlt |
(I raised the possibly of a backport mostly just in case somebody turned up who needed it; I'm not advocating for it) |
| 16:03 |
Dyrcona |
Perhaps the decision should be postponed until we can get feedback from berick? |
| 16:04 |
sandbergja |
I'm okay with that |
| 16:06 |
|
Guest340 joined #evergreen |
| 16:06 |
JBoyer |
sandbergja, would you like to stretch your new release team muscles and followup with berick about this either directly or via the dev list? |
| 16:06 |
sandbergja |
haha sure! |
| 16:06 |
JBoyer |
sandbergja++ |
| 16:07 |
mmorgan |
sandbergja++ |
| 16:07 |
JBoyer |
#action sandbergja will followup with berick about timing re: merging the new linter |
| 16:08 |
JBoyer |
ok, any further agenda lint lying around? |
| 16:08 |
sandbergja |
JBoyer: I see what you did there |
| 16:08 |
mmorgan |
:) |
| 16:08 |
* JBoyer |
winks, does finger guns |
| 16:09 |
JBoyer |
We're already a little over time, so |
| 16:09 |
JBoyer |
#topic Announcements |
| 16:09 |
JBoyer |
#info Next Meeting is October 11, 2022 |
| 16:09 |
JBoyer |
#endmeeting |
| 16:09 |
pinesol |
Meeting ended Tue Sep 13 16:09:25 2022 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:09 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2022/evergreen.2022-09-13-15.00.html |
| 16:09 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2022/evergreen.2022-09-13-15.00.txt |
| 16:09 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2022/evergreen.2022-09-13-15.00.log.html |
| 16:09 |
sandbergja |
JBoyer++ |
| 16:09 |
terranm |
JBoyer++ |
| 16:09 |
* mmorgan |
cleans the agenda lint filter before the next meeting |
| 16:09 |
collum |
JBoyer++ |
| 16:09 |
mmorgan |
JBoyer++ |
| 16:10 |
jeffdavis |
JBoyer++ |
| 16:11 |
miker |
JBoyer++ |
| 16:11 |
gmcharlt |
JBoyer++ |
| 16:11 |
miker |
what'd I miss? did we finish Evergreen? |
| 16:11 |
Dyrcona |
JBoyer++ |
| 16:12 |
Dyrcona |
sandbergja++ mmorgan++ terannm++ gmcharlt++ |
| 16:12 |
Dyrcona |
miker: We voted to rewrite it all in Java. |
| 16:12 |
Dyrcona |
:) |
| 16:13 |
miker |
Dyrcona: perfect, I can retire! :) |
| 16:13 |
Dyrcona |
:) |
| 16:20 |
Bmagic |
JBoyer++ |
| 16:28 |
|
jihpringle joined #evergreen |
| 16:29 |
pinesol |
News from commits: Docs: adding Global Flags documentation <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9efa68b538ad5bd3b66d5aaed4c4ce3a00897e1d> |
| 16:32 |
|
Dyrcona joined #evergreen |
| 16:45 |
|
jihpringle joined #evergreen |
| 16:55 |
|
jvwoolf left #evergreen |
| 17:07 |
|
mmorgan left #evergreen |
| 17:29 |
pinesol |
News from commits: LP#1989348: set default new record via route data <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=247b7164c80faca7f5aae50db907c6984c396b36> |
| 17:29 |
pinesol |
News from commits: LP#1920268: properly align titles in Bootstrap search results, regardless of cover art <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=33b1cbad7609d9d621313dc393ec3282960491ca> |
| 17:36 |
|
Stompro joined #evergreen |
| 21:00 |
|
stephengwills left #evergreen |
