| 09:09 |
|
jvwoolf joined #evergreen |
| 09:12 |
Rogan |
kmlussier morning |
| 09:12 |
Rogan |
mmorgan morning to you too! |
| 09:15 |
Dyrcona |
What I'm doing to copy acq data for testing the SFTP stuff works with a branch updated to main, but on 3.7.4 the legacy acq po view becomes unresponsive. |
| 09:21 |
Dyrcona |
Maybe acq is just unresponsive on this test system? |
| 09:23 |
Dyrcona |
This po has 17 lineitems. It shows 1, then after a minute or so I get the "this page is unresponsive" dialog. |
| 09:23 |
Dyrcona |
It would be nice if the dev tools would open. It's that unresponsive. |
| 09:25 |
Dyrcona |
Got the console open and nada. |
| 09:53 |
|
sleary joined #evergreen |
| 10:02 |
|
jvwoolf joined #evergreen |
| 12:05 |
|
jihpringle joined #evergreen |
| 12:07 |
Dyrcona |
So, I'm doing the restore again because my test data load blew up. |
| 13:32 |
|
jvwoolf joined #evergreen |
| 13:52 |
Dyrcona |
Nope. Acquisitions is still busted. I think this db/vm combinations just can't deal with it. |
| 13:56 |
Dyrcona |
"GET /js/dojo/openils/acq/nls/en-us/acq.js HTTP/1.0" 404 That's no big deal, right? That's just looking for the translated files, isn't it? |
| 14:00 |
Dyrcona |
ha! Rickie Lee Jones sings, "It's more trouble than it's worth." |
| 14:02 |
Dyrcona |
I also tried autogen.sh because I think org units might have changed after the restore. |
| 14:05 |
Dyrcona |
Ok. Now, I sign in with a different workstation, and it takes me straight to workstation registration. If I try to add this workstation, it says the workstation already exists. It shows me with no working location in the green bar. |
| 14:10 |
JBoyer |
Sometimes I still need to wipe out the browser's localstorage when a test system has been rebuilt, especially if the workstation names and ids no longer match up. |
| 14:10 |
Dyrcona |
jBoyre I'll try that. I have disable cache with dev tools turned, but that's not local storage, is it? :) |
| 14:13 |
Dyrcona |
JBoyer++ That fixed it. |
| 14:13 |
JBoyer |
\o/ |
| 14:41 |
Dyrcona |
The Dojo stuff can't go away too soon for me. |
| 14:41 |
Dyrcona |
kmlussier++ |
| 14:41 |
kmlussier |
Dyrcona: Agreed. |
| 14:42 |
Dyrcona |
JBoyer: You might be pleased to know that retrieved an EPO via SFTP on my test server again today, despite my issues with the legacy acq interface. |
| 14:43 |
Dyrcona |
I suppose I'll try the invoice for this po, too. |
| 14:43 |
kmlussier |
We're all pleased to know that, Dyrcona. :) |
| 14:43 |
kmlussier |
Dyrcona++ |
| 09:35 |
Dyrcona |
Don't try this in production, kids: evergreen=# select cwmars.delete_acq_purchase_order(id) from acq.purchase_order; |
| 09:35 |
JBoyer |
FYI, if you haven't seen it yet there's an angular rewrite of the reporter on butternut.evergreencatalog.com (and a reports security improvement). Would be great to see one or both of these land in 3.13! |
| 09:39 |
Dyrcona |
Maybe I should have added " where state = 'pending'" It's taking a while. |
| 09:45 |
Dyrcona |
Is there a good way to disable EDI accounts in acq? Doesn't look like there's an active flag. I want to test EDI with SFTP on just a couple of accounts. |
| 09:46 |
Dyrcona |
Hah! I just realized that I'm running that function above in the wrong database. It's running "evergreen" and I was setting this up in "jasontest." |
| 09:47 |
abneiman |
Bmagic: can you please see if docs build broke again? I'm looking for things I put in earlier this week & I see the files in git but I'm not seeing the updates on the webpage(s) |
| 09:48 |
abneiman |
alternatively, pls let me know if I broke docs, lol |
| 11:10 |
pinesol |
Launchpad bug 1525394 in Evergreen "SIP patron part level holds respond blank" [Undecided,Confirmed] https://launchpad.net/bugs/1525394 - Assigned to Chris Sharp (chrissharp123) |
| 11:29 |
csharp_ |
berick: sick with a cold - feel free to grab it |
| 11:30 |
berick |
csharp_: ugh! |
| 11:30 |
csharp_ |
berick: I was able to test parts holds and the fix works, but I was never able to figure out how one places an issuance hold |
| 11:30 |
berick |
ohh, that's the one you were looking at before.. thanks for the info |
| 11:30 |
berick |
i'll see what I can do |
| 11:30 |
csharp_ |
thanks |
| 12:35 |
|
dickreckard joined #evergreen |
| 13:01 |
Dyrcona |
Well, I simplified things by getting my data transfer to work with \copy, so I don't have to copy the files to the database server. I am still working on foreign key constraints, though. Every time I add a new table, I come up with another fkey relationship that I have to add to the queries. |
| 13:01 |
Dyrcona |
Acq is complicated. |
| 13:04 |
Dyrcona |
Oh! That acq.purchase_order delete finished. It actually succeeded in deleting all of the purchase orders in that test database. |
| 13:32 |
pinesol |
News from commits: LP1525394 moving toward fixing SIP hold titles <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=7775c5e1dcd74c354f249849c863d774f339b5d9> |
| 13:32 |
pinesol |
News from commits: LP1525394: Return Titles for All Hold Types in SIP <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=ffec39a79bd09ba5ba7223f13c455d56e0ec277b> |
| 13:32 |
pinesol |
News from commits: LP1525394 SIP patron part level holds respond blank <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=91a5ea4345d7822169688ab85c4037f817887dfe> |
| 15:56 |
berick |
e.g. https://bugsquash2.mobiusconsortium.org/eg2/en-US/staff/acq/po/9 |
| 15:57 |
berick |
btw there's enough seed data in EG to create a new PO, add a brief record, add one copy, add a price, then activate |
| 15:59 |
Dyrcona |
berick++ |
| 15:59 |
berick |
well, more configs needed for actually testing the sftp part |
| 15:59 |
berick |
edi configs, etc. |
| 15:59 |
Dyrcona |
I'm using production data copied to an older produciton database. I had to check "Allow Activation with Zero-Item Line Items?" |
| 16:00 |
Dyrcona |
Yeah, I've switched the host fields for the provider/edi accounts that I'm testing. |
| 16:01 |
Dyrcona |
Are items actually created in the asset.copy table? Should l look for those and pull them over? I notice that there are links to the biblio.record_entry table. |
| 16:04 |
Dyrcona |
Yeah, I guess they are. I should pull that data over too, I suppose. |
| 16:05 |
Dyrcona |
I've been trying to get the data from the auditor tables before the purchase order was activated, so I suppose I should check the auditor tables in the case of a po that has been received? |
| 16:08 |
berick |
and you won't need "Allow Activation with Zero-.." if you just add a copy to the order |
| 16:16 |
Dyrcona |
berick: Uh-huh. Considering I'm happier in the database than the interface, I disagree with you. :) |
| 16:16 |
berick |
hah! gotcha |
| 16:19 |
Dyrcona |
I've got a test system with production data upgraded to main as of a week ago or so. The data is two weeks or more old, so I'd like to test with that. I've got another machine with an account set up to use for SFTP. I reckon I can generate POs and send them there, then grab the ORDRSP message from production, throw that file over on the SFTP vm and see if the fetcher can get it. |
| 16:26 |
Dyrcona |
Looks like i should also grab lineitem_detail, asset.copy and asset.call_number. |
| 16:31 |
|
jvwoolf joined #evergreen |
| 16:34 |
Dyrcona |
And, I need to grab acq.fund_debit as well. |
| 16:41 |
Dyrcona |
i suppose I can set the fund and fund_debit to null in lineitem_detail... I'll give that a try. |
| 16:43 |
Dyrcona |
berick: Should pull the asset.copy and call number through lineitem_detail, or should I null those fields, too? (I guess I could plumb the code to find out.) |
| 16:49 |
Dyrcona |
Ooh. I activated the order... |
| 16:49 |
Dyrcona |
Guess I have time to run the order push to see if the message goes to my test vm. |
| 16:53 |
Dyrcona |
Nope. no file got sent over. |
| 16:56 |
Dyrcona |
Right the edi_message was created but remote file is blank. I guess i'll pick this up on Monday. |
| 16:56 |
Dyrcona |
Have a great weekend, everyone! |
| 07:31 |
|
collum joined #evergreen |
| 07:59 |
|
BDorsey joined #evergreen |
| 08:23 |
JBoyer |
dickreckard, I've helped with some upgrades that skipped about that many versions, there are only a couple places that things could get weird or take a long time, |
| 08:23 |
JBoyer |
and if you setup a test database (you don't even need the newer version of Evergreen running to test the upgrade scripts) you should be able to plan for all of those. |
| 08:24 |
JBoyer |
And since all of the upgrade scripts either work or don't you don't have to worry about the db being left in a hard-to-debug state. |
| 08:28 |
|
Dyrcona joined #evergreen |
| 08:31 |
|
mantis joined #evergreen |
| 09:19 |
Bmagic |
dickreckard: I would go with the sql script upgrade approach. It would be much less time consuming |
| 09:20 |
JBoyer |
Well, for example, if you run the 3.2.2-3.2.3-upgrade-db.sql script, it will either work entirely leaving your db as expected for a 3.2.3 system, or it will fail and tell you what went wrong so you can fix the issue and then run the script again. |
| 09:20 |
JBoyer |
And if an upgrade fails, it rolls back every change it tried to make, so you'd be left with the same 3.2.2 db that you had before trying to apply the update. |
| 09:22 |
Bmagic |
JBoyer speaks truth! And I'll echo him: we always practice the upgrade SQL scripts on a test copy of the database in order to see which ones fail and why. Make the required adjustments to the SQL scripts to fit our database needs. Most* of the time we don't have to make changes. You won't know until you try |
| 09:23 |
|
dguarrac joined #evergreen |
| 09:30 |
Dyrcona |
dickreckard: Do you have access to another PostgreSQL database where you can test the database upgrade? |
| 09:33 |
|
smayo joined #evergreen |
| 09:33 |
* Bmagic |
waves at smayo |
| 09:34 |
|
jvwoolf joined #evergreen |
| 09:36 |
jvwoolf |
Bmagic++ |
| 09:36 |
jvwoolf |
#1 hype man |
| 09:37 |
Bmagic |
Can I get an Eeeeee! |
| 09:37 |
Dyrcona |
So, fun with autorenewals on a test system: 1 failed to renew last night because the circ drone couldn't get a transaction. Nothing in the Pg logs about it, except "there is not transaction in progress." |
| 09:37 |
smayo |
Eeeeee |
| 09:37 |
Dyrcona |
Very next autorenew event gets an error state, but from looking at the database and the logs, it actually succeeded. Both process by the same trigger drone. |
| 09:38 |
jvwoolf |
https://www.youtube.com/watch?v=0ipbu4msLSw |
| 09:38 |
dickreckard |
Bmagic: Dyrcona JBoyer, yes will go with the test db! thank you all for help :) |
| 09:38 |
Dyrcona |
No reason at all for the second to have the state='error'. |
| 09:39 |
Bmagic |
jvwoolf++ # love that battle cry |
| 09:39 |
Dyrcona |
dicreckard: I recommend you try this: https://gist.github.com/Dyrcona/00bd6b6290b6fbbb579c7f93b360ab0d It will create a database upgrade script between two arbitrary Evergreen versions. It requires git, and I guarantee the script will not work on the first try. |
| 09:56 |
Dyrcona |
Both events have the same update_time: 2024-03-21 05:43:13.394412-04. I think that might be significant. That they're being updated at the same time. |
| 10:04 |
Bmagic |
terranm++ # lol, good to know that yall know what I would type so you know when to be suspicious hahaha |
| 10:05 |
terranm |
Bmagic++ |
| 10:10 |
Bmagic |
csharp_: https://bugsquash3.mobiusconsortium.org is up and running at your service. I did login and test placing a hold and it worked! bugsquash2 has several patches that are candidates for having broke holds. I'll figure out which one and post on the bug |
| 10:15 |
|
kworstell_isl joined #evergreen |
| 10:16 |
|
kworstell_isl_ joined #evergreen |
| 10:24 |
Dyrcona |
ooh. got a real dead lock in a test system on Sunday: Process 3401997 ... blocked by process 3402007. ...Process 3402007 ... blocked by process 3401997. |
| 10:26 |
Dyrcona |
Looks like the hold targeter blocked a process trying to reindex the action.hold_request table and vice versa. |
| 10:26 |
* Dyrcona |
changes the hold targeter schedule. |
| 10:27 |
|
kworstell-isl joined #evergreen |
| 10:48 |
|
sleary joined #evergreen |
| 10:49 |
Rogan |
dickreckard I'm late to the party but echo jboyer's statement, just exporting isolated tables and reimporting them will be a bigger pain than the sql upgrades and you will lose a lot of data |
| 11:01 |
Dyrcona |
pg_dump/pg_restore usually does not work if the schema has changed. |
| 11:02 |
kenstir |
Can I get a clue how to set up my test server for Stripe payments? I have a stripe account, and I used the library settings editor to add things to BR1, but the BR1 patron with a fine does not see any "pay fines" button. Screenshot: https://launchpadlibrarian.net/720500896/2024-03-20-Library-Settings-Editor.png |
| 11:04 |
Dyrcona |
kenstir: You added your test settings for stripe and enabled stripe as the cc processor? If so, you should be able to "pay" with one of the stripe test cards. See the strip documentation. |
| 11:05 |
kenstir |
Dyrcona Yes I did but the issue is I don't see any pay button in EG when logged in as the patron. I do see the fine. |
| 11:06 |
Dyrcona |
you restarted services and apache2 after making the settings changes? they don't always have an immediate effect. |
| 11:06 |
mmorgan |
kenstir: Did you set the library setting Allow Credit Card Payments (credit.payments.allow) to TRUE also? |
| 14:10 |
berick |
Dyrcona: yeah, and I'll probably be poking at https://opensearch.org/ before too long as an Elastic replacement. |
| 14:12 |
jeffdavis |
Are we ok to officially recommend disabling JIT in Postgres? I don't recall if anyone had reservations about turning it off. (bug 2042158) |
| 14:12 |
pinesol |
Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [Undecided,Confirmed] https://launchpad.net/bugs/2042158 - Assigned to Galen Charlton (gmc) |
| 14:18 |
Dyrcona |
jeffdavis: I have reservations about turning it off, but I have not made them public. If we have queries that cause issues with the JIT we should probably fix the queries. I have not turned off JIT in my Pg 15 and Pg 16 test databases and I've not encountered the issue described in the bug. All of that said, don't let just me stop anything from going forward. |
| 14:23 |
Dyrcona |
Speaking of PostgreSQL settings, this is mainly for Bmagic: I think I'm going back to 1.1 for random_page_cost. A couple of queries that I've run since setting it to 1.0 seem slower. |
| 14:25 |
Dyrcona |
... on Pg10 anyway. |
| 14:40 |
JBoyer |
I haven't weighed in much on that or had much time to do much lately but feel the same as Dyrcona re: turning off the JIT unconditionally. |
| 09:29 |
* mmorgan |
tries to grab any of kmlussier's tuit cookies that remain |
| 09:29 |
Dyrcona |
Huh.... websocketd-osrf.service got disabled somehow. I've seen systemd disable user services after an update, but not system services.... |
| 09:30 |
Dyrcona |
systemd-- |
| 09:35 |
Dyrcona |
Nooooo! All that work and the test system still looks different from production. I even remade a new test branch in exactly the same way as production. |
| 09:35 |
Dyrcona |
i wonder if there's a template change in production that doesn't appear in the override folders? That has to be it. |
| 09:39 |
Dyrcona |
Nope. I just copied the production templates to my custom branch and `git diff` does nothing. |
| 09:47 |
Dyrcona |
git status say everything up to date. |
| 10:10 |
|
jvwoolf joined #evergreen |
| 10:10 |
|
mmorgan joined #evergreen |
| 10:11 |
Dyrcona |
This sort of thing drives me nuts. |
| 10:29 |
Dyrcona |
OK, so it looks like the difference is that templates/bootstrap/opac/parts/cart_nav.tt2 is displaying on the test system but not in production, even though it looks like it ought to display on both given what the templates all look like..... |
| 10:32 |
|
Christineb joined #evergreen |
| 10:36 |
csharp_ |
templates-bootstrap, you mean? |
| 10:36 |
csharp_ |
(wondering if the path is wrong) |
| 10:37 |
Dyrcona |
csharp_: You're correct. I can't type in chat. |
| 10:38 |
csharp_ |
btw, I'll state for the record that I don't like having templates and templates-bootstrap - seems like the bootstrap versions could be an option to symlink to or something and just have "templates", but it's ok |
| 10:38 |
Dyrcona |
What it looks like is production is rendering templates-bootstrap/opac/parts/topnav_subnav.tt2 differently than the test machine. |
| 10:38 |
csharp_ |
gotcha |
| 10:39 |
csharp_ |
@who is in charge of writing things down in The Record? |
| 10:39 |
pinesol |
eeevil is in charge of writing things down in The Record. |
| 10:42 |
JBoyer |
Dyrcona, any chance apache config stuff is an issue? |
| 10:43 |
Dyrcona |
JBoyer: The overrides are in different paths, but the Apache stuff is pretty much the same. |
| 10:44 |
Dyrcona |
I've eyeballed the eg_vhost.confs, but I'll diff them. |
| 10:47 |
Dyrcona |
OK. i difference: templates_cons (the override) comes before templates-bootstrap in production. On my test system both of the overrides come after the stock directories. I'll swap those and see what happens. |
| 10:47 |
Dyrcona |
s/i/1/ |
| 10:48 |
Dyrcona |
JBoyer++ That was it! |
| 10:49 |
Dyrcona |
csharp_++ too. |
| 11:03 |
|
kenstir joined #evergreen |
| 11:04 |
terranm |
As long as we close more bugs than we open |
| 11:19 |
|
mantis joined #evergreen |
| 11:19 |
mantis |
getting a 500 internal error when signing into the OPAC on MOBIUS test server 1 |
| 11:24 |
pinesol |
News from commits: LP#2052567: allow Reports to load when BitWarden plugin is active <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=d3c203d3a1875f74a0ffe2db4431b49eb4564d3c> |
| 11:27 |
|
jvwoolf1 joined #evergreen |
| 11:34 |
Bmagic |
mantis: I might have been restarting apache at that moment (updating it for Czech language) - it's working for me at the moment |
| 11:36 |
mantis |
got it! thanks! |
| 11:37 |
csharp_ |
working on testing bug 1525394 and I have verified that part-holds now work, but we don't use serials and I'm not sure how to test issuance holds :-/ |
| 11:37 |
pinesol |
Launchpad bug 1525394 in Evergreen "SIP patron part level holds respond blank" [Undecided,Confirmed] https://launchpad.net/bugs/1525394 - Assigned to Chris Sharp (chrissharp123) |
| 11:38 |
csharp_ |
Bmagic: do you know if issuance holds are possible on your testbox with that fix on it? |
| 11:39 |
Bmagic |
I'm fuzzy on "issuance holds" but I don't see why the system wouldn't be able to do it. It's mostly stock Evergreen main |
| 11:47 |
Bmagic |
I spelled a couple of those wrong, lol |
| 11:49 |
Bmagic |
terranm: https://bugsquash2.mobiusconsortium.org/eg2/en-US/staff/catalog/search?org=1&limit=10&query=a&fieldClass=keyword&joinOp=&matchOp=contains&format=serial&dateOp=is&ridx=0 |
| 11:56 |
jeffdavis |
I'm a little disappointed to learn that Cat Fancy magazine has rebranded as Catster |
| 11:58 |
csharp_ |
Bmagic: actually I've been testing on our own server, but thanks for the connection info - I'll give yours a shot |
| 11:59 |
csharp_ |
jeffdavis++ |
| 12:00 |
terranm |
Bmagic++ jeffdavis++ |
| 12:01 |
collum |
Bmagic: in the url change query=a to query=* |
| 12:01 |
collum |
There's a few more. |
| 15:20 |
|
kmlussier joined #evergreen |
| 15:22 |
|
smayo joined #evergreen |
| 15:31 |
|
mantis left #evergreen |
| 15:45 |
csharp_ |
ok, next time anyone asks why the bugs aren't getting signed off on, please remember that it can take a lot of time and effort just to set up a test case! |
| 15:46 |
csharp_ |
I've spent 2+ hours today just trying to figure out enough serials to create an issuance hold to test the "no part holds showing up in SIP2" bug :-/ |
| 15:46 |
csharp_ |
(still not there) |
| 15:47 |
csharp_ |
and it might be sunk cost fallacy at this point, but I'll be damned if I don't figure this out and commit the fix |
| 15:48 |
|
kworstell-isl joined #evergreen |
| 15:50 |
Dyrcona |
csharp_++ |
| 15:51 |
Dyrcona |
I'm in a similar boat with the SFTP EDI stuff. I'm trying to figure out enough acq to set up test orders and pregenerated responses. |
| 15:56 |
csharp_ |
where is tlittle when we need her in this hour of need? |
| 15:57 |
csharp_ |
Bmagic: is all well with the bugsquash2 server? I'm suddenly stuck |
| 15:57 |
* csharp_ |
weeps |
| 15:59 |
Bmagic |
try hitting it from another VM to confirm? |
| 16:04 |
csharp_ |
Bmagic: looks ok now - thanks for checking |
| 16:04 |
Bmagic |
ok great |
| 16:17 |
csharp_ |
Bmagic: on bugsquash2, when I try to place a hold on Catster magazine after creating a holdable copy, I'm getting an empty red error box and this in the console: "ERROR TypeError: t.lastRequest.result.evt is null" - can you confirm? |
| 16:17 |
csharp_ |
I'm able to place the hold on my own test server running main-ish |
| 16:17 |
Bmagic |
checking |
| 16:17 |
csharp_ |
placing the hold for Sarah Smith |
| 16:18 |
csharp_ |
holdable copy barcode is "chrisistesting" |
| 16:19 |
csharp_ |
(my own server doesn't have the SIP2 port open on the ITS-administered firewall, so I can't test there) |
| 16:20 |
csharp_ |
however, I guess I'm now wondering if the item I attached is in fact an "issuance" |
| 16:20 |
Bmagic |
hold rule matrix is in the way I think |
| 16:20 |
csharp_ |
ah |
| 16:20 |
Bmagic |
result: Object { success: false, evt: null } |
| 16:46 |
Bmagic |
bugsquash3 will end up being a tomorrow thing if you'll still be around? |
| 16:47 |
csharp_ |
yeah, I'll be here - no biggie |
| 16:47 |
Bmagic |
I'm excited about sqaushing this one! |
| 16:47 |
csharp_ |
and I have a PINES-ish server to test - but it probably needs even more serials setup than enhanced concerto since we've never used it |
| 17:09 |
|
mmorgan left #evergreen |
| 17:15 |
|
sleary joined #evergreen |
| 18:59 |
|
jihpringle joined #evergreen |
| 12:39 |
|
kworstell_isl joined #evergreen |
| 12:52 |
Dyrcona |
And, now, there's a BIOS update. Might as well install that, too. |
| 13:00 |
|
Dyrcona joined #evergreen |
| 13:17 |
Dyrcona |
I'm looking at Lp 2040514. Does anyone have any tips for testing SFTP for EDI? I'm planning to set up one of my VMx to be the SFTP server. I'm wondering where I can look for actual messages to send back and forth. I'm pretty sure the actual EDI gets stored in the database somewhere. |
| 13:17 |
pinesol |
Launchpad bug 2040514 in Evergreen "EDI SFTP doesn't work" [High,In progress] https://launchpad.net/bugs/2040514 - Assigned to Jason Stephenson (jstephenson) |
| 13:18 |
|
kworstell_isl_ joined #evergreen |
| 13:29 |
|
jvwoolf joined #evergreen |
| 15:01 |
Bmagic |
#info mmorgan will explore moving LP stats to community site and automating same |
| 15:01 |
mmorgan |
Please carry forward. Wanted to also note that some of today's stats came from the Launchpad API. |
| 15:02 |
Bmagic |
#action mmorgan will explore moving LP stats to community site and automating same |
| 15:02 |
Bmagic |
#info sandbergja will see if gh actions can run the pgtap tests |
| 15:02 |
sandbergja |
I have a pullrequest for that, bug 2055796 |
| 15:02 |
pinesol |
Launchpad bug 2055796 in Evergreen "Have github actions run pgtap tests for us" [Undecided,New] https://launchpad.net/bugs/2055796 |
| 15:02 |
Bmagic |
sandbergja++ |
| 15:02 |
smayo |
sandbergja++ |
| 15:02 |
dluch |
sandbergja++ |
| 15:05 |
|
collum joined #evergreen |
| 15:05 |
Bmagic |
#action gmcharlt - create a Git commit message type and update bug 2051946 |
| 15:05 |
pinesol |
Launchpad bug 2051946 in Evergreen "institute a Git commit message template" [Wishlist,New] https://launchpad.net/bugs/2051946 - Assigned to Galen Charlton (gmc) |
| 15:05 |
Dyrcona |
Looks like it is in progress. I tested the other branch that makes release notes entries. |
| 15:05 |
eeevil |
gmcharlt_ is traveling today, aiui. |
| 15:05 |
Bmagic |
ah, cool |
| 15:05 |
Bmagic |
#info Stompro will formalize the tense usage in the release-note message |
| 15:13 |
sandbergja |
Dyrcona++ |
| 15:13 |
eeevil |
re the first part, I think that's smart (and then the release can get the squashed bugs) |
| 15:13 |
Bmagic |
+1 (and I can help with the building(s)) |
| 15:13 |
abneiman |
+1 to 27th, I can test & eval the release-notes script as part of point releases |
| 15:13 |
mmorgan |
+1 to March 27, I can help also. |
| 15:14 |
sandbergja |
Bmagic++ |
| 15:14 |
sandbergja |
abneiman++ |
| 15:23 |
Bmagic |
#topic New Business - Barriers to getting things committed |
| 15:23 |
jeffdavis |
I can start this off |
| 15:23 |
Bmagic |
please do |
| 15:23 |
jeffdavis |
I want to commit more pullrequests, but when I try, I often run into the same barriers: |
| 15:23 |
jeffdavis |
(1) no test environment available, (2) no test plan, (3) test plan is difficult to set up, (4) merge conflicts, esp with code that has sat uncommitted for months, (5) extra overhead required to backport and/or unsure whether to backport, (6) unresolved questions about the fix. |
| 15:23 |
jeffdavis |
I wonder if there are things we can be doing to mitigate some of those barriers? |
| 15:23 |
jeffdavis |
For example, would more community dev VMs be helpful? |
| 15:24 |
Dyrcona |
For 5 we can backport fewer fixes, particularly those that touch the database. |
| 15:24 |
Bmagic |
I think the answer is: yes |
| 15:24 |
Bmagic |
do we need a system for people to "checkout" a VM so it's their's for a time? |
| 15:25 |
sandbergja |
It seems that if we address some of the others, 4 might take care of itself (i.e. if we have a quicker commit cadence, branches won't sit for as long) |
| 15:25 |
abneiman |
4 is a problem, but especially a chicken-and-egg thing since the longer things sit without review the more conflicts they accumulate. For 2, I can commit to sharing test plans for Equinox-developed features. |
| 15:25 |
Bmagic |
we could use Evergreen to manage the checkouts |
| 15:25 |
abneiman |
sandbergja: great minds, lol |
| 15:25 |
Dyrcona |
i also think it is perfectly fair to comment on the bug that there is no test plan provided, and it's not obvious how to test the bug. |
| 15:26 |
Dyrcona |
For 4, it's also perfectly fine to ask the original developer to rebase it, or at least comment that it needs a rebase if you're not comfortable doing it yourself. |
| 15:26 |
sleary |
If you are the person rebasing it, and the merge conflicts have to do with CSS or ARIA, please ping me here and I'll be happy to help. |
| 15:27 |
abneiman |
+1, asking for dev rebases is totally fair game |
| 15:27 |
abneiman |
sleary++ |
| 15:27 |
jeffdavis |
I've also shared pullrequests and had to rebase them multiple times, which gets frustrating, so asking the dev to rebase is fair but only goes so far IMO. |
| 15:28 |
abneiman |
so it sounds like we really have 4 communications problems, 1 technical problem (test environments), and 1 practice problem (when do we backport?) |
| 15:28 |
Dyrcona |
jeffdavis: I do try to handle the rebases myself, but sometimes, its not obvious how to resolve it. |
| 15:29 |
mmorgan |
abneiman++ |
| 15:29 |
jeffdavis |
abneiman: great point |
| 15:29 |
kmlussier |
Often, when somebody asks for a rebase, it's during a rare moment when the tester has time to look at the code. If the person doesn't rebase it quickly, that person may no longer be available to test. Not so much a communications problem, but a tuits problem. |
| 15:30 |
Dyrcona |
I think that's more of a time problem. Most of us have "other jobs" or at least our job has more requirements than working on Evergreen code. |
| 15:30 |
dluch |
abneiman++ |
| 15:31 |
abneiman |
perhaps if a tester and a dev had a quick conversation, though, everyone's time could be used more valuably - "hey I'm planning to test this in $timeframe, do you mind looking at a rebase?" "I can do rebase within $possibleothertimeframe and let you know when it's done" etc etc |
| 15:32 |
mmorgan |
I think the code review sessions have been great for getting folks together to tackle individual bugs, whatever their issues. |
| 15:32 |
abneiman |
code review is GREAT for this |
| 15:32 |
abneiman |
sandbergja++ |
| 15:32 |
sleary |
sandbergja floated the idea of a rebasing party during the code review meeting on Monday. If people would like to do that this Friday, I can be available to help out with all the UI stuff that changed in the last couple of versions. |
| 15:33 |
dluch |
redavis: that's a good thought! |
| 15:33 |
redavis |
sandbergja++ sleary++ |
| 15:33 |
abneiman |
don't want to lose terranm 's point about devs / committers being engaged with BSW |
| 15:33 |
abneiman |
that's a time when a critical mass of people are testing, etc. |
| 15:33 |
sleary |
terranm++ |
| 15:33 |
Bmagic |
agreed |
| 15:33 |
redavis |
agreed |
| 15:39 |
Bmagic |
:), nevermind on the winding down |
| 15:39 |
kmlussier |
Oh, my. That's an old bug. I even have comments on it. |
| 15:39 |
abneiman |
Dyrcona: curious if you have an alternate suggestion? |
| 15:40 |
mmorgan |
Regarding test environments - community ones that can be checked out exclusively would be great |
| 15:40 |
terranm |
Maybe we need to have a needsdiscussion cleanup party, too |
| 15:40 |
redavis |
Bmagic++ mmorgan++ |
| 15:40 |
sleary |
terranm++ |
| 15:45 |
dluch |
We might be able to help with VMs...have to discuss internally, though |
| 15:45 |
abneiman |
Monthly half-day open code reviews or the like, with rotating responsibilty for hosting / VMs? |
| 15:45 |
csharp_ |
Bmagic: for me/us, the networking piece is an issue - PINES/GPLS machines are behind a finicky firewall :-/ |
| 15:45 |
Dyrcona |
We're supposed to be requiring test plans and release notes, so enforce that. (I've been adding them for my recent branches.) |
| 15:45 |
csharp_ |
but we can talk logistics at that level later |
| 15:45 |
abneiman |
and a committment from each senior committer to attend 1 per year or something |
| 15:46 |
kmlussier |
abneiman: I think a middle way is desireable. Smaller and more consistent contributions is a better approach than a mass of contributions / review happening at the same time. |
| 15:49 |
csharp_ |
it's not just a matter of time/tuits - I just need to develop better habits |
| 15:49 |
abneiman |
I'm just trying to think about ways to spread the load - if more people are doing things, we're relying less on the community unicorns (you know who you are lol) to shoulder so much |
| 15:50 |
dluch |
++ |
| 15:50 |
Dyrcona |
I've also been burned by not testing some big things thoroughly enough, so I like to set aside at least a day to test even small things. |
| 15:50 |
redavis |
(if you're in this meeting, you're a community unicorn) |
| 15:50 |
Bmagic |
redavis++ |
| 15:50 |
sleary |
kmlussier gmcharlt_ went over things with me, but I don't think there is much written down in the wiki on going from contributor to committer |
| 15:51 |
csharp_ |
🦄🦄🦄 |
| 15:51 |
kmlussier |
redavis: No, I'm just here because I like talking to all of you. |
| 15:51 |
Bmagic |
we're coming up on our hour yall |
| 15:51 |
sandbergja |
Dyrcona made me think of something that would be helpful for me: if there is a way we could run the tests against each pull request automatically. |
| 15:51 |
Dyrcona |
kmlussier: If you do want the commit bit back, just let me know. I can do it without a vote. :) |
| 15:51 |
sandbergja |
That green checkbox in Github saying "your tests passed" really helps me in other open source projects |
| 15:52 |
kmlussier |
redavis brought up earlier the idea of talkng about this at the hackfest. I've been thinking it might be worthwhile to have a monthly meeting where we could focus on one problem we want to solve. Because we could talk about this all day. |
| 15:52 |
Bmagic |
sandbergja: yes! a container that lauches with a branch and runs the test and dumps the results |
| 15:52 |
* csharp_ |
feels us teetering on the edge of the "move Git" discussion - keep his mouth shut |
| 15:52 |
sandbergja |
it wouldn't catch everything for sure, but it would provide a bit of a confidence boost |
| 15:52 |
kmlussier |
Dyrcona: I won't ask for it back unless I know I have the time to contribute. |
| 15:55 |
Bmagic |
https://wiki.evergreen-ils.org/doku.php?id=versioning |
| 15:55 |
jeff |
Are we talking about freshening up the examples and the OpenSRF / PostgreSQL deps? |
| 15:55 |
Bmagic |
ok, good idea, mailling list |
| 15:55 |
abneiman |
OTOH I think more automated testing is always going to be a good thing but I will not teeter us into "move git" today |
| 15:55 |
sleary |
move Git tomorrow ;) |
| 15:55 |
Bmagic |
#topic New Business - Possible hackfest (or other date) discussion on Evergreen releases - see email (Kathy) |
| 15:55 |
Bmagic |
#link http://list.evergreen-ils.org/pipermail/evergreen-dev/2024-February/000740.html |
| 13:48 |
jeffdavis |
Maybe that is a conference/hackfest discussion though. |
| 13:50 |
jeffdavis |
And maybe the recent work on improving our release process has exhausted our appetite for other process discussions. :) |
| 13:50 |
Dyrcona |
jeffdavis: Time... I need a clone. |
| 13:50 |
* sleary |
is always here for process discussions |
| 13:51 |
sleary |
At the last New Devs meeting, a lot of people said they had trouble just setting up test systems to work on. Docker helps, but it requires a ton of resources. |
| 13:52 |
sandbergja |
Bmagic: is node --version 16 or above on that box? |
| 13:56 |
Bmagic |
sandbergja, nope, 12.16.3 |
| 13:56 |
sandbergja |
I noticed that the new antora wants 16 or more: https://www.npmjs.com/package/antora/v/3.1.7?activeTab=code |
| 14:46 |
jeffdavis |
:) |
| 14:47 |
Dyrcona |
What do we mean "barriers to committing?" I assume it was about committers not reviewing code for main. |
| 14:47 |
Dyrcona |
My number 1 barrier is time. |
| 14:48 |
sandbergja |
For me, lack of time and access to a system for qa are big. But I'd also say that merge conflicts and semantic conflicts (e.g. an upgrade script changes a stored procedure, but that stored procedure has changed in the meantime, so committing it would cause a regression) also make things harder than they need to be |
| 14:49 |
sandbergja |
Also, I'd add that it takes a while to re-load concerto, or to manually run the automated tests |
| 14:50 |
Dyrcona |
For merge conflicts and semantic issues, just throw back at the original developer and ask for a rebase if you're not comfortable fixing the conflicts yourself. |
| 14:51 |
jeffdavis |
My other big ones are (1) no test plan, and/or tests are complicated to set up; (2) unresolved questions about the fix; (3) extra work to backport and uncertainty about whether to do so. |
| 14:51 |
jeffdavis |
Time is the big one, but the others all make the process even more time-consuming. |
| 14:52 |
Dyrcona |
yeah, testing is often difficult for me. I usually avoid staff client stuff because I never use it, so I often have trouble testing staff client changes. |
| 14:55 |
jeffdavis |
I wonder if some kind-hearted organization would be able to make a limited number of VMs available to committers to help mitigate the lack of access to test environments. |
| 14:56 |
jeffdavis |
(not thinking of any particular organization tbh, actually wondering if this is something my org could help with) |
| 14:59 |
Dyrcona |
My org is trying to get away from being in the hosting business. |
| 15:00 |
jeffdavis |
I know some wonderful folks do already set up test environments pre-loaded with branches for bug squashing weeks, I'm wondering about something a bit more flexible as a supplement. |
| 15:05 |
Dyrcona |
yeah, that's what I thought you meant. |
| 15:43 |
|
jihpringle joined #evergreen |
| 16:49 |
|
jvwoolf joined #evergreen |
| 10:25 |
Dyrcona |
Also, I get the buzzing noises, too. I've got 4 different conversations going on right now, including this one. :) |
| 10:29 |
|
kworstell-isl joined #evergreen |
| 10:30 |
|
redavis_reboot joined #evergreen |
| 10:34 |
pinesol |
News from commits: LP#2053245: fix Angular staff client test failure <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=9aa81e3a89ff8631f5e026081a069e033a719d9e> |
| 10:51 |
|
stephengwills joined #evergreen |
| 10:56 |
|
collum joined #evergreen |
| 11:07 |
Dyrcona |
One thing that has come up in internal CW MARS discussion is that we need different intervals to clean data from different auditor tables. We keep 13 months on the biblio record entry history because we use it for a report. We keep 6 months on most tables. Then there's the hold request history where we need to keep 3 months or less because we purge certain holds at 3 months for privacy reasons. (NB: 6 months for most things was consi |
| 13:50 |
Dyrcona |
kmlussier++ tuits++ |
| 13:51 |
* Dyrcona |
should open a Lp bug to eliminate the acq auditor functions. |
| 13:53 |
Dyrcona |
csharp_: I could adapt fix_columns to a do block that hits these two tables. That might work for my purposes. |
| 13:59 |
Dyrcona |
Well, my test database is now a mess. |
| 14:01 |
Dyrcona |
Grr. It's not that simple.... Of course it's not that simple...... |
| 14:05 |
Dyrcona |
Well, that did not fix anything. |
| 14:06 |
Dyrcona |
because columns are still in different orders...... |
| 14:19 |
Dyrcona |
ugh... I'm going to have to do this again on a different schema version. |
| 14:20 |
|
_collum joined #evergreen |
| 14:23 |
Dyrcona |
So, the insert ... select takes longer when you don't truncate the source table first. |
| 14:29 |
Dyrcona |
Looks like the schema hasn't really changed between the two releases that I have test data for. |
| 14:33 |
csharp_ |
gmcharlt_: Rogan: in the Zoom waiting room for board meeting in case you can see this |
| 14:33 |
csharp_ |
or kmlussier or redavis |
| 14:33 |
Rogan |
csharp_: I'll mention it |
| 14:33 |
csharp_ |
Rogan: thank you |
| 14:41 |
|
collum joined #evergreen |
| 14:49 |
|
collum joined #evergreen |
| 15:03 |
Dyrcona |
heh. Test it on a database that hasn't had a refresh in over 6 months and all the rows disappear! That's a 100% space savings on that 1 table alone. :) |
| 15:17 |
Bmagic |
space good; cougar bad |
| 15:20 |
jeff |
space good. |
| 15:20 |
jeff |
sadly, this update wasn't nearly as exciting as it could have been: Introducing new Space Manager capabilities in Google Chat |
| 15:49 |
Dyrcona |
s/thought/though/ |
| 15:51 |
Bmagic |
Dyrcona: https://imgur.com/a/05CngrU |
| 15:51 |
Dyrcona |
heh. |
| 15:52 |
Dyrcona |
Well, it's tested as far as it works.... I'm just not sure if the streaming replication is gong to like it. |
| 15:52 |
Dyrcona |
I mean, I ran it on 4 databases..... :) |
| 15:53 |
Bmagic |
alright, I retract my link |
| 15:54 |
|
mantis left #evergreen |
