| Time |
Nick |
Message |
| 07:17 |
|
collum joined #evergreen |
| 07:37 |
|
kworstell-isl joined #evergreen |
| 07:51 |
|
BDorsey joined #evergreen |
| 07:57 |
|
stephengwills joined #evergreen |
| 08:41 |
|
mmorgan joined #evergreen |
| 08:54 |
|
Dyrcona joined #evergreen |
| 09:26 |
|
dguarrac joined #evergreen |
| 10:14 |
|
jihpringle joined #evergreen |
| 10:53 |
|
Dyrcona joined #evergreen |
| 11:04 |
|
sandbergja joined #evergreen |
| 11:22 |
Dyrcona |
Looks like I lost my bug report, and I'll have to type it all over, unless my browser still has it by some miracle. |
| 11:23 |
Bmagic |
I hate when that happens |
| 11:23 |
Bmagic |
there are no miracles, only programmers |
| 11:25 |
Dyrcona |
Well, my browser still had the text for the big text box, so there's that. |
| 11:26 |
Bmagic |
couldn't have worked out better :) |
| 11:27 |
Dyrcona |
Well, it could have gone through the first time, but yeah.... :) |
| 11:31 |
|
mantis joined #evergreen |
| 13:06 |
|
Stompro joined #evergreen |
| 13:33 |
Dyrcona |
*** buffer overflow detected ***: terminated |
| 13:33 |
Dyrcona |
That's from starting OpenSRF services on Ubuntu 24.04 for the first time. Fun stuff. |
| 13:34 |
berick |
exciting |
| 13:34 |
Dyrcona |
looks like the C code. |
| 13:37 |
Dyrcona |
The routers, opensrf.cslow, opensrf.dbmath, and opensrf.math all get terminated. |
| 13:41 |
Dyrcona |
The surviving services all have something like this in osrfsys.log: server: Listener received an XMPP error message. Likely a bounced message. sender=router private.localhost/router |
| 13:41 |
Dyrcona |
Probably because the router ain't there. |
| 13:51 |
Dyrcona |
looks like a "new thing" with gcc 12+. I'm gonna have to read some documentation, but I think some compiler options might be able to catch it at compile time, then we can fix it. |
| 13:54 |
Dyrcona |
That assumes that the problem is in our code and not some library or something else we use. |
| 14:09 |
Dyrcona |
And, it's not a new thing. |
| 14:10 |
Dyrcona |
The buffer overflow protection isn't new, I mean. |
| 14:18 |
Dyrcona |
compiler warnings are pretty sparse: a couple of functions defined but not used. |
| 14:34 |
|
kenstir joined #evergreen |
| 14:44 |
Dyrcona |
I should try the Redis branch to see if maybe it's Ejabberd causing the problem. |
| 14:47 |
Bmagic |
13 minutes till dev meeting |
| 14:52 |
|
kenstir joined #evergreen |
| 14:54 |
kenstir |
I want to send push notifications from EG to the mobile apps. I know how to do it in the app and in Firebase. I am starting to investigate how to add it to the OSRF API and database. Is this an appropriate topic for the dev meeting? |
| 14:55 |
Bmagic |
5 minutes till dev meeting |
| 14:56 |
Dyrcona |
kenstir: It's probably a bit late for today. |
| 14:59 |
kenstir |
Dyrcona: I'll wait until after the meeting then to ask for schema hints. |
| 15:00 |
Bmagic |
#startmeeting 2024-04-09 - Developer Meeting |
| 15:00 |
pinesol |
Meeting started Tue Apr 9 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_04_09___developer_meeting' |
| 15:00 |
Bmagic |
#info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-04-09 |
| 15:00 |
Bmagic |
#topic Introductions#topic Introductions |
| 15:00 |
Bmagic |
#info Bmagic = Blake GH, MOBIUS |
| 15:00 |
Dyrcona |
#info Dyrcona = Jason Stephenson, C/W MARS, Inc. |
| 15:00 |
phasefx |
#info phasefx = Jason Etheridge, EOLI |
| 15:00 |
berick |
#info berick Bill Erickson, KCLS |
| 15:00 |
Stompro |
#info Stompro = Josh Stompro, LARL |
| 15:01 |
mmorgan |
#info mmorgan = Michele Morgan, NOBLE |
| 15:01 |
sleary |
#info sleary = Stephanie Leary, EOLI |
| 15:01 |
jeff |
#info jeff = Jeff Godin, Traverse Area District Library (TADL) |
| 15:02 |
Bmagic |
feel free to introduce yourselves throughout |
| 15:02 |
Bmagic |
#topic Action Items from Last Meeting |
| 15:02 |
Bmagic |
#info mmorgan will explore moving LP stats to community site and automating same |
| 15:02 |
mmorgan |
Still looking at this. I did just want to share this sheet with some charts from the stats since I started compiling them: |
| 15:02 |
sandbergja |
#info sandbergja = Jane Sandberg, PUL |
| 15:02 |
mmorgan |
https://docs.google.com/spreadsheets/d/1igd02X0VjIcJrGdmcEQ34bAha8b3IHYprHkdZhcOkkE/edit?usp=sharing |
| 15:03 |
Bmagic |
mmorgan++ |
| 15:03 |
sandbergja |
charts++ |
| 15:03 |
sandbergja |
mmorgan++ |
| 15:03 |
sleary |
mmorgan++ |
| 15:04 |
Bmagic |
I think it's the right thing |
| 15:04 |
JBoyer |
JBoyer = Jason Boyer, EOLI |
| 15:04 |
JBoyer |
#info JBoyer = Jason Boyer, EOLI |
| 15:04 |
mmorgan |
Any input appreciated! |
| 15:05 |
Bmagic |
thanks mmorgan! I suppose the hurdle we have is getting the raw data in there |
| 15:05 |
Bmagic |
seems like we need a program (maybe we already do?) to interact with LP's API |
| 15:06 |
mmorgan |
Dyrcona shared some python scripts which I've been looking at. |
| 15:06 |
mmorgan |
Still coming up the curve. |
| 15:06 |
Bmagic |
Dyrcona++ |
| 15:06 |
mmorgan |
Dyrcona++ |
| 15:06 |
Bmagic |
let us know if anyone can help! |
| 15:06 |
Dyrcona |
Those were mostly for manipulating bug statuses, and last time I tried them they didn't work. The API has changed over the years. |
| 15:07 |
scottangel |
#info scottangel = Scott Angel, MOBIUS |
| 15:07 |
mmorgan |
Dyrcona: I did manage to get counts back with a few changes, so it's a start. |
| 15:07 |
Dyrcona |
mmorgan++ |
| 15:08 |
Bmagic |
excellent |
| 15:08 |
Bmagic |
anything else? |
| 15:08 |
mmorgan |
Not at this time. |
| 15:08 |
Bmagic |
#info gmcharlt - create a Git commit message type and update bug 2051946 |
| 15:08 |
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:08 |
Bmagic |
I don't suppose he's here, and it seems* like it's done at this point |
| 15:09 |
Bmagic |
I've used the code that generates the release notes, pretty snazzy |
| 15:10 |
Bmagic |
This bug is about committing a template, like the one described here: https://gist.github.com/lisawolderiksen/a7b99d94c92c6671181611be1641c733 |
| 15:10 |
Bmagic |
is that right? |
| 15:11 |
Stompro |
Bmagic, I think you are correct. |
| 15:12 |
Bmagic |
ok, we'll kick it down the road |
| 15:12 |
Bmagic |
#action gmcharlt - create a Git commit message type and update bug 2051946 |
| 15:12 |
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:12 |
Bmagic |
#action mmorgan will explore moving LP stats to community site and automating same |
| 15:12 |
Bmagic |
#topic Launchpad Status (as of noon Eastern) |
| 15:13 |
Bmagic |
#info Open Bugs - 3063 |
| 15:13 |
Bmagic |
#info Pullrequests - 92 |
| 15:13 |
Bmagic |
#info Signedoff - 13 |
| 15:13 |
Bmagic |
#topic Launchpad Status since last meeting |
| 15:13 |
Bmagic |
#info Bugs Added - 42 |
| 15:13 |
Bmagic |
#info Pullrequest tag Added - 43 |
| 15:13 |
Bmagic |
#info Signedoff tag Added - 34 |
| 15:13 |
Bmagic |
#info Fix Committed - 37 |
| 15:13 |
Bmagic |
#topic New Business - LP#1017990 - let's deprecate and/or remove the open-ils.circ.holds.create APIs! |
| 15:14 |
Bmagic |
jeffdavis? |
| 15:14 |
Bmagic |
anyone want to comment on the idea? |
| 15:15 |
Dyrcona |
We usually announce the removal of something a release or two in advance to give people warning who may be using those APIs n custom apps. |
| 15:16 |
berick |
+1 to deprecating |
| 15:16 |
berick |
there are better apis |
| 15:16 |
kenstir |
The Hemlock app has not called open-ils.circ.holds.create in 5+ years. |
| 15:16 |
Dyrcona |
Deprecate for 3.13 and remove in whatever comes after? |
| 15:17 |
Bmagic |
Dyrcona++ # yes, that sounds reasonable, considering this bug is 12+ years old |
| 15:18 |
mmorgan |
+1 |
| 15:18 |
Bmagic |
It's already a thread on the dev list? |
| 15:18 |
|
smorrison joined #evergreen |
| 15:19 |
Bmagic |
I don't see it actually. Should this become an emailed announcement+blog post? |
| 15:20 |
Dyrcona |
Yes, and it should be in the release notes for the next release as well. |
| 15:21 |
Dyrcona |
It would be nice if we tag an API as deprecated and it would generate a warning when used. |
| 15:21 |
Bmagic |
anyone want to volunteer for the email+blog post? |
| 15:22 |
Bmagic |
That would be cool, Dyrcona: are you aware of an example API where we've done that. Something to crib from? |
| 15:23 |
berick |
$logger->warn(...) ? |
| 15:23 |
Dyrcona |
I meant "it would be nice if we [could] tag an API as deprecated." We can't right now. |
| 15:23 |
Dyrcona |
but, yeah, adding logger->warn() would work. |
| 15:23 |
Bmagic |
berick: that seems easy enough, though I was thinking it would be in the return payload back to the caller |
| 15:24 |
Dyrcona |
Putting it in the payload might break things, but then 3rd parties wouldn't get the message. |
| 15:24 |
berick |
yeah, that's all new |
| 15:24 |
JBoyer |
Not a good idea to just drop random notes in an API reply, especially one so old we want to remove it, may as well just take it out if it's going to start confusing old clients. |
| 15:24 |
Bmagic |
ok, payload is out, the log warning? |
| 15:25 |
JBoyer |
Loud logging is the best way to alert sysadmins, who can hopefully track down what's calling it |
| 15:25 |
Bmagic |
so this already-existing branch, could use that addition? |
| 15:25 |
Bmagic |
well, no, that branch is removing |
| 15:26 |
Bmagic |
so, a new* branch with that change for the 3.13 release, then csharp's branch merges in 3.14? |
| 15:26 |
eeevil |
fwiw, there is the original API versioning scheme we could leverage. that's more about letting the client choose a compat level, but we can add logging there |
| 15:27 |
eeevil |
#info eeevil == Mike Rylander, EOLI |
| 15:29 |
Bmagic |
so, we're logging for sure, who wants to branch that? |
| 15:30 |
Bmagic |
I can do the announcement pieces |
| 15:31 |
Bmagic |
#action Bmagic will write announcement+blog post for deprication of open-ils.circ.title_hold.is_possible and open-ils.circ.holds.create[.override] |
| 15:31 |
Bmagic |
I'll fix the spelling :) |
| 15:31 |
berick |
maybe that should just go into the LP, the intermediate patching for warning |
| 15:31 |
JBoyer |
#action JBoyer will throw a branch on lp 1017990 to loudly inform the logs something is still calling that ^ |
| 15:31 |
pinesol |
Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990 |
| 15:32 |
Bmagic |
JBoyer++ |
| 15:32 |
Bmagic |
I forgot to add this |
| 15:32 |
Bmagic |
#link https://bugs.launchpad.net/evergreen/+bug/1017990 |
| 15:32 |
Bmagic |
Shall we move on? |
| 15:33 |
Bmagic |
#topic New Business - LP#2042158 - should we recommend disabling Postgres JIT? |
| 15:33 |
Bmagic |
#link https://bugs.launchpad.net/evergreen/+bug/2042158 |
| 15:33 |
pinesol |
Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [Undecided,Confirmed] - Assigned to Galen Charlton (gmc) |
| 15:33 |
Bmagic |
yall are quiet today :) |
| 15:35 |
Bmagic |
gmcharlt isn't here, it's assigned to him. I think he was going to explore making Evergreen JIT-compatible? |
| 15:35 |
sandbergja |
I was curious: what about the JIT causes these performance issues? Do we have any postgres docs saying what we would need to change? |
| 15:35 |
Bmagic |
I found it rear it's head when saving a bib record in the staff client |
| 15:36 |
Dyrcona |
Bmagic: You sure that's the JIT? Saving a bib can sometimes be slow because of all the triggers. |
| 15:37 |
Bmagic |
I think* it was saving a bib record, which in-turn queried reporter.old_super_simple_record - which is what's written on the bug report |
| 15:37 |
eeevil |
there are certain things that JIT wants to do that we have already poured a lot of brain power into manually tuning |
| 15:37 |
Bmagic |
that makes sense |
| 15:38 |
eeevil |
it's not that EG is incompatible with PG's JIT, it's that (just like autovac and stats targets, and lots of other stuff, tbh) it requires config that is tuned to your particular size and shape of data |
| 15:39 |
eeevil |
a small EG instance may benefit a BUNCH from JIT, and reporting might as well (I've tested neither, but I have suspicions) |
| 15:40 |
sandbergja |
thanks, eeevil, that's helpful info to have |
| 15:40 |
eeevil |
but(!) unless someone has the tuits to learn the feature well, and analyze our queries in that context, I agree that we should recommend disabling JIT for now |
| 15:40 |
Bmagic |
eeevil++ |
| 15:41 |
eeevil |
I'd actually propose we investigate (as a community, as broadly as we can manage) cross-column stats targets before jumping into JIT |
| 15:41 |
Dyrcona |
I'm OK with that, but I don't think I've every encountered an issue caused by JIT. Pg 16 (even unoptimized) has pretty much always been faster than Pg 10 for me. BUT! I've not run it in produciton, just in testing on a production-sized database with a production-sized server. |
| 15:41 |
eeevil |
(not to derail the JIT-specific discussion, but as a query tuning tool I think that will pay off for more folks) |
| 15:42 |
eeevil |
Dyrcona: I haven't seen JIT-specific issues either, but I think we can be fairly sure that plan stability is /higher/ without JIT (until we learn to tune it well) |
| 15:43 |
Bmagic |
Disabling it fixed our problem on a test-then-production instance |
| 15:43 |
Bmagic |
pretty sure it manifested as a time-out when clicking on save in the MARC editor |
| 15:43 |
Dyrcona |
So, we'll recommend disabling JIT in the installation instructions, then. |
| 15:43 |
eeevil |
which is to say, yes, some folks will lose out on some optimizations they get "for free" with JIT on, but things are much less likely to go sideways in ways some have seen |
| 15:45 |
Bmagic |
I understand that PG is sensitive to the data within, and the configuration tweaks need to match. I made tweaks to the best of my abilities to match the machine's memory compared to database size. shared_buffers, default_statistics_target, work_mem, wal_buffers etc |
| 15:45 |
Dyrcona |
Well, tuning PostgreSQL still feels too much like voodoo to me. :) |
| 15:46 |
Bmagic |
eeevil: maybe a different bug for cross-column stats targets? |
| 15:46 |
eeevil |
Bmagic: oh, yes, definitely. that should not go on the JIT bug |
| 15:47 |
Bmagic |
(we do need to move on, down to 13 minutes) |
| 15:47 |
Bmagic |
want an action item? |
| 15:47 |
eeevil |
want, and "have any time at all for" are non-overlapping sets, today |
| 15:47 |
Bmagic |
#action eeevil will open a bug for cross-column stats targets |
| 15:47 |
Bmagic |
in your face |
| 15:47 |
eeevil |
I've been volun-told! |
| 15:47 |
Bmagic |
:) |
| 15:48 |
Bmagic |
I think we can leave the JIT discussion there, PG 12+ is still experimental |
| 15:48 |
Bmagic |
I'll add it to next month's topics too |
| 15:49 |
Bmagic |
#topic New Business - Redis licensing change / discussion of potential replacement |
| 15:49 |
Dyrcona |
Looks like the distros are going with ValKey. |
| 15:49 |
berick |
yeah |
| 15:49 |
jeff |
based on LF's support, yeah. |
| 15:49 |
jeff |
works for me! |
| 15:49 |
Bmagic |
ValKey++ |
| 15:49 |
Bmagic |
berick++ |
| 15:50 |
berick |
it'll be a while before valkey is packagable .. tons of activity on there now |
| 15:50 |
Bmagic |
redis-- |
| 15:50 |
berick |
to rebrand, etc. |
| 15:50 |
berick |
i mean it's usable, but not something you want to create a lot of documentation around just yet |
| 15:51 |
Bmagic |
any clue when* ? |
| 15:51 |
berick |
not I |
| 15:52 |
Bmagic |
8 minutes..... anything else on this one? |
| 15:52 |
berick |
i guess question is, continue as-is with Redis, then switch later, or pause the whole shebang until Valkey is ready enough for the community |
| 15:52 |
berick |
but we can discuss more at the Hatckfest |
| 15:52 |
jeff |
with current "Evergreen works on these distros" packaging redis (a version before the license change), is there any reason/value in installing ValKey on those systems? Use distro-supplied redis packages until distro-supplied ValKey packages are the norm? |
| 15:53 |
Bmagic |
we've not merged the OpenSRF branch, so, we can wait right? |
| 15:53 |
berick |
jeff: yeah, i don't see any need to rush the valkey. it's the same code. |
| 15:53 |
jeff |
if there's reason to install ValKey (a la pgdg apt repos like with Postgres), then by all means... but if not, it's... yeah, just a name in this scenario. |
| 15:53 |
berick |
rather, any need to run screaming from Redis just yet |
| 15:53 |
Bmagic |
or, jeff, are you saying, we merge the branch with the older redis sooner, rather than waiting for valkey? |
| 15:54 |
berick |
merging sooner would be my pref, but that's probably no surprise |
| 15:55 |
jeff |
close. i was asking if there was reason to wait for valkey to stabilize and be widely available in our favorite linux distros by default. sounds like there's no need to wait. |
| 15:55 |
Bmagic |
to be continued at hackfest |
| 15:55 |
berick |
Bmagic: how's it going, btw, w/ Redis? |
| 15:55 |
Bmagic |
It's running so fine, it's just working. I don't think about it |
| 15:55 |
* Dyrcona |
is going to try Redis on Ubuntu 24.04 to see if it affects the buffer overflow I get when starting OpenSRF services. |
| 15:56 |
Bmagic |
but yes, we have it on a small production instance |
| 15:56 |
berick |
awesome Bmagic++ |
| 15:56 |
Bmagic |
#topic New Business - Release branch proposals – anything we can move forward with? |
| 15:56 |
Bmagic |
sorry we're probably going to go over time |
| 15:56 |
Bmagic |
#link http://list.evergreen-ils.org/pipermail/evergreen-dev/2024-March/000777.html |
| 15:56 |
sandbergja |
Thanks for all who have discussed this on the mailing list so far |
| 15:57 |
sandbergja |
Just wondering if there is anything there that is actionable |
| 15:57 |
sandbergja |
in the interest of reducing the number of things we have to think about while building releases (which is currently too many for me personally, I always find that I create the release tag branch at the wrong time in the process or some other mistake) |
| 15:58 |
Bmagic |
tagging the branch rather than branching the tag |
| 15:58 |
Dyrcona |
It would be nice to just type 'make release' and not have to worry about anything else. :) |
| 15:59 |
sandbergja |
100% |
| 15:59 |
Bmagic |
and our PG version-upgrade stuff would auto-figure itself |
| 16:00 |
eeevil |
I just want to register my dislike of "stamp version commit -> cut release -> UNstamp version commit" ... but other than that (if we can avoid it) it's all just a checklist |
| 16:00 |
Dyrcona |
Bmagic: It's mostly automatic now, but there might be a few steps required before running 'make release.' |
| 16:01 |
sandbergja |
eeevil: does your objection still apply to what Dyrcona proposed, with the stamping it "+dev" between releases? |
| 16:01 |
Bmagic |
eeevil: the tag would presumabely remain on the commit right? |
| 16:02 |
eeevil |
sandbergja: I'm less against that, but anything that keeps main (or one of the major version branches) effectively locked gets the side-eye from me |
| 16:03 |
Dyrcona |
eeevil: What do you mean by "effectively locked?" |
| 16:04 |
sandbergja |
oh, like locked to a specific version? |
| 16:05 |
eeevil |
well, today we say "ok, what's in there now is 3.13.0, make a branch for that" -- at which point commits for 3.13.1 can start flowing into th 3.13 branch -- "and fill it with as many release-related commits as are needed" |
| 16:05 |
eeevil |
the only "locking" is the exact branch point, and that's not locked, we can branch from a commit 3 back from the tip |
| 16:06 |
eeevil |
but, if we put all the release related commits into the overall version branch then nobody but the release team can touch that branch until the all-clear is sent out |
| 16:07 |
eeevil |
it's effectively locked because we can't have non-release-related commits going in |
| 16:07 |
Dyrcona |
That's generally how we do it now anyway. |
| 16:08 |
Dyrcona |
Someone almost always send an email: We're working on relases, don't touch branches X, Y, Z. |
| 16:08 |
eeevil |
I know I haven't been RM in quite a while, but ... why do we do that? |
| 16:09 |
Dyrcona |
Because building releases is WAY more time consuming than it used to be and involves 4 to 6 people generally. Even point releases. |
| 16:09 |
sandbergja |
what Dyrcona said |
| 16:09 |
sandbergja |
we may be getting a bit off topic, as well |
| 16:10 |
eeevil |
(I could very well be misremembering, but I recall my process being: 1) release branch 2) version update in there 3) upgrade script in there 4) release notes in there 5) side-port upgrade script and release notes to major version and main) |
| 16:10 |
sandbergja |
If I put together a branch that has some automation of 1) git tags, 2) keeping all commits on the rel_* and main branches, 3) stamping the +dev when we are not in a release, and 4) removes Changelog, would anyone object? |
| 16:11 |
Dyrcona |
eeevil: We get translations from 2 sources, do release notes for bug fixes, backport release notes, etc. |
| 16:12 |
Dyrcona |
more like forward port release notes and db upgrades. |
| 16:12 |
Dyrcona |
sandbergja: I'll look at the branch if you put one together. |
| 16:12 |
sandbergja |
Dyrcona++ |
| 16:12 |
Bmagic |
Dyrcona++ |
| 16:13 |
Bmagic |
sorry to keep yall late |
| 16:13 |
eeevil |
sandbergja: I certainly won't object to a branch to look at! ;) |
| 16:13 |
Bmagic |
#topic Announcements |
| 16:13 |
sandbergja |
Bmagic++ |
| 16:13 |
Bmagic |
#info Next Meeting is Tuesday, May 14th 2024 |
| 16:13 |
Bmagic |
#endmeeting |
| 16:13 |
pinesol |
Meeting ended Tue Apr 9 16:13:22 2024 US/Eastern. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) |
| 16:13 |
pinesol |
Minutes: http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-04-09-15.00.html |
| 16:13 |
pinesol |
Minutes (text): http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-04-09-15.00.txt |
| 16:13 |
pinesol |
Log: http://evergreen-ils.org/meetings/evergreen/2024/evergreen.2024-04-09-15.00.log.html |
| 16:13 |
mmorgan |
sandbergja++ |
| 16:13 |
mmorgan |
Bmagic++ |
| 16:13 |
scottangel |
Bmagic++ |
| 16:13 |
eeevil |
sandbergja: I realize I sound like I'm yelling "get off my lawn" :) |
| 16:13 |
csharp_ |
hey guys, y'all havin' some kind of meeting? |
| 16:14 |
eeevil |
"back in MY day..." |
| 16:14 |
Dyrcona |
eeevil++ |
| 16:14 |
csharp_ |
(sorry, completely dropped that the dev meeting was today) |
| 16:14 |
Dyrcona |
Bmagic++ |
| 16:15 |
Bmagic |
Thank you, thank you. I'd like to thank my computer, who puts up with my abuse all day. |
| 16:15 |
sandbergja |
eeevil: I didn't take it that way, no worries! And it would be great to reduce (maybe eliminate) the need for merge freezes for releases. I think we need to really simplify/automate the release process before we are there, though. |
| 16:15 |
sandbergja |
Bmagics_computer++ |
| 16:18 |
eeevil |
translations are, ISTM, the biggest barrier to treating a release branch as the playground of the release team, because there's a necessary human process of actual translation on en-us string change/addition, and that takes time (string freeze) |
| 16:21 |
eeevil |
are there better practices we could be employing to keep i18n up to date, ideally automatically? like, automated nightly commits of materially changed i18n artifacts? (I really don't know if that's possible with today's tools ... I don't think it would have been (or been safe, at least) before) |
| 16:21 |
Dyrcona |
eeevil: The way I suggested doing it works for a few other projects. One of which keeps the translations in the main git branch. |
| 16:21 |
sandbergja |
Dyrcona has been a good advocate for keeping the translations in the repo. I think that if some developers and some translators put their heads together, we could figure out a really nice process that does that. |
| 16:22 |
sandbergja |
oh, ha! |
| 16:22 |
eeevil |
the main problem being one of getting translators in front of the in-repo string dumps, I guess? |
| 16:23 |
eeevil |
rather than using several external translation platforms an pulling from them at some interval |
| 16:23 |
eeevil |
*and |
| 16:23 |
Dyrcona |
Right. My understanding is the original Lp translation repo exists to leverage the Lp translation tools, and then POEditor was added for Angular. |
| 16:24 |
Dyrcona |
POEditor is a sticking point because only a couple of the devs can actually do anything with it. I can look, for instance, but I'm apparently not allowed to touch. |
| 16:27 |
sandbergja |
eeevil: launchpad is already doing what you are suggesting for non-Angular strings (see the "Launchpad automatic translations update" commits at https://code.launchpad.net/~evergreen-bugs/evergreen/translation-export-3.12), it's just... in the wrong version control system (bzr instead of git) |
| 16:27 |
eeevil |
sandbergja: solution: we switch to bzr! /me ducks |
| 16:27 |
sandbergja |
heh |
| 16:28 |
Dyrcona |
I think we can switch the translation repo to git, but I could be wrong. |
| 16:28 |
sandbergja |
that sure would be nice |
| 16:28 |
sandbergja |
Poeditor also has integrations to do that automatic move-the-translations-into-the-repo for github or gitlab |
| 16:29 |
Dyrcona |
If we wanted, we could probably move from self-hosting our git repos to hosting them on Lp, and then we could have the translations in a subdirectory of the actual repo. |
| 16:30 |
eeevil |
that's been the way of things for long enough that I was using bzr during releases ... the big issue is that it's really only tracking main (or, was). so strings that change after the .0 release become tricky. hard to backport |
| 16:30 |
Dyrcona |
yeah, I think we started doing different translations branches for that reason. |
| 16:31 |
Dyrcona |
We could also have a rule: No bakports of commits with string changes. :) |
| 16:31 |
Dyrcona |
We could always open up the hosting discussion again with various additional pros and cons. |
| 16:36 |
Dyrcona |
berick: You might be happen to know: No buffer overflow with Redis and OpenSRF on Ubuntu 24.04. |
| 16:37 |
Dyrcona |
Spoke too soon. |
| 16:37 |
berick |
Dyrcona: you're saying it's not happening to you? I haven't .. |
| 16:37 |
berick |
haha |
| 16:38 |
Dyrcona |
With ejabberd, the buffer overflow message pops up with osrf_control -l --start-all. |
| 16:38 |
|
kmlussier joined #evergreen |
| 16:38 |
Dyrcona |
With redis, it looks like things start, but then osrf_control -l --diagnostic shows only the Perl services running. The routers are not listed, and the c services all have pid files but are not running. :( |
| 16:39 |
Dyrcona |
24.04 is going to be "fun." |
| 16:39 |
Dyrcona |
Oh, wait. the routers are running.... |
| 16:39 |
Dyrcona |
* router [34204] uptime=01:00 cputime=00:00:00 |
| 16:39 |
Dyrcona |
* router [34205] uptime=01:00 cputime=00:00:00 |
| 16:41 |
Dyrcona |
I'll switch back and check for the routers again. |
| 16:42 |
berick |
Bmagic++ # deprecation notice |
| 16:42 |
Bmagic |
I was formatting the email when I held shift too long, and boom, it sent |
| 16:42 |
Bmagic |
sfhit+enter, enter lol |
| 16:42 |
berick |
we'll do it live! |
| 16:43 |
Bmagic |
sorry, make that ctrl+enter, enter |
| 16:45 |
berick |
Dyrcona: you have a working branch for bug 2054842 ? |
| 16:45 |
pinesol |
Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,New] https://launchpad.net/bugs/2054842 - Assigned to Jason Stephenson (jstephenson) |
| 16:46 |
berick |
or maybe that's what you are doing right now |
| 16:47 |
Dyrcona |
yeah, I'm working on it right now. I got the OpenSRF and its prerequisites installed and I'm trying to get it to run. I think we've got a bug in the C code somewhere. |
| 16:49 |
Dyrcona |
And, I switched back to ejabberd: no routers. |
| 16:49 |
|
collum joined #evergreen |
| 16:49 |
Dyrcona |
I'm going to call it a day, and I'll see if I can find what's causing the buffer overflow tomorrow. |
| 17:00 |
|
mantis left #evergreen |
| 17:00 |
|
mmorgan left #evergreen |
| 17:07 |
|
collum joined #evergreen |
| 17:12 |
JBoyer |
LP 1017990 has an updated branch that doesn't remove the functions entirely but builds on csharp_'s existing branch to not use the functions internally while MAKING LOUD NOISES in the log if they're called at all. |
| 17:12 |
pinesol |
Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990 |
| 17:24 |
|
collum joined #evergreen |
| 18:40 |
|
collum joined #evergreen |
| 18:59 |
|
collum joined #evergreen |
| 19:16 |
|
collum joined #evergreen |
| 20:33 |
|
collum joined #evergreen |
| 20:50 |
|
collum joined #evergreen |
| 21:09 |
|
collum joined #evergreen |
| 21:17 |
|
collum joined #evergreen |
| 21:41 |
|
stephengwills left #evergreen |
| 22:34 |
|
collum joined #evergreen |
| 23:17 |
|
sandbergja joined #evergreen |
| 23:42 |
|
collum joined #evergreen |
| 23:59 |
|
collum joined #evergreen |
