Time |
Nick |
Message |
03:35 |
|
bshum joined #evergreen |
07:08 |
|
collum joined #evergreen |
07:58 |
|
BDorsey joined #evergreen |
08:03 |
|
collum joined #evergreen |
08:29 |
|
mmorgan joined #evergreen |
09:01 |
|
dguarrac joined #evergreen |
09:23 |
|
Dyrcona joined #evergreen |
09:24 |
Dyrcona |
Why is it that something tested in production over a week ago and worked, doesn't work when I actually want to use it? |
09:31 |
Dyrcona |
OK. It IS working. The first thing it tried to do ended up being invalid as far as the new process is concerned. |
09:31 |
Dyrcona |
The a/t event is not invalid, but it doesn't meet other criteria in the script. |
10:00 |
|
kmlussier joined #evergreen |
10:05 |
csharp_ |
rubber_ducking++ |
10:06 |
csharp_ |
JonHGeorg: happy to help! |
10:06 |
|
Em_Ott joined #evergreen |
10:09 |
kmlussier |
Good morning #evergreen! |
10:09 |
kmlussier |
@coffee [someone] |
10:09 |
* pinesol |
brews and pours a cup of Kenya Peaberry Nyeri-Tatu, and sends it sliding down the bar to pinesol |
10:09 |
|
Em_Ott joined #evergreen |
10:09 |
kmlussier |
@tea [someone] |
10:09 |
* pinesol |
brews and pours a pot of Chamomile (Sachet), and sends it sliding down the bar to mmorgan (http://ratetea.com/tea/harney/chamomile-sachet/5103/) |
10:10 |
mmorgan |
Thank you kmlussier! Though I'm not sure it's wise to send Chamomile! ;-) |
10:11 |
kmlussier |
mmorgan: I've always thought of you as more of a coffee person anyway. |
10:11 |
* mmorgan |
is on the fence, these days. Today is a rare day when I'm drinking a second cup of REAL coffee. |
10:11 |
* mmorgan |
is usually on to green tea by now. |
11:29 |
Dyrcona |
berick++ We're using the evergreen-xml-notices for real in production today. |
11:29 |
Dyrcona |
Bmagic++ |
11:30 |
berick |
Dyrcona: cool, good to know |
11:31 |
berick |
heads up I'm adding a patron-self-registration (pending patron) email notice to ours. will share when it's merged |
11:34 |
Dyrcona |
That's cool. You might want to consider adding some of the other modifications to your own github repo. If you want, I can make clean branch of my modifications from here: https://github.com/CWMARSINC/evergreen-xml-notices/tree/cwmars |
11:34 |
Dyrcona |
That branch could probably use better attribution of what is yours versus which are my changes. |
11:35 |
Dyrcona |
Also, some of the very specific changes should probably be skipped, like our events. |
11:37 |
berick |
yeah i'm curoius what you've added |
11:37 |
berick |
"curoius" is the ancient Greek spelling, btw, not a typo |
11:37 |
Dyrcona |
:) |
11:38 |
Dyrcona |
Other than different paths for the local files, the bulk is in that branch above. Many of the changes come from your KCLS repo. |
11:40 |
* berick |
nods |
11:44 |
collum |
Κουρόιους |
11:44 |
berick |
exactly |
11:58 |
|
redavis joined #evergreen |
12:08 |
|
jihpringle joined #evergreen |
12:42 |
csharp_ |
Dyrcona++ berick++ # very interested in the xml notices stuff |
12:42 |
csharp_ |
@decide curois or chreeus |
12:42 |
pinesol |
csharp_: go with chreeus |
12:43 |
csharp_ |
pinesol: yep - my mama always did |
12:43 |
pinesol |
csharp_: I eat more coconut cream pie before breakfast than most people eat all day |
13:14 |
|
Christineb joined #evergreen |
13:37 |
Dyrcona |
pinesol: What about RC Cola and a Moon Pie? |
13:37 |
pinesol |
Dyrcona: The horror... The horror... |
13:41 |
csharp_ |
@dessert |
13:41 |
* pinesol |
grabs some Lemon Cupcakes for csharp_ |
13:42 |
Dyrcona |
berick: I wonder if Lp 1953044 is related to a use after free/double free I reported as a security bug. |
13:42 |
pinesol |
Launchpad bug 1953044 in OpenSRF "Perl services can crash with a "Use of freed value in iteration" error" [Medium,Confirmed] https://launchpad.net/bugs/1953044 |
13:45 |
Dyrcona |
Never mind. Doesn't look like the same thing now that I read it again. |
13:47 |
Dyrcona |
@dessert search moon pie |
13:47 |
pinesol |
Dyrcona: 1 found: #40: "Moon Pie and some RC Cola" |
13:47 |
Dyrcona |
:) |
13:47 |
Dyrcona |
@dessert 40 pinesol |
13:47 |
* pinesol |
grabs some Moon Pie and some RC Cola for pinesol |
13:48 |
kmlussier |
@dessert Dyrcona |
13:48 |
* pinesol |
grabs some candy from krvmga's desk for Dyrcona |
13:48 |
Dyrcona |
That's most appropriate, though it's no longer krvmga's desk. |
13:48 |
kmlussier |
krvmga always had candy at his desk. |
14:24 |
redavis |
Bmagic, just noting, in case you weren't aware and wanted to be, bugsquash.mobiusconsortium.org is giving an internal server error. |
14:29 |
|
terranm joined #evergreen |
14:46 |
|
shulabear joined #evergreen |
14:55 |
Bmagic |
warning: dev meeting immanent |
14:56 |
|
Em_Ott joined #evergreen |
14:59 |
* kmlussier |
had forgotten she had a to-do item from the last meeting. |
14:59 |
Bmagic |
40 seconds |
14:59 |
|
LindaJansova joined #evergreen |
14:59 |
Bmagic |
15 seconds |
14:59 |
berick |
heh |
14:59 |
Bmagic |
5 |
14:59 |
redavis |
daaaahhhhhaaaaaannnngggg |
15:00 |
Bmagic |
#startmeeting 2024-06-11 - Developer Meeting |
15:00 |
pinesol |
Meeting started Tue Jun 11 15:00:01 2024 US/Eastern. The chair is Bmagic. 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 '2024_06_11___developer_meeting' |
15:00 |
Bmagic |
#info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-06-11 |
15:00 |
Bmagic |
#topic Introductions |
15:00 |
Dyrcona |
#info Dyrcona = Jason Stephenson, CW MARS |
15:00 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
15:00 |
terranm |
#info terranm = Terran McCanna, PINES |
15:00 |
Bmagic |
you can't beat the meeting host Dyrcona! |
15:00 |
redavis |
#info redavis = Ruth Davis, ECDI |
15:00 |
sleary |
#info sleary = Stephanie Leary, EOLI |
15:00 |
abneiman |
#info abneiman = Andrea Buntz Neiman, Equinox |
15:00 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
15:00 |
Bmagic |
party foul |
15:00 |
kmlussier |
#info kmlussier is Kathy Lussier, NOBLE |
15:00 |
berick |
#info berick Bill Erickson, KCLS |
15:00 |
shulabear |
:#info shulabear = Shula Link, GCHRL |
15:01 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
15:01 |
|
smayo joined #evergreen |
15:01 |
LindaJansova |
#info LindaJansova is Linda Jansova, Osvobozena knihovna, Czech Republic |
15:01 |
jeff |
]]\\\ |
15:01 |
jeff |
bah. |
15:01 |
shulabear |
#info shulabear = Shula Link, GCHRL |
15:01 |
eeevil |
#info eeevil = Mike Rylander, EOLI |
15:01 |
smayo |
#info smayo = Steven Mayo, PINES |
15:02 |
|
EvaCe joined #evergreen |
15:02 |
Bmagic |
#topic Action Items from Last Meeting |
15:02 |
Bmagic |
#info gmcharlt - create a Git commit message type and update bug 2051946 |
15:02 |
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:02 |
Bmagic |
absent? |
15:03 |
Bmagic |
we'll carry it |
15:03 |
sleary |
I believe that's done, though |
15:03 |
Bmagic |
oh? |
15:03 |
Bmagic |
the bug doesn't have what I would expect |
15:03 |
sleary |
or perhaps I'm thinking of the release note one-liners |
15:04 |
abneiman |
sleary I think you're thinking of the release notes |
15:04 |
Bmagic |
the one-liners is something else |
15:04 |
sleary |
ok |
15:04 |
abneiman |
2051946 is a follow up & I do not think it's done |
15:04 |
Bmagic |
#action gmcharlt - create a Git commit message type and update bug 2051946 |
15:04 |
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:04 |
Bmagic |
#info mmorgan will explore moving LP stats to community site and automating same |
15:04 |
mmorgan |
Please carry forward. Still making progress as time allows. I did want to note that the majority of today's datapoints came via the Launchpad API. |
15:04 |
Bmagic |
suuuweet! |
15:05 |
sleary |
mmorgan++ |
15:05 |
Bmagic |
mmorgan++ |
15:05 |
redavis |
mmorgan++ |
15:05 |
Dyrcona |
mmorgan++ |
15:05 |
Bmagic |
#action mmorgan will explore moving LP stats to community site and automating same |
15:05 |
kmlussier |
mmorgan++ |
15:05 |
Bmagic |
#info Dyrcona will take a look at bug 1017990 for merging into main and 3.13 |
15:05 |
pinesol |
Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990 |
15:05 |
abneiman |
mmorgan: is the Launchpad API better behaved these days? |
15:05 |
abneiman |
IIRC it was very finicky & crashed a lot |
15:06 |
mmorgan |
abneiman: It's answered properly when I've asked it the right questions so far :) |
15:06 |
abneiman |
mmorgan++ |
15:06 |
Dyrcona |
My experience is that there were limits on how many things you could do before it would start acting up. |
15:07 |
Dyrcona |
Anyway, I commented on the bug (https://bugs.launchpad.net/evergreen/+bug/1017990/comments/14) and I see that csharp_ has followed up with some additional code. |
15:07 |
pinesol |
Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] |
15:07 |
Bmagic |
well, 3.13 is released, and this bug didn't make it |
15:07 |
csharp_ |
#info csharp_ is Chris Sharp, GPLS |
15:07 |
Dyrcona |
Ugh. wrong comment: https://bugs.launchpad.net/evergreen/+bug/1017990/comments/21 |
15:08 |
Dyrcona |
I'll take another look at Chris's branch. I'm not sure what I looked at last time. |
15:08 |
Bmagic |
alright, no problem. Carrying it |
15:08 |
Dyrcona |
Too much going on lately. |
15:08 |
Bmagic |
#action Dyrcona will take a look at bug 1017990 |
15:09 |
pinesol |
Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990 |
15:09 |
Bmagic |
#info eeevil will open a bug for cross-column stats targets |
15:09 |
csharp_ |
Dyrcona: thanks |
15:10 |
Bmagic |
I'm assuming eeevil is typing |
15:11 |
eeevil |
I haven't even thought about that ... been a long month! |
15:11 |
eeevil |
so, push it forward, please |
15:11 |
Bmagic |
same for me! Carry! |
15:11 |
Bmagic |
#action eeevil will open a bug for cross-column stats targets |
15:11 |
Bmagic |
same for this probably |
15:11 |
Bmagic |
#info eeevil will see about merging bug 2042158 |
15:11 |
pinesol |
Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [High,Fix released] https://launchpad.net/bugs/2042158 |
15:12 |
Bmagic |
oh! nope, that one was touched |
15:12 |
Bmagic |
close the books on that |
15:12 |
eeevil |
I saw about that :) |
15:12 |
Bmagic |
eeevil++ |
15:12 |
eeevil |
Bmagic++ |
15:12 |
* csharp_ |
can't quite grab the "just in time" joke that's floating out there |
15:12 |
Bmagic |
csharp_++ |
15:13 |
Bmagic |
kmlussier's turn |
15:13 |
Bmagic |
#info kmlussier will update wiki (commit message standards) to include details about shared components/pullrequest rule for LP tagging on multi-commits |
15:13 |
kmlussier |
I'm sorry. I forgot to put it on my to-do list. I'll get it done before the end of the day. |
15:13 |
Bmagic |
no rush, we don't have another one of these for 30 days! |
15:13 |
Bmagic |
#action kmlussier will update wiki (commit message standards) to include details about shared components/pullrequest rule for LP tagging on multi-commits |
15:13 |
kmlussier |
I'll forget again if I don't do it right away. :) |
15:14 |
Bmagic |
:) |
15:14 |
Bmagic |
that does it for action items from last month |
15:14 |
Bmagic |
#topic Evergreen |
15:14 |
Bmagic |
#info 3.13.0 is released |
15:15 |
Bmagic |
boomshakalaka |
15:15 |
jeff |
heartfelt thanks to all, especially the release team! |
15:15 |
smayo |
release_team++ |
15:15 |
redavis |
release_team++ |
15:15 |
terranm |
release_team++ |
15:15 |
kmlussier |
release_team++ |
15:15 |
LindaJansova |
release_team++ |
15:15 |
Bmagic |
the release team is drunk on a beach somewhere |
15:15 |
abneiman |
...wait how did I miss THAT memo |
15:15 |
redavis |
lol, or in this meeting. frightfully sober |
15:16 |
shulabear |
the release team wishes |
15:16 |
mmorgan |
release_team++ |
15:16 |
Bmagic |
IRC works on phones these days |
15:16 |
sleary |
beach, Launchpad... no, not the same at all |
15:16 |
redavis |
@coffee release_team |
15:16 |
* pinesol |
brews and pours a cup of Ethiopia Yirgacheffe Beloya Selection 8, and sends it sliding down the bar to release_team |
15:16 |
abneiman |
@liquor release_team |
15:16 |
pinesol |
abneiman: is your coffee overgranularized? |
15:16 |
abneiman |
dang |
15:16 |
sleary |
lol |
15:16 |
redavis |
lol!!! |
15:16 |
kmlussier |
@bartender release_team |
15:16 |
* pinesol |
fills a pint glass with J.W. Dundee's Original Honey Brown, and sends it sliding down the bar to release_team (http://beeradvocate.com/beer/profile/302/832/) |
15:17 |
abneiman |
kmlussier++ |
15:17 |
Bmagic |
kmlussier++ |
15:17 |
shulabear |
kmlussier++ |
15:17 |
Bmagic |
#topic Launchpad Status (as of noon Eastern) |
15:17 |
Bmagic |
incoming |
15:17 |
Bmagic |
#info Open Bugs - 3050 |
15:17 |
Bmagic |
#info Pullrequests - 82 |
15:17 |
Bmagic |
#info Signedoff - 11 |
15:17 |
Bmagic |
#topic Launchpad Status since last meeting |
15:17 |
Bmagic |
#info Bugs Added - 43 |
15:17 |
Bmagic |
#info Pullrequest tag Added - 12 |
15:17 |
Bmagic |
#info Signedoff tag Added - 11 |
15:17 |
Bmagic |
#info Fix Committed - 21 |
15:17 |
Bmagic |
#topic New Business - translation infrastructure: eliminate Launchpad in favor of POEditor - Stephanie/3.13 team |
15:19 |
sleary |
I'll let the rest of the team chime in since we're all here. We had some issues with Launchpad's translation branches not creating / updating automatically in the background like they're supposed to, and we had to get Galen to help figure out wha was going on. |
15:19 |
sleary |
I think this is related to the API flakiness. |
15:19 |
Bmagic |
anyone interested in forming an investigation? |
15:19 |
|
shulabear75 joined #evergreen |
15:19 |
Bmagic |
(into seeing how POEditor workflow plays out for both POT and Angular translations) |
15:20 |
terranm |
I cannot volunteer right now, but +1 to only having one place to manage translations |
15:20 |
Bmagic |
One thing that might be: POEditor doesn't poll our repo |
15:21 |
Bmagic |
LP does automatically sync our strings into it's mechanism via our git repo |
15:21 |
LindaJansova |
I agree, it would certainly be better to have one place to work on the translations :-). |
15:21 |
Dyrcona |
Well, when it works. Looks like we went a few months without any updates. |
15:21 |
Bmagic |
I don't think* POEditor does that |
15:21 |
sleary |
I think POEditor *can*, but is not currently set up. https://poeditor.com/kb/localization-file-management-with-github-bitbucket-and-gitlab-integrations is one place to start. |
15:22 |
Bmagic |
sleary++ |
15:22 |
Bmagic |
look at you bringing up the documentation |
15:22 |
Dyrcona |
I think it would be better for translators and release teams if there is only 1 place for translations. |
15:22 |
LindaJansova |
Also, POEditor search capabilities far surpass those available on Launchpad where it is not possible to search in more than one set of strings at the time. So +1 for POEditor! |
15:22 |
abneiman |
I'm generally a fan of anything that streamlines the build process, and currently we have like 10 translation steps and two separate places. Streamlining this makes it easier on translators as well as release teams. |
15:23 |
Bmagic |
one website to rule them all does sound attractive |
15:23 |
sleary |
the translation-related steps are a huge hurdle for release teams right now. |
15:23 |
sleary |
and no one understands the Launchpad processes very well. |
15:23 |
redavis |
If there is a team working or a potential team working on this, I'd be happy to be on the team (investigation team, I guess). |
15:23 |
LindaJansova |
One place would also help when we try to do some troubleshooting (nowadays it is rather complicated). |
15:23 |
Bmagic |
how do we move forward with this migration? |
15:24 |
sleary |
I think the investigation's goal will be to answer that question |
15:24 |
redavis |
It seems like the only real reticence is having an actual plan to get from LP to POEditor. |
15:24 |
Bmagic |
We need a team to dive in and click all the buttons? Who's on the team. We have one! kmlussier. |
15:25 |
kmlussier |
Huh? I don't think you want me on that team. |
15:25 |
redavis |
I mean...redavis^ |
15:25 |
abneiman |
I'm with you redavis |
15:25 |
Bmagic |
redavis, sorry, yes, redavis |
15:25 |
redavis |
abneiman++ |
15:25 |
sleary |
I am interested but abneiman will murder me in my sleep if I volunteer for anything else this month |
15:25 |
kmlussier |
redavis++ abneiman++ |
15:25 |
abneiman |
if we can get a dev who's familiar with the build process, I think redavis, said dev, and I can come up with something useful :-D |
15:26 |
Bmagic |
"these two hands" </rockbitter> |
15:26 |
sleary |
heh |
15:26 |
abneiman |
omg sleary lol |
15:26 |
Dyrcona |
I can see what I can do. I've had trouble using POEditor, but I think someone supposedly fixed that. |
15:26 |
abneiman |
but also, yeah, no |
15:26 |
redavis |
lol!!! |
15:26 |
kmlussier |
abneiman doesn't seem like the murderous type. |
15:26 |
mmorgan |
sleary: That would be counterproductive. |
15:26 |
abneiman |
thanks for the vote of confidence kmlussier, lmao |
15:26 |
redavis |
Dyrcona, wanna give it a go? |
15:26 |
Bmagic |
LindaJansova: interested in looking at it? |
15:26 |
csharp_ |
@who is the murderous type? |
15:26 |
pinesol |
Bmagic is the murderous type. |
15:26 |
csharp_ |
pinesol++ |
15:26 |
Dyrcona |
Bmagic is the Spy! |
15:27 |
Bmagic |
haha, I deserve that pinesol |
15:27 |
* redavis |
already knew that |
15:27 |
Dyrcona |
I'll take a look for sure. |
15:27 |
Bmagic |
ok, redavis and Dyrcona are officially a POEditor team? |
15:27 |
abneiman |
and me |
15:27 |
Bmagic |
!! |
15:28 |
redavis |
Okay, so then I'll send out a convening email to the team as it were. LindaJansova, we'd love you onboard as well if you can. |
15:28 |
LindaJansova |
I think I and EvaCe can have a look at it when the data are in POEditor but can also collaborate on the steps prior to that (although we are not that familiar with the processes behind the scenes, I'm afraid ;-)). |
15:28 |
LindaJansova |
Apologies, I appear to be a slower typer ;-). |
15:28 |
redavis |
LindaJansova++ |
15:28 |
Bmagic |
LindaJansova++ |
15:28 |
redavis |
lol, no worries. |
15:28 |
kmlussier |
LindaJansova++ |
15:28 |
Dyrcona |
LindaJansova++ |
15:28 |
abneiman |
it's ok LindaJansova - we're trying to fix the processes behind the scenes anyway! and we appreciate your input! |
15:28 |
LindaJansova |
:-) |
15:29 |
shulabear75 |
LindaJansova++ |
15:29 |
redavis |
LindaJansova and EvaCe, how about we include you in emails and updates, but with no obligation on your part? |
15:29 |
LindaJansova |
Sounds great :-)! |
15:29 |
Bmagic |
#action redavis, Dyrcona, abneiman, LindaJansova, EvaCe will investigate and see what it will take to move our translations to POEditor |
15:29 |
mmorgan |
redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++ |
15:30 |
Bmagic |
redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++ |
15:30 |
sleary |
redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++ |
15:30 |
csharp_ |
redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++, oh my! |
15:30 |
Bmagic |
that's probably the best outcome for this topic |
15:30 |
Bmagic |
we'll be excited to hear from yall next month |
15:31 |
Bmagic |
#topic New Business - LP#2060734: changes to the release process |
15:31 |
sleary |
ah, I put this on the agenda hoping sandbergja would be here to discuss it, but we'll have to do that in the comments / on the list. |
15:31 |
Bmagic |
I see |
15:32 |
Bmagic |
#topic New Business - Outstanding roadblocks to merging OpenSRF Redis? |
15:32 |
berick |
pretty much what it says. What else needs doing before we can merge to OpenSRF main? |
15:32 |
Bmagic |
is it converted to redis's replacement? |
15:33 |
berick |
no that will take time |
15:33 |
Dyrcona |
Which replacement did we decide on? |
15:33 |
Bmagic |
My understanding was that we can't adopt it officially because redis's rules? |
15:33 |
Bmagic |
valkey? |
15:33 |
berick |
Bmagic: not exactly |
15:33 |
csharp_ |
Dyrcona: ValKey |
15:33 |
berick |
the packages availabe now are perfectly fine to use |
15:33 |
Dyrcona |
I think we can adopt the versions that are packaged in current distros, can't we? |
15:33 |
csharp_ |
yes |
15:33 |
Dyrcona |
berick++ |
15:34 |
berick |
and we have a replacement plan, just have to wait for that stuff to settle down |
15:34 |
berick |
which won't affect the code, just the docs/installers |
15:34 |
Bmagic |
ok, so we can* keep using redis, via the git branch's auto-installer? |
15:34 |
Dyrcona |
I haven't seen package for ValKey, yet. |
15:34 |
csharp_ |
Bmagic: yep |
15:35 |
Bmagic |
hmmm, so the question is: do we merge it before ValKey is "out" ? |
15:35 |
Bmagic |
with the understanding that we will have a follow-up LP to update the bits for ValKey when that's possible |
15:35 |
berick |
the bigger qestion for me is whether the functionality is complete for the various use cases |
15:36 |
berick |
which is to some extent aimed at the Equinox folks |
15:36 |
Dyrcona |
I've been using it since October on a test instance and haven't noticed anything that doesn't work. |
15:36 |
Bmagic |
We have it running on production, for a small library. Working just fine. Though, I'd feel more confident if it were on production for a larger library/consortium |
15:37 |
berick |
Bmagic: i'm deploying it as soon as it's merged to opensrf main |
15:37 |
berick |
(part of why i'm asking now, want to get going on it) |
15:37 |
Bmagic |
merging it doesn't make it required: just making sure that's clear |
15:37 |
csharp_ |
not that it helps us with debian(-ish) things, but Fedora already has valkey in the repos |
15:37 |
berick |
csharp_: oh neat |
15:37 |
Bmagic |
Fedora is a speeding bullet that no one will catch |
15:38 |
csharp_ |
as well as valkey-compat-redis.x86_64 : Conversion script and compatibility symlinks for Redis |
15:38 |
jeff |
debian will be a while, I'm sure. request is here, no update since two months ago: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068342 |
15:38 |
pinesol |
jeff: Error: Could not parse data returned by Debian: |
15:38 |
jeff |
none of that prevents use or merging. |
15:38 |
Bmagic |
merging it is pretty much fine right? Like people can ignore it and keep using ejabberd? |
15:39 |
csharp_ |
jeff: we'll probably need to use a PPA if it becomes a thing |
15:39 |
jeff |
possibly eeevil or gmcharlt or JBoyer have input/thoughts/feedback but may be unavailable to comment. |
15:39 |
jeff |
(I think that's who berick was asking, for the most part) |
15:39 |
berick |
Bmagic: not exactly, you'd have to use an already-released version of opensrf to use ejabberd |
15:39 |
Bmagic |
i see |
15:39 |
berick |
once on main, it's only redis, no side-by-side |
15:40 |
csharp_ |
I think it's fine to say OpenSRF < 4.0 (or whatever) is ejabber-friendly |
15:40 |
Bmagic |
But that's just OpenSRF, on the Evergreen side, you don't have to do anything? For example, if someone installs Evergreen 3.14, they can use OpenSRF 3.3.0 without issue |
15:40 |
csharp_ |
don't upgrade if you want to stay on ejabberd |
15:40 |
csharp_ |
@who wants to stay on ejabberd? |
15:40 |
pinesol |
eby wants to stay on ejabberd. |
15:40 |
Dyrcona |
Bmagic: Evergreen already installs the Redis packages. |
15:41 |
berick |
right it only affects opensrf |
15:41 |
Dyrcona |
I think we should maybe get Ubuntu 24.04 installation support first. https://bugs.launchpad.net/evergreen/+bug/2054842 |
15:41 |
pinesol |
Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] - Assigned to Jason Stephenson (jstephenson) |
15:41 |
Bmagic |
ejabberd is a pain in my neck, and I can't wait to be rid of it. So, you've got no resistance from me :) |
15:41 |
Dyrcona |
Redis is more like tennis elbow... :) |
15:41 |
jeff |
the idea as I recall was OpenSRF 3.x = ejabberd, OpenSRF 4.x = redis/valkey/whatever, and merging redis to OpenSRF main and releasing OpenSRF 4.x does not mean that Evergreen x.y can't continue to work with OpenSRF 3.x or 4.x, but I've been wrong before. :-) |
15:42 |
csharp_ |
I used to not care, but the pain over the last few versions/ubuntu releases has been signficant |
15:42 |
csharp_ |
jeff: that was my understanding too |
15:42 |
Dyrcona |
csharp_: Ubuntu 24.04 just works with ejabberd this time. We got lucky. :) |
15:43 |
kmlussier |
Dyrcona: I have tennis elbow. It's quite painful. |
15:43 |
csharp_ |
the thin ice we're skating on held! (this is fine dog) |
15:43 |
* kmlussier |
is hoping reddis isn't quite so painful. |
15:43 |
Dyrcona |
jeff csharp_: Yeah, that was my suggestion about the numbering. |
15:43 |
Bmagic |
We have a few systems adopting 3.13 over the next few months, I think we can give redis a whirl at the same time. I'd like to see it up and running in a larger environment as proof. I don't think any test environment can do what a production environment does |
15:44 |
Dyrcona |
kmlussier: I'm sorry, didn't mean to make light of it. All software is some kind of pain to use. |
15:44 |
Dyrcona |
berick has done a great job making the Redis integration just work. Very little configuration required. |
15:44 |
Bmagic |
agreed berick++ |
15:44 |
csharp_ |
I think we're in a chicken/egg situation - I don't want to move PINES to anything that's not in main and we don't want it in main until someone like PINES is running it live :-) |
15:45 |
Bmagic |
I don't know where all of this leaves us |
15:45 |
Dyrcona |
So, are we at an impasse then? |
15:45 |
berick |
my concern is deploying to prod, then the branch meets merge resistance, and now i'm running significantly different key infrastucture code |
15:45 |
berick |
exactly, chicken and egg |
15:45 |
Bmagic |
I will get it installed on a larger production environment and report back. Will that work for now? |
15:45 |
redavis |
Bmagic++ |
15:45 |
shulabear75 |
csharp++ berick++ |
15:45 |
csharp_ |
or a game of chicken, or something about chickens |
15:45 |
redavis |
GuineaPigs++ |
15:45 |
shulabear75 |
csharp_++ |
15:45 |
Dyrcona |
Bmagic++ |
15:45 |
csharp_ |
kaw ke kaw! |
15:46 |
Bmagic |
alright, next |
15:46 |
Bmagic |
#topic New Business - Backport guidelines? What should be backported? - Stephanie/code review team |
15:46 |
sleary |
ah, this came up last week. |
15:46 |
shulabear75 |
as someone who deals with a lot of front-end users in PINES, i am completely with Chris on this for my own sanity in the days after the eventual update. |
15:46 |
abneiman |
this is a good question to revisit |
15:47 |
sleary |
I don't think we have any real guidelines for committers on what things should be backported, and the main question was whether it's wise to backport things that involve string changse. |
15:47 |
sleary |
changes. |
15:47 |
sleary |
database updates, also, but strings are more common in potentially backportable things |
15:47 |
Dyrcona |
So.... My opinion: We backport too many schema changes... Josh Berkus thought we were kind of nuts when we talked about it in Vancouver all those years ago. |
15:48 |
redavis |
Dyrcona++ |
15:48 |
Dyrcona |
Also, we used to not keep translations up to date for backport branches. This meant backport string changes weren't readily translatable. |
15:49 |
Dyrcona |
We are updating strings for point releases, now, but we could stop if we say no string changes. |
15:50 |
abneiman |
I agree with Dyrcona re backporting schema changes, unless it's critical. I can go either way about string changes. |
15:50 |
redavis |
seems like if there are security things that can easily be backported, okay. And, if there's perhaps a regression that gets fixed for a new release and can...again...be EASILY backported...that makes sense. Otherwise, it seems to just make sense to aim for now and forward. |
15:50 |
mmorgan |
If translations were more manageable, maybe it would make sense not to restrict backporting string changes. |
15:50 |
abneiman |
I'd like to hear from our translators about string changes in point releases ... and mmorgan makes a very good, er, point about more manageable translations |
15:51 |
redavis |
agreed with mmorgan and abneiman |
15:51 |
LindaJansova |
A sidenote - perhaps it would be beneficial to have specific mentions of time slots for doing the translation work in the release schedule (which now only contains String Freeze). |
15:51 |
redavis |
LindaJansova++ |
15:51 |
redavis |
Noted |
15:51 |
sleary |
LindaJansova++ |
15:51 |
EvaCe |
LindaJansova++ |
15:51 |
LindaJansova |
As to changes in point releases - probably once the time slots are introduced and we now (= can plan) when to translate, it would be fine with us :-). |
15:52 |
abneiman |
noted LindaJansova - however for point releases, we usually don't have as formal a schedule. It's more like, what's ready? OK cut release! on an approximately monthly schedule |
15:52 |
abneiman |
which I think is currently 3rd Wednesdays (for point releases) |
15:52 |
abneiman |
though we haven't done one since April, since May was all 3.13 all the time, and noting that third Wednesday in June is a US federal holiday |
15:53 |
sleary |
we could plan those a little better and put things on the community calendar if we need to |
15:53 |
redavis |
sleary++ |
15:53 |
mmorgan |
sleary++ |
15:53 |
Bmagic |
not sure I'm seeing an action item |
15:53 |
LindaJansova |
Okay :-) but perhaps having a clear schedule would be good anyway (maybe living elsewhere than in the release schedule wiki page if that one would make things more complicated?)... |
15:54 |
LindaJansova |
sleary++ |
15:54 |
Dyrcona |
I think we should just stop point releases after a new x+1 release is made. If people do upgrade past the point of the generated upgrade script, it makes upgrading to a new major release that much harder. |
15:55 |
redavis |
LindaJansova, I think we can better utilize the community calendar to include release activities including string freezes. |
15:56 |
Bmagic |
redavis: would you like that action? Editing the calendar along these lines? |
15:56 |
redavis |
Bmagic, yes...but I am not exactly sure when that will happen since there's some cat herding to happen prior... |
15:57 |
redavis |
So, go ahead and add that action item for me, and then I'll just report on where it stands at the next meeting...whether "done" or "progressed" or whatever. |
15:57 |
eeevil |
Dyrcona: every release is a major release? |
15:57 |
Dyrcona |
redavis: I think for 3.14 we can discuss a schedule with time set aside for translation work. |
15:58 |
redavis |
Dyrcona++ email to you and the rest of the team headed out tomorrow. |
15:58 |
Bmagic |
#action redavis will look at making a regular calendar event for translation work in lock step with point releases |
15:58 |
kmlussier |
If we have a clearer idea of what the release schedule should be, it would help with scheduling the translations. |
15:58 |
Dyrcona |
eeevil: Almost. We get questions all the time about how I do upgrade A.B.G to X.Y.Z when the db upgrade is for AB.D to X.Y.Z and so on. |
15:58 |
Bmagic |
we're coming up to our hour |
15:58 |
Dyrcona |
I honestly don't think we have the human resources to do monthly point releases. |
15:59 |
kmlussier |
A conversation for another day? :) |
15:59 |
Dyrcona |
I won't be there. |
15:59 |
redavis |
kmlussier, I think we're talking about that on Thursday. |
15:59 |
eeevil |
I agree with the resource vs monthlies point, fwiw |
15:59 |
Bmagic |
Next month's regular meeting would be July 9th, I'm not going to be able to make that |
15:59 |
mmorgan |
If we can better streamline the release process, it would take fewer resources. |
16:00 |
kmlussier |
redavis: Yes, Thursday at 12 p.m. Eastern. |
16:00 |
abneiman |
yes, I strongly encourage everyone who's interested in the release conversations to attend the discussion kmlussier is hosting this Thursday! |
16:00 |
kmlussier |
Sorry Dyrcona. I went by what was in the Doodle poll. |
16:00 |
eeevil |
but, all software has bugs, so I'm not sure I'm on board with every-release-is-an-island |
16:00 |
redavis |
kmlussier++ abneiman++ |
16:00 |
Dyrcona |
eeevil: I'm not saying that either exactly. |
16:01 |
Bmagic |
anyone want to take this July 9th meeting? |
16:01 |
* redavis |
hums "features in the stream...that is what we are." |
16:01 |
Bmagic |
#topic Announcements |
16:02 |
abneiman |
Bmagic: I can lead the 7/9 meeting |
16:02 |
eeevil |
redavis: great, now /that'll/ be in my head for 2 hours... :P |
16:02 |
kmlussier |
Bmagic: If nobody else volunteers, I can take it. But I'll be running back from a dental appointment. |
16:02 |
Bmagic |
#info Next Meeting is Tuesday, July 9th 2024 |
16:02 |
terranm |
I have another quick topic before everybody leaves - is August a good time for the next Bug Squashing Week? (kmlussier pointed out that it'll be the 10 year anniversary of community bug squashing events) |
16:02 |
kmlussier |
Never mind. abneiman beat me to it. |
16:02 |
redavis |
eeevil, success is my only aim...muahahahahah |
16:02 |
Bmagic |
abneiman++ # it's yours! I'll do the wiki dance after this one, you get July 9th's privilege |
16:02 |
abneiman |
ta |
16:02 |
redavis |
terranm, I was going to email you about that too! |
16:03 |
kmlussier |
August 26 to be exact. |
16:03 |
eeevil |
redavis: "no release between, how can it be wrong" |
16:03 |
terranm |
We could do August 26-30 |
16:03 |
redavis |
eeevil++++++++++++++++++++ |
16:03 |
Bmagic |
terranm: looks good for me |
16:04 |
redavis |
terranm, perfect |
16:04 |
sleary |
terranm++ |
16:04 |
terranm |
Maybe we'll have the new circ/patron interfaces to test then? |
16:04 |
LindaJansova |
terranm++ |
16:04 |
redavis |
terranm++ |
16:04 |
Bmagic |
terranm++ |
16:04 |
mmorgan |
terranm++ |
16:04 |
terranm |
Thanks, I'll put it on the calendar and all that |
16:04 |
Bmagic |
thanks everyone! Good turn out this month |
16:04 |
kmlussier |
I have questions about the new circ/patron interfaces, but I'll send it in an email. |
16:04 |
Bmagic |
#endmeeting |
16:04 |
pinesol |
Meeting ended Tue Jun 11 16:04:47 2024 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
16:04 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-06-11-15.00.html |
16:04 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-06-11-15.00.txt |
16:04 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-06-11-15.00.log.html |
16:04 |
sleary |
terranm there is a pull request on that now, although someone pointed out a couple of things that might be missing, so I'll update that branch soon |
16:05 |
kmlussier |
Bmagic++ |
16:05 |
abneiman |
Bmagic++ |
16:05 |
mmorgan |
Bmagic++ |
16:05 |
abneiman |
sleary++ # circ interfaces PR |
16:05 |
LindaJansova |
Bmagic++ |
16:05 |
redavis |
Bmagic++ |
16:05 |
terranm |
Bmagic++ |
16:05 |
sleary |
Bmagic++ |
16:05 |
Dyrcona |
Bmagic++ |
16:05 |
kmlussier |
@karma |
16:05 |
pinesol |
kmlussier: Highest karma: "berick" (42), "Dyrcona" (40), "Bmagic" (35), "sleary" (27), and "eeevil" (22). Lowest karma: "comcast" (-8), "dojo" (-3), "NSA" (-1), "runaround" (-1), and "actual_evil" (-1). You (kmlussier) are ranked 7 out of 61. |
16:07 |
csharp_ |
comcast-- |
16:09 |
|
shulabear joined #evergreen |
16:09 |
redavis |
Dyrcona, terranm, I've updated the 3.14 release schedule with the August bugsquash week |
16:09 |
Dyrcona |
redavis++ |
16:09 |
eeevil |
Dyrcona: I think raising the db-change bar MUCH higher on back branches once the next major is out might be a compromise? that seems like it would have the intended effect in practice... like, replacing functions (without breaking the API) or fixing security issues is fine, but otherwise it's a "no" by default. if someone wants to put in the work to make a later-major upgrade script do all the right things (lots of IF EXISTS, DO blocks to check for |
16:09 |
eeevil |
stuff, etc) then, "maybe, let's discuss"? |
16:10 |
eeevil |
is that what you're thinking? |
16:10 |
sleary |
Dyrcona redavis pro tip: when you make the schedule, don't forget to actually schedule the meetings for building the releases. (Guess what the 3.13 team forgot to do. >.<) |
16:11 |
terranm |
redavis++ |
16:11 |
redavis |
lol, thank you for the reminder. We'll definitely do that. |
16:11 |
Dyrcona |
eeevil: Mostly something like that. I also think not doing tarballs would help and switch to actual git tags instead of tag branches. |
16:11 |
redavis |
I ain't nothing if not a meeting scheduler. |
16:12 |
mmorgan |
Just a thought - maybe db and string changes only get backported to .1 and .2 point releases (or something like that) |
16:12 |
Dyrcona |
By "not doing tarballs" I mean not doing tarballs for point releases after a certain point. I don't know who uses them. |
16:14 |
kmlussier |
redavis: That's been the one thing I've hated most about every job I've had since 2010. |
16:14 |
Dyrcona |
kmlussier++ |
16:14 |
sleary |
kmlussier++ # That is the one thing I actually *would* like an AI assistant for. |
16:15 |
Dyrcona |
sleary++ |
16:15 |
Dyrcona |
I saw a comment the other day along the lines of: I was hoping for AI to do my dishes and fold my laundry while I do art and writing, and not the other way around. |
16:15 |
sleary |
yep |
16:16 |
kmlussier |
I always used the severity of the bug as the metric for determining whether a database or string change should be backported. |
16:16 |
|
jihpringle joined #evergreen |
16:16 |
mmorgan |
kmlussier++ |
16:17 |
Dyrcona |
I've pretty much just backported without thinking about it too much, but I think we should put more thought behind it. |
16:18 |
sleary |
I would really like us to have a written set of guidelines (or "more of a suggestion") for newer committers |
16:18 |
terranm |
+1 to better guidelines. I'm still a very nervous committer. |
16:18 |
mmorgan |
+1 |
16:19 |
mmorgan |
terranm: I think I will always be a nervous committer. |
16:19 |
terranm |
I mean, caution is often a good thing |
16:19 |
terranm |
Just not the anxiety part :D |
16:20 |
mmorgan |
caution++ anxiety-- |
16:20 |
terranm |
mmorgan++ |
17:05 |
|
mmorgan left #evergreen |
18:05 |
|
kmlussier left #evergreen |
18:49 |
|
jihpringle joined #evergreen |
20:03 |
pinesol |
News from commits: LP2015112 follow-up: ng lint --fix <https://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=72173f76e08b0455f0dc7fa38bcfd4e2f00b02b9> |