| 10:03 |
|
kworstell_isl joined #evergreen |
| 10:07 |
Dyrcona |
Stompro: It's all right you missed the meeting. We discussed the 3.next target and some bugs. |
| 10:07 |
Dyrcona |
Also the Perl MARC code tries to deal with bad files like that. Not sure how it deals with that many nuls in a row, though. |
| 10:12 |
Stompro |
Dyrcona, if there are any specific bugs that need sign offs or more testing let me know. |
| 10:13 |
Dyrcona |
Well, there are 12 signed off bugs in total. I was going to have a look at those this week. If you want to take some, feel free. |
| 10:14 |
Dyrcona |
I'm on vacation next week. |
| 10:28 |
Stompro |
I'll take a look at them. |
| 12:09 |
jeffdavis |
disable_email_change rather, but you've found the right setting anyway :) |
| 12:09 |
* jeffdavis |
-> coffee |
| 12:27 |
|
collum joined #evergreen |
| 12:37 |
Stompro |
Dyrcona, do you have your timezone set, that was the test file that failed for me when I had the wrong timezone set. |
| 13:09 |
|
ian1 joined #evergreen |
| 13:13 |
Dyrcona |
Stompro: I do have it set. |
| 13:14 |
Dyrcona |
Reloaded the db and ran make livecheck again and everything passed. |
| 13:25 |
|
cbrown joined #evergreen |
| 13:30 |
Dyrcona |
I should not be testing this. I don't know what I'm doing, but anyway.... |
| 13:32 |
Dyrcona |
Like, how do I make a new call number prefix in the client? |
| 13:48 |
Dyrcona |
Ugh! Lp madness... There's a bug that has ended up with 2 distinct branches that were applied at different times. |
| 13:49 |
Dyrcona |
The earlier branch is basically a fix and the latter should have been a new bug, imnsho. |
| 14:18 |
Bmagic |
thats frustrating |
| 14:33 |
Dyrcona |
jeff: I am summarily removing your name from "Assigned to" on bugs you don't appear to be actively looking at. |
| 14:50 |
Dyrcona |
Grabbing 1423. |
| 14:56 |
pinesol |
News from commits: LP2048425: Increase test coverage for circ limit sets <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=221725a66032d2087481798db6c77b7bd7b7eccc> |
| 15:00 |
|
mantis left #evergreen |
| 15:11 |
jeff |
Dyrcona: sounds good. any bugs in particular, or are you just removing me from everything? |
| 15:26 |
pinesol |
News from commits: LP2065448 Stamp DB upgrade script <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=0d306102f3480042647c92cacf01fde329a0bc6b> |
| 15:36 |
Dyrcona |
Don't think the Lp advanced search URLs survive getting pasted into IRC. |
| 15:37 |
Dyrcona |
jeff: Turns out it is only 1 bug so far. |
| 15:38 |
|
SREtds-lib joined #evergreen |
| 15:52 |
Dyrcona |
JBoyer | Bmagic: Do you know if anyone is using Lp 1613335 in production? I'm going to test it and if it works, I'll push it for 3.14. |
| 15:53 |
pinesol |
Launchpad bug 1613335 in Evergreen "SIP Return Screen Message OK" [Low,Confirmed] https://launchpad.net/bugs/1613335 - Assigned to Jason Stephenson (jstephenson) |
| 15:54 |
Bmagic |
awesome, I'm using it in production |
| 15:56 |
Dyrcona |
Bmagic: Your branch or JBoyer's? I'm going to push the one that makes it optional. |
| 16:02 |
jeff |
(behind a config option for existing installs, i should say) |
| 16:02 |
Dyrcona |
jeff: Yeah, it's a setting on the login element. |
| 16:02 |
jeff |
yup, reviewed. :-) |
| 16:02 |
Dyrcona |
I'm going to test with two of ours copied from production: one I'll add the setting the other I won't. |
| 16:05 |
Dyrcona |
Oof. I might not have my SIP test code on this vm any more... |
| 16:16 |
Dyrcona |
Then, I have to modify the script for different file locations.... :) |
| 16:21 |
Dyrcona |
And, it works for me! |
| 16:21 |
Dyrcona |
After all these years.... :) |
| 09:30 |
|
Guest14 joined #evergreen |
| 09:52 |
|
cbrown joined #evergreen |
| 10:01 |
|
mantis joined #evergreen |
| 10:01 |
mantis |
running through the 3.11.6 ver install on a test server and I got a lot of these errors when building our Angular files |
| 10:01 |
mantis |
ex; Error: src/main.ts:1:32 - error TS2307: Cannot find module '@angular/core' or its corresponding type declarations. |
| 10:01 |
mantis |
not sure why this is a problem now |
| 10:03 |
JBoyer |
mantis, that looks like you're either running the "build from git" instructions when you don't need to or if you are installing from git maybe missed one of the pre-req install steps? |
| 10:03 |
mantis |
this is the command |
| 10:03 |
mantis |
ng build --configuration production |
| 10:04 |
JBoyer |
The npm install step is what I'm wondering about, that's what pulls down things like angular core and friends. |
| 10:04 |
mantis |
I know it's technically outdated |
| 10:05 |
mantis |
also run into this after running CHROME_BIN=/usr/bin/chromium-browser npm run test |
| 10:05 |
mantis |
23 07 2024 09:59:20.061:ERROR [karma-server]: Error: Found 1 load error |
| 10:05 |
mantis |
at Server.<anonymous> (/home/opensrf/Evergreen-ILS-3.11.6-biblio/Open-ILS/src/eg2/node_modules/karma/lib/server.js:243:26) |
| 10:05 |
mantis |
at Object.onceWrapper (node:events:631:28) |
| 10:05 |
mantis |
at Server.emit (node:events:529:35) |
| 10:05 |
mantis |
at Server.emit (node:domain:489:12) |
| 10:05 |
mantis |
at emitListeningNT (node:net:1851:10) |
| 10:05 |
|
ian1 joined #evergreen |
| 10:06 |
JBoyer |
is there anything in /home/opensrf/Evergreen-ILS-3.11.6-biblio/Open-ILS/src/eg2/node_modules and was a different version of Evergreen installed previously? |
| 10:06 |
mantis |
I'll check |
| 10:18 |
mantis |
Yeah it had Evergreen 3.11.4 on here |
| 10:18 |
mantis |
though I am comparing angular/core directories and there are a couple of differences |
| 10:18 |
Dyrcona |
Well, that's not old enough to cause issues with different node versions. |
| 10:18 |
mantis |
esm2020 and testing folders are not in evgtest2 |
| 10:19 |
mantis |
Dyrcona++ |
| 10:19 |
mantis |
I'll try the reinstallation |
| 10:20 |
Dyrcona |
I wonder if something made it into 3.11.6 that should not have? I built it. It installed fine from the tarball, but I did not attempt an upgrade. |
| 10:20 |
mantis |
should I remove the node_modules before or after running the build commands? |
| 10:21 |
Dyrcona |
BTW, I am working on Lp2060734 again today. I've made a couple of releases with it, and I'm about to test the results of those releases on Debian Bookworm and Ubuntu 24.04, so I'm also in the middle of doing installations. |
| 10:21 |
Dyrcona |
Lp 2060734 |
| 10:21 |
pinesol |
Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 10:23 |
Dyrcona |
I should build one from git, maybe. |
| 11:37 |
|
ian1 joined #evergreen |
| 11:45 |
|
Christineb joined #evergreen |
| 11:50 |
|
ian1 joined #evergreen |
| 11:52 |
Dyrcona |
Does anyone know OTTOTH of a branch with a database upgrade other than the reports permissions branch? (I've applied it already for my test purposes.) |
| 11:52 |
Dyrcona |
I think I have one hanging around maybe. It might have gone in. |
| 11:56 |
Dyrcona |
I can use Lp 1835953 |
| 11:57 |
pinesol |
Launchpad bug 1835953 in Evergreen "Circulation auto renewal remaining should not be nullable" [Medium,Confirmed] https://launchpad.net/bugs/1835953 |
| 11:57 |
Dyrcona |
Hm... something wrong with my configuration. The two tests that depend on apache failed. |
| 11:59 |
Dyrcona |
I'll look into it after lunch. |
| 12:03 |
|
jihpringle joined #evergreen |
| 12:19 |
JBoyer |
To this day I do not understand rooibos tea. (At least that one, I know there's more than one type.) |
| 12:40 |
Dyrcona |
Looks like my problem was nginx needed a restart. |
| 12:41 |
* Dyrcona |
has never had rooibos tea. |
| 12:42 |
Dyrcona |
Ok. gonna test my fake upgrade from 3.14.0 to 3.14.1, then I'll do 3.14.1 to 3.14.2.... :) |
| 12:46 |
Dyrcona |
Think I'll do somethin' unorthodox... I'll reinstall the 3.14.0 schema and data, then run the db upgrade, and then install 3.14.1. After that, I'll run the tests. |
| 13:01 |
|
cbrown_isl joined #evergreen |
| 13:03 |
Dyrcona |
So, that works... |
| 13:05 |
|
cbrown joined #evergreen |
| 14:18 |
sandbergja |
It looks good to me! |
| 14:19 |
Dyrcona |
OK. I moderately prefer deleting the line over modifying it. |
| 14:19 |
sandbergja |
agree, it does seem cleaner |
| 14:21 |
Dyrcona |
OK. That's the one we'll go with. I'm basically done. I'll update the Lp bug and add some instructions for testing it in a comment. I exercised just about everything it does. |
| 14:24 |
Dyrcona |
I'm going to give that commit another test or two first. |
| 14:25 |
sandbergja |
woo hoo! Thanks so much, Dyrcona! |
| 14:33 |
Dyrcona |
sandbergja++ This branch will make certain aspects of the releases so much easier. |
| 14:34 |
sandbergja |
I'm glad! And we as a community can keep chipping away at it. |
| 08:53 |
|
Dyrcona joined #evergreen |
| 08:53 |
|
mantis joined #evergreen |
| 09:32 |
|
jvwoolf joined #evergreen |
| 10:55 |
Dyrcona |
stompro: I'm going to have another look at Lp 2054842. I want to rebase the branches and run the tests again. Don't let that stop you from looking at them if you wish. |
| 10:55 |
pinesol |
Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] https://launchpad.net/bugs/2054842 - Assigned to Jason Stephenson (jstephenson) |
| 11:00 |
Dyrcona |
I think the issue is that some test fail on a remote database, but they succeed if the test is local, and IIRC, I've seen that not just on Ubuntu 24.04, but other distros as well. |
| 11:01 |
Dyrcona |
Ugh. I mean if the database is on a remote server, some of the tests seem to fail, and if the database is local, they succeed. |
| 11:02 |
pinesol |
News from commits: LP2018014: Add release note <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=588da520d3def40fdf89f586b920d6e65502543a> |
| 11:04 |
jeff |
are the failing tests failing because they have pre-reqs that aren't in the database server pre-req Makefile target(s)? |
| 11:55 |
|
ian1 joined #evergreen |
| 12:32 |
|
redavis joined #evergreen |
| 12:41 |
|
Christineb joined #evergreen |
| 13:17 |
Dyrcona |
jeff: I don't think so. I pasted it here before. One of them doesn't find as many bills as it expects. |
| 13:20 |
Dyrcona |
Here's one place I mentioned the failing tests before and eliminated Pg 16 as the culprit: http://irc.evergreen-ils.org/evergreen/2024-06-24#i_555023 |
| 13:27 |
Dyrcona |
I was also considering the possibility that Lp 2060734 caused it. I had that one, Lp 2054842 and Lp 2037656 applied. I also tested wit an older release, IIRC, and got failures on a remote database with all the prerequisites installed. (I have a test db server with everything installed that I use all the time and it works for normal operations.) |
| 13:27 |
pinesol |
Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 13:27 |
pinesol |
Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] https://launchpad.net/bugs/2054842 - Assigned to Jason Stephenson (jstephenson) |
| 13:27 |
pinesol |
Launchpad bug 2037656 in Evergreen "Add Support for PostgreSQL 16" [Wishlist,Confirmed] https://launchpad.net/bugs/2037656 |
| 13:29 |
|
kworstell_isl_ joined #evergreen |
| 13:30 |
|
kworstell_isl_ joined #evergreen |
| 13:32 |
|
kworstell_isl joined #evergreen |
| 13:58 |
Dyrcona |
Testing on Ubuntu 24.04 with local Pg 16, make check and make livecheck pass. |
| 14:25 |
Dyrcona |
Sure is slow running the tests over the Internet. :) |
| 14:30 |
Dyrcona |
Up to 24-login-ap.t and it looks like they've all passed so far. I was getting failures before this in the past. Maybe it's just one of those things? Maybe jeff was right about something missing, but the failing tests didn't seem like ones where it would matter. |
| 14:32 |
|
jvwoolf joined #evergreen |
| 14:49 |
Dyrcona |
Hey! make livecheck passed this time. |
| 14:59 |
|
kworstell-isl joined #evergreen |
| 10:20 |
Dyrcona |
ian1: Do you mind pasting the command line you used? |
| 10:21 |
ian1 |
perl Open-ILS/src/support-scripts/eg_db_config --update-config --service all --create-database --create-schema --create-offline --user evergreen --password ******* --hostname localhost --port 5432 --database everdb --admin-user evergreen --admin-pass ********* |
| 10:22 |
Dyrcona |
Two suggestions: 1. if there is no other database on here, name the database "evergreen" it will save you issues with psql. |
| 10:23 |
Dyrcona |
2. Set the --admin-usr to "admin" and the --admin-pass to "demo123". This way, you can run the automated tests and they will just work. |
| 10:23 |
ian1 |
I can just run it again right? |
| 10:23 |
Dyrcona |
I guess a third suggestion: Add --load-all-sample to get some sample data in the database, unless you intend to build your data from scratch. |
| 10:24 |
Dyrcona |
You can, but I'd drop everdb, first : psql -U evergreen -h localhost -d postgres -c 'drop database everdb;' |
| 10:26 |
ian1 |
round x |
| 10:27 |
Dyrcona |
I don't remember how many times it took me to get a working test installation the first time. I still mess things up now and then when I build a new vm for testing. There are also scripts and docker images out there to make the setup easier. |
| 10:27 |
Dyrcona |
It's because we've all made the same mistakes that we're able to help. :) |
| 10:28 |
Dyrcona |
Also, if you can think of better ways to word the instructions, please do make suggestions/open bugs on Launchpad. |
| 10:29 |
ian1 |
I'm planning to attend DIG meetings at a minimum. May look for other ways to get involved as well. I love a clean well formatted document. So I ran the db config again. |
| 10:45 |
Dyrcona |
huh.... |
| 10:45 |
Dyrcona |
At this point, I'm stumped. |
| 10:45 |
Dyrcona |
I'd need to see the configuration files. |
| 10:46 |
Dyrcona |
Did you test OpenSRF before with the math add test from the OpenSRF README? |
| 10:46 |
ian1 |
I did that yesterday and at the time it worked fine |
| 10:46 |
Dyrcona |
So, you have /etc/ld.so.conf.d/opensrf.conf, then.... |
| 10:47 |
Dyrcona |
Is this Ubuntu 24.04? |
| 15:29 |
sandbergja |
I was hoping we could go back to the previous discussion, and pull out one or two bitesize items that we could make progress on *in this meeting* |
| 15:29 |
abneiman |
ok - did you have your eye on a couple items in particular? |
| 15:29 |
redavis |
fer sure. But I do like the idea of someone being able to checkout a virtual machine. Just used that in a class and it was delightful. |
| 15:29 |
sandbergja |
so not like move git hosting or setting up a VM checkout system, but... like more guidance on backporting. Or doing something proactive about existing pull requests without test plans |
| 15:30 |
jeffdavis |
Would a "needstestplan" tag be useful or is that just kicking the can down the road some more? |
| 15:30 |
redavis |
jeffdavis++ |
| 15:30 |
sleary |
was just thinking that, jeffdavis |
| 15:31 |
abneiman |
it's certainly a start |
| 15:31 |
abneiman |
jeffdavis++ |
| 15:31 |
Dyrcona |
For testing, we do have this old document: https://wiki.evergreen-ils.org/doku.php?id=dev:contributing:qa |
| 15:31 |
Dyrcona |
It basically says, you must include tests. |
| 15:32 |
jeffdavis |
I think " a plan for how to test if the fix works" is not necessarily the same as the automated tests contemplated there. |
| 15:32 |
jeffdavis |
Although automated tests are certainly ideal. |
| 15:32 |
sleary |
correct. |
| 15:32 |
abneiman |
yes, I was going to say - not everything is automatically-testable |
| 15:32 |
redavis |
I think there are both code tests and feature tests. |
| 15:33 |
sleary |
and I think that document is not entirely up to date with our current translation process. |
| 15:33 |
abneiman |
and in fact, we do have a "needstest" LP tag which indicates that an automated test is needed (and is often misapplied by people who think it means "please test this") |
| 15:34 |
sandbergja |
It seems to me that the automated test part of that document has been more or less ignored for 9 years... It is pretty unusual to see any code submitted _with_ automated tests. |
| 15:34 |
|
kworstell-isl joined #evergreen |
| 15:34 |
Dyrcona |
True. We have not been enforcing it. Commit messages explaining how to test have been acceptable, too. |
| 15:34 |
redavis |
there's a nuance differentiating needstest and needstestplan |
| 15:36 |
|
Jaysal joined #evergreen |
| 15:36 |
Dyrcona |
I'm not sure we were all that strict with the 2.8 and 2.9 releases mentioned in the document, but it's a start. |
| 15:36 |
|
Jaysal joined #evergreen |
| 15:36 |
sandbergja |
I'm hearing no strong objections to a needstestplan tag |
| 15:37 |
redavis |
+1 to needstestplan tag |
| 15:37 |
sandbergja |
And the page Dyrcona mentioned has a nice example of a test plan in a commit message |
| 15:37 |
redavis |
It seems that that page could also do with a nice update, but I can't volunteer for that. |
| 15:37 |
abneiman |
no, but I will point out that with one exception, the needstest tag is on bugs that haven't seen any action in 3+ years |
| 15:39 |
* mmorgan |
likes the idea of using Launchpad tags, but we need to make sure the tags are more like action items than reasons to kick the can down the road. |
| 15:39 |
abneiman |
this ^^^^ |
| 15:39 |
redavis |
abneiman, I can envision the needstestplan used on a consternating lp ticket during BSW where a tester might need more info to set up their test. "help me!" |
| 15:39 |
abneiman |
good point, redavis |
| 15:40 |
jeffdavis |
I will say I committed something today because abneiman asked for eyes on the 3.14 roadmap, and the fix had a test plan and no merge conflict. |
| 15:40 |
abneiman |
"The disambiguation of uses of Lauchpad tags: an Evergreen Conference Panel and / or drinking game" |
| 15:40 |
redavis |
lol! |
| 15:40 |
abneiman |
jeffdavis++ |
| 15:42 |
mmorgan |
+1 |
| 15:42 |
smayo |
sleary++ |
| 15:42 |
abneiman |
well, in that case, "needswork" and "needsrebase" should also be on that list |
| 15:42 |
sandbergja |
One etiquette question (which I think might be part of not kicking the can down the road): if a pullrequest gets a needstestplan applied, can anybody reply on launchpad with the test plan? Or would it have to tbe the original patch author. |
| 15:43 |
mmorgan |
I also like the idea of a bugs to look at list. |
| 15:43 |
redavis |
that's a cool idea. clarifying question - would needstestplan only go on pull requested tickets? |
| 15:43 |
redavis |
sandbergja++ |
| 15:43 |
sleary |
redavis I think so |
| 15:43 |
redavis |
sleary++ |
| 15:43 |
shulabear |
redavis++ |
| 15:44 |
Dyrcona |
sandbergja: In keeping the bazaar atmosphere, I think anyone could offer a test plan, though it would be better coming from the original patch author. |
| 15:44 |
abneiman |
yes, I was basically typing what Dyrcona just said re test plan |
| 15:44 |
redavis |
Dyrcona++ |
| 15:44 |
mmorgan |
I also think anyone could offer a test plan. |
| 15:44 |
sandbergja |
Dyrcona++ |
| 15:44 |
shulabear |
Dyrcona++ |
| 15:44 |
abneiman |
and +1 to the tag being only applicable to pr'd items |
| 15:45 |
jeffdavis |
IMO it should be an expectation that the author provides the test plan, but I agree anyone could do it. |
| 15:45 |
abneiman |
OK, so, I think we have a few items of agreement here: |
| 15:45 |
redavis |
And maybe worth noting that there might be people who excel at test plans but not other stuff and vice versaish. |
| 15:45 |
shulabear |
redavis++ |
| 15:45 |
sandbergja |
redavis: good point |
| 15:46 |
sleary |
I think we've occasionally gotten test plans from the first signoff person. |
| 15:46 |
abneiman |
1) [someone] will create a needstestplan tag, which will be appplied to PR'd bugs if a test plan is lacking and needed; 2) we prefer if all PR'd bugs ALREADY have a test plan from the patch author, but if not, anyone can provide them; 3) mmorgan will update the LP stats monthly pull to include new uses of needswork, needsrebase, and needstestplan |
| 15:46 |
mmorgan |
Providing test plans could be a good fit for folks that use Evergreen and not so much write code. |
| 15:47 |
abneiman |
is that an accurate summary? does anyone want to take the first item as an action? |
| 15:47 |
redavis |
I do envision that this might be a nice entry point for community contribution as well. |
| 15:47 |
sandbergja |
I can make the tag right now |
| 15:48 |
abneiman |
sandbergja++ # the best kind of action items are the ones already done! |
| 15:48 |
abneiman |
ok, for the minutes: |
| 15:48 |
redavis |
sandbergja++ |
| 15:49 |
abneiman |
#info agreed upon the following: 1) sandbergja will create a needstestplan tag, which will be appplied to PR'd bugs if a test plan is lacking and needed; 2) we prefer if all PR'd bugs ALREADY have a test plan from the patch author, but if not, anyone can provide them; 3) mmorgan will update the LP stats monthly pull to include new uses of needswork, needsrebase, and needstestplan |
| 15:49 |
terranm |
It will need to be added to https://wiki.evergreen-ils.org/doku.php?id=dev:lp_tags as well - I can do that |
| 15:49 |
abneiman |
terranm++ |
| 15:49 |
redavis |
terranm++ |
| 15:49 |
Dyrcona |
I think there's actually and #agreed command for the bot. |
| 15:49 |
abneiman |
moving along, or any other discussion here? did we meet your goal of bitesize actionable items here, sandbergja? |
| 15:49 |
Dyrcona |
s/and/an/ |
| 15:49 |
terranm |
To make sure I'm right, needstestplan should be applied to tickets needing testing instructions, correct? (I had to step away, so trying to catch up)_ |
| 15:50 |
sleary |
yes |
| 15:50 |
terranm |
thx |
| 15:50 |
sandbergja |
I'm good! Thanks all! |
| 15:52 |
abneiman |
jeffdavis already took one of these on, so there are now TWO features committed for 3.14! |
| 15:52 |
dluch |
woot! |
| 15:52 |
eeevil |
side note, I'm happy that evergreen pi will be a spoooooky release right by Halloween :D |
| 15:52 |
abneiman |
and yes, I will give myself a related action |
| 15:52 |
abneiman |
#action abneiman will review existing EOLI PRs for test plans |
| 15:52 |
phasefx_ |
we could just keep versioning in the pattern of pi, but it wouldn't be rational |
| 15:52 |
Dyrcona |
eeevil: Should we do what tex does and increment 1 digit of pi for each future release? |
| 15:53 |
Dyrcona |
phasefx_++ |
| 15:54 |
abneiman |
(I'm just forging ahead, you nerds) there are 3 pullrequests and 2 signoffs on that 3.14 roadmap. Perhaps instead of a Last Minute Merge Melee, we can look at some of those earlier? |
| 15:54 |
sleary |
smayo we should put a ghost easter egg in there somewhere |
| 15:54 |
eeevil |
alliterative code names: pumpkin pi |
| 15:54 |
redavis |
There are couple of those that are still in or pre-testing. |
| 15:55 |
abneiman |
good point, redavis |
| 15:55 |
sleary |
yes, and a few not finished at all--although dark mode is getting pretty close! |
| 15:55 |
redavis |
Also, I'll go do a root around LP and see if there are some other things that should be added to the roadmap as well. |
| 15:56 |
jeffdavis |
I'm kind of scared to commit bug 2043142 because it's so big, even though folks here at Sitka have tested and signed off on it. Does a non-EOLI person need to commit it? |
| 15:56 |
pinesol |
Launchpad bug 2043142 in Evergreen "wishlist: Reports security improvements" [Wishlist,New] https://launchpad.net/bugs/2043142 |
| 15:56 |
abneiman |
AFAIK these are ready for review: |
| 15:56 |
abneiman |
Add PostgreSQL 16 support bug 2037656 – pullrequested & signedoff |
| 15:56 |
pinesol |
Launchpad bug 1902120 in Evergreen "Rename 'All parts' to 'Any part' in hold placement screen" [Wishlist,Confirmed] https://launchpad.net/bugs/1902120 |
| 15:56 |
pinesol |
Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 15:56 |
redavis |
jeffdavis, that's preferable. |
| 15:57 |
Dyrcona |
Regarding Lp 2043142: Someone at CW MARS told me it likely would not affect us because we don't let library staff create templates. Otherwise, we would probably have tested it by now. |
| 15:57 |
pinesol |
Launchpad bug 2043142 in Evergreen "wishlist: Reports security improvements" [Wishlist,New] https://launchpad.net/bugs/2043142 |
| 15:57 |
sandbergja |
out of curiosity, does bug 2043142 have a test plan? |
| 15:58 |
abneiman |
sandbergja: there is a tech ref doc and an extensive commit message, but not necessarily a "do A and get B" test plan |
| 15:58 |
Dyrcona |
I have actually been looking at Lp 2060734, and I should go ever it again. I think I'd like to suggest/make some modifications. |
| 15:58 |
pinesol |
Launchpad bug 2060734 in Evergreen "Various changes to the release process" [Undecided,Confirmed] https://launchpad.net/bugs/2060734 - Assigned to Jason Stephenson (jstephenson) |
| 15:59 |
abneiman |
which, does point to a wrinkle that I of all people should've thought of, which is, what's the difference between a bugfix test plan and a feature test plan |
| 15:59 |
Dyrcona |
typos-- |
| 15:59 |
sandbergja |
Dyrcona++ # thanks for reviewing that |
| 15:59 |
Dyrcona |
sandbergja++ Thanks for taking it on. |
| 15:59 |
sandbergja |
abneiman: good question |
| 16:00 |
Dyrcona |
yeah, bug fix tests should be easier than new features, unless the feature is really simple. |
| 16:00 |
abneiman |
because with features, it's not as simple as "do A and get B" - which is why we (Equinox) try to include documentation and tech ref docs with new features, along with extensive commit messages |
| 16:01 |
abneiman |
but, if you all would rather us put out more formal test plans, I can work on that as well |
| 16:01 |
|
rlefaive joined #evergreen |
| 16:01 |
abneiman |
however, we are at the top of the hour so maybe "test plans for big features" could be a future topic |
| 16:02 |
sandbergja |
yeah, that might be where it gets trickier |
| 16:02 |
dluch |
+1 |
| 16:03 |
redavis |
also +1 |
| 16:03 |
abneiman |
#action discussion item for next meeting: test plans for big features |
| 16:03 |
abneiman |
that even might be a worthy hackaway topic |
| 16:03 |
abneiman |
anyway. |
| 16:04 |
abneiman |
anything else to discuss? Anything that I forgot? Any parting words of wisdom? |
| 16:04 |
redavis |
stay hydrated |
| 16:04 |
eeevil |
never start a land war in ... oh, nevermind |
| 16:04 |
abneiman |
#agree we're all gonna stay hydrated |
