15:00:01 <Bmagic> #startmeeting 2024-06-11 - Developer Meeting
15:00:01 <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:01 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:01 <pinesol> The meeting name has been set to '2024_06_11___developer_meeting'
15:00:08 <Bmagic> #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-06-11
15:00:15 <Bmagic> #topic Introductions
15:00:17 <Dyrcona> #info Dyrcona = Jason Stephenson, CW MARS
15:00:19 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:00:27 <terranm> #info terranm = Terran McCanna, PINES
15:00:30 <Bmagic> you can't beat the meeting host Dyrcona!
15:00:32 <redavis> #info redavis = Ruth Davis, ECDI
15:00:34 <sleary> #info sleary = Stephanie Leary, EOLI
15:00:36 <abneiman> #info abneiman = Andrea Buntz Neiman, Equinox
15:00:42 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:00:45 <Bmagic> party foul
15:00:45 <kmlussier> #info kmlussier is Kathy Lussier, NOBLE
15:00:49 <berick> #info berick Bill Erickson, KCLS
15:00:57 <shulabear> :#info shulabear = Shula Link, GCHRL
15:01:03 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:01:09 <LindaJansova> #info LindaJansova is Linda Jansova, Osvobozena knihovna, Czech Republic
15:01:31 <jeff> ]]\\\
15:01:34 <jeff> bah.
15:01:35 <shulabear> #info shulabear = Shula Link, GCHRL
15:01:36 <eeevil> #info eeevil = Mike Rylander, EOLI
15:01:57 <smayo> #info smayo = Steven Mayo, PINES
15:02:16 <Bmagic> #topic Action Items from Last Meeting
15:02:24 <Bmagic> #info gmcharlt - create a Git commit message type and update bug 2051946
15:02:24 <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:52 <Bmagic> absent?
15:03:25 <Bmagic> we'll carry it
15:03:25 <sleary> I believe that's done, though
15:03:34 <Bmagic> oh?
15:03:55 <Bmagic> the bug doesn't have what I would expect
15:03:56 <sleary> or perhaps I'm thinking of the release note one-liners
15:04:06 <abneiman> sleary I think you're thinking of the release notes
15:04:09 <Bmagic> the one-liners is something else
15:04:21 <sleary> ok
15:04:22 <abneiman> 2051946 is a follow up & I do not think it's done
15:04:33 <Bmagic> #action gmcharlt - create a Git commit message type and update bug 2051946
15:04:33 <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:37 <Bmagic> #info mmorgan will explore moving LP stats to community site and automating same
15:04:48 <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:57 <Bmagic> suuuweet!
15:05:00 <sleary> mmorgan++
15:05:01 <Bmagic> mmorgan++
15:05:09 <redavis> mmorgan++
15:05:10 <Dyrcona> mmorgan++
15:05:12 <Bmagic> #action mmorgan will explore moving LP stats to community site and automating same
15:05:16 <kmlussier> mmorgan++
15:05:23 <Bmagic> #info Dyrcona will take a look at bug 1017990 for merging into main and 3.13
15:05:23 <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:25 <abneiman> mmorgan: is the Launchpad API better behaved these days?
15:05:35 <abneiman> IIRC it was very finicky & crashed a lot
15:05:59 <mmorgan> abneiman: It's answered properly when I've asked it the right questions so far :)
15:06:06 <abneiman> mmorgan++
15:06:31 <Dyrcona> My experience is that there were limits on how many things you could do before it would start acting up.
15:07:01 <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:01 <pinesol> Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed]
15:07:05 <Bmagic> well, 3.13 is released, and this bug didn't make it
15:07:06 <csharp_> #info csharp_ is Chris Sharp, GPLS
15:07:39 <Dyrcona> Ugh. wrong comment: https://bugs.launchpad.net/evergreen/+bug/1017990/comments/21
15:08:29 <Dyrcona> I'll take another look at Chris's branch. I'm not sure what I looked at last time.
15:08:40 <Bmagic> alright, no problem. Carrying it
15:08:41 <Dyrcona> Too much going on lately.
15:08:59 <Bmagic> #action Dyrcona will take a look at bug 1017990
15:08:59 <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:13 <Bmagic> #info eeevil will open a bug for cross-column stats targets
15:09:21 <csharp_> Dyrcona: thanks
15:10:34 <Bmagic> I'm assuming eeevil is typing
15:11:18 <eeevil> I haven't even thought about that ... been a long month!
15:11:30 <eeevil> so, push it forward, please
15:11:36 <Bmagic> same for me! Carry!
15:11:44 <Bmagic> #action eeevil will open a bug for cross-column stats targets
15:11:51 <Bmagic> same for this probably
15:11:53 <Bmagic> #info eeevil will see about merging bug 2042158
15:11:53 <pinesol> Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [High,Fix released] https://launchpad.net/bugs/2042158
15:12:03 <Bmagic> oh! nope, that one was touched
15:12:14 <Bmagic> close the books on that
15:12:19 <eeevil> I saw about that :)
15:12:21 <Bmagic> eeevil++
15:12:37 <eeevil> Bmagic++
15:12:44 * csharp_ can't quite grab the "just in time" joke that's floating out there
15:12:56 <Bmagic> csharp_++
15:13:08 <Bmagic> kmlussier's turn
15:13:09 <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:23 <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:38 <Bmagic> no rush, we don't have another one of these for 30 days!
15:13:50 <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:56 <kmlussier> I'll forget again if I don't do it right away. :)
15:14:00 <Bmagic> :)
15:14:12 <Bmagic> that does it for action items from last month
15:14:36 <Bmagic> #topic Evergreen
15:14:44 <Bmagic> #info 3.13.0 is released
15:15:02 <Bmagic> boomshakalaka
15:15:16 <jeff> heartfelt thanks to all, especially the release team!
15:15:19 <smayo> release_team++
15:15:24 <redavis> release_team++
15:15:25 <terranm> release_team++
15:15:33 <kmlussier> release_team++
15:15:35 <LindaJansova> release_team++
15:15:42 <Bmagic> the release team is drunk on a beach somewhere
15:15:56 <abneiman> ...wait how did I miss THAT memo
15:15:58 <redavis> lol, or in this meeting. frightfully sober
15:16:02 <shulabear> the release team wishes
15:16:05 <mmorgan> release_team++
15:16:09 <Bmagic> IRC works on phones these days
15:16:21 <sleary> beach, Launchpad... no, not the same at all
15:16:24 <redavis> @coffee release_team
15:16:24 * pinesol brews and pours a cup of Ethiopia Yirgacheffe Beloya Selection 8, and sends it sliding down the bar to release_team
15:16:36 <abneiman> @liquor release_team
15:16:36 <pinesol> abneiman: is your coffee overgranularized?
15:16:39 <abneiman> dang
15:16:47 <sleary> lol
15:16:48 <redavis> lol!!!
15:16:55 <kmlussier> @bartender release_team
15:16:55 * 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:06 <abneiman> kmlussier++
15:17:10 <Bmagic> kmlussier++
15:17:12 <shulabear> kmlussier++
15:17:29 <Bmagic> #topic Launchpad Status (as of noon Eastern)
15:17:35 <Bmagic> incoming
15:17:36 <Bmagic> #info Open Bugs - 3050
15:17:36 <Bmagic> #info Pullrequests - 82
15:17:36 <Bmagic> #info Signedoff - 11
15:17:42 <Bmagic> #topic Launchpad Status since last meeting
15:17:47 <Bmagic> #info Bugs Added - 43
15:17:47 <Bmagic> #info Pullrequest tag Added - 12
15:17:47 <Bmagic> #info Signedoff tag Added - 11
15:17:47 <Bmagic> #info Fix Committed - 21
15:17:57 <Bmagic> #topic New Business - translation infrastructure: eliminate Launchpad in favor of POEditor - Stephanie/3.13 team
15:19:03 <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:15 <sleary> I think this is related to the API flakiness.
15:19:18 <Bmagic> anyone interested in forming an investigation?
15:19:55 <Bmagic> (into seeing how POEditor workflow plays out for both POT and Angular translations)
15:20:41 <terranm> I cannot volunteer right now, but +1 to only having one place to manage translations
15:20:51 <Bmagic> One thing that might be: POEditor doesn't poll our repo
15:21:21 <Bmagic> LP does automatically sync our strings into it's mechanism via our git repo
15:21:25 <LindaJansova> I agree, it would certainly be better to have one place to work on the translations :-).
15:21:43 <Dyrcona> Well, when it works. Looks like we went a few months without any updates.
15:21:43 <Bmagic> I don't think* POEditor does that
15:21:52 <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:05 <Bmagic> sleary++
15:22:15 <Bmagic> look at you bringing up the documentation
15:22:29 <Dyrcona> I think it would be better for translators and release teams if there is only 1 place for translations.
15:22:45 <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:50 <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:19 <Bmagic> one website to rule them all does sound attractive
15:23:25 <sleary> the translation-related steps are a huge hurdle for release teams right now.
15:23:33 <sleary> and no one understands the Launchpad processes very well.
15:23:43 <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:55 <LindaJansova> One place would also help when we try to do some troubleshooting (nowadays it is rather complicated).
15:23:55 <Bmagic> how do we move forward with this migration?
15:24:20 <sleary> I think the investigation's goal will be to answer that question
15:24:22 <redavis> It seems like the only real reticence is having an actual plan to get from LP to POEditor.
15:24:50 <Bmagic> We need a team to dive in and click all the buttons? Who's on the team. We have one! kmlussier.
15:25:13 <kmlussier> Huh? I don't think you want me on that team.
15:25:16 <redavis> I mean...redavis^
15:25:23 <abneiman> I'm with you redavis
15:25:35 <Bmagic> redavis, sorry, yes, redavis
15:25:42 <redavis> abneiman++
15:25:52 <sleary> I am interested but abneiman will murder me in my sleep if I volunteer for anything else this month
15:25:54 <kmlussier> redavis++ abneiman++
15:25:59 <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:03 <Bmagic> "these two hands" </rockbitter>
15:26:09 <sleary> heh
15:26:10 <abneiman> omg sleary lol
15:26:15 <Dyrcona> I can see what I can do. I've had trouble using POEditor, but I think someone supposedly fixed that.
15:26:15 <abneiman> but also, yeah, no
15:26:16 <redavis> lol!!!
15:26:19 <kmlussier> abneiman doesn't seem like the murderous type.
15:26:30 <mmorgan> sleary: That would be counterproductive.
15:26:39 <abneiman> thanks for the vote of confidence kmlussier, lmao
15:26:41 <redavis> Dyrcona, wanna give it a go?
15:26:43 <Bmagic> LindaJansova: interested in looking at it?
15:26:45 <csharp_> @who is the murderous type?
15:26:45 <pinesol> Bmagic is the murderous type.
15:26:52 <csharp_> pinesol++
15:26:55 <Dyrcona> Bmagic is the Spy!
15:27:05 <Bmagic> haha, I deserve that pinesol
15:27:06 * redavis already knew that
15:27:09 <Dyrcona> I'll take a look for sure.
15:27:45 <Bmagic> ok, redavis and Dyrcona are officially a POEditor team?
15:27:53 <abneiman> and me
15:27:59 <Bmagic> !!
15:28:08 <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:09 <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:25 <LindaJansova> Apologies, I appear to be a slower typer ;-).
15:28:27 <redavis> LindaJansova++
15:28:30 <Bmagic> LindaJansova++
15:28:32 <redavis> lol, no worries.
15:28:39 <kmlussier> LindaJansova++
15:28:41 <Dyrcona> LindaJansova++
15:28:42 <abneiman> it's ok LindaJansova - we're trying to fix the processes behind the scenes anyway! and we appreciate your input!
15:28:50 <LindaJansova> :-)
15:29:04 <shulabear75> LindaJansova++
15:29:13 <redavis> LindaJansova and EvaCe, how about we include you in emails and updates, but with no obligation on your part?
15:29:32 <LindaJansova> Sounds great :-)!
15:29:38 <Bmagic> #action redavis, Dyrcona, abneiman, LindaJansova, EvaCe will investigate and see what it will take to move our translations to POEditor
15:29:53 <mmorgan> redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++
15:30:01 <Bmagic> redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++
15:30:10 <sleary> redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++
15:30:33 <csharp_> redavis++ abneiman++ Dyrcona++ LindaJansova++ EvaCe++, oh my!
15:30:38 <Bmagic> that's probably the best outcome for this topic
15:30:49 <Bmagic> we'll be excited to hear from yall next month
15:31:12 <Bmagic> #topic New Business - LP#2060734: changes to the release process
15:31:40 <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:51 <Bmagic> I see
15:32:12 <Bmagic> #topic New Business - Outstanding roadblocks to merging OpenSRF Redis?
15:32:27 <berick> pretty much what it says.  What else needs doing before we can merge to OpenSRF main?
15:32:52 <Bmagic> is it converted to redis's replacement?
15:33:01 <berick> no that will take time
15:33:21 <Dyrcona> Which replacement did we decide on?
15:33:28 <Bmagic> My understanding was that we can't adopt it officially because redis's rules?
15:33:40 <Bmagic> valkey?
15:33:43 <berick> Bmagic: not exactly
15:33:44 <csharp_> Dyrcona: ValKey
15:33:50 <berick> the packages availabe now are perfectly fine to use
15:33:51 <Dyrcona> I think we can adopt the versions that are packaged in current distros, can't we?
15:33:55 <csharp_> yes
15:33:59 <Dyrcona> berick++
15:34:13 <berick> and we have a replacement plan, just have to wait for that stuff to settle down
15:34:26 <berick> which won't affect the code, just the docs/installers
15:34:32 <Bmagic> ok, so we can* keep using redis, via the git branch's auto-installer?
15:34:33 <Dyrcona> I haven't seen package for ValKey, yet.
15:34:39 <csharp_> Bmagic: yep
15:35:18 <Bmagic> hmmm, so the question is: do we merge it before ValKey is "out" ?
15:35:45 <Bmagic> with the understanding that we will have a follow-up LP to update the bits for ValKey when that's possible
15:35:45 <berick> the bigger qestion for me is whether the functionality is complete for the various use cases
15:36:23 <berick> which is to some extent aimed at the Equinox folks
15:36:25 <Dyrcona> I've been using it since October on a test instance and haven't noticed anything that doesn't work.
15:36:42 <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:04 <berick> Bmagic: i'm deploying it as soon as it's merged to opensrf main
15:37:13 <berick> (part of why i'm asking now, want to get going on it)
15:37:29 <Bmagic> merging it doesn't make it required: just making sure that's clear
15:37:35 <csharp_> not that it helps us with debian(-ish) things, but Fedora already has valkey in the repos
15:37:44 <berick> csharp_: oh neat
15:37:56 <Bmagic> Fedora is a speeding bullet that no one will catch
15:38:08 <csharp_> as well as valkey-compat-redis.x86_64 : Conversion script and compatibility symlinks for Redis
15:38:27 <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:27 <pinesol> jeff: Error: Could not parse data returned by Debian:
15:38:36 <jeff> none of that prevents use or merging.
15:38:55 <Bmagic> merging it is pretty much fine right? Like people can ignore it and keep using ejabberd?
15:39:07 <csharp_> jeff: we'll probably need to use a PPA if it becomes a thing
15:39:13 <jeff> possibly eeevil or gmcharlt or JBoyer have input/thoughts/feedback but may be unavailable to comment.
15:39:27 <jeff> (I think that's who berick was asking, for the most part)
15:39:35 <berick> Bmagic: not exactly, you'd have to use an already-released version of opensrf to use ejabberd
15:39:43 <Bmagic> i see
15:39:50 <berick> once on main, it's only redis, no side-by-side
15:40:13 <csharp_> I think it's fine to say OpenSRF < 4.0 (or whatever) is ejabber-friendly
15:40:25 <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:32 <csharp_> don't upgrade if you want to stay on ejabberd
15:40:45 <csharp_> @who wants to stay on ejabberd?
15:40:45 <pinesol> eby wants to stay on ejabberd.
15:40:50 <Dyrcona> Bmagic: Evergreen already installs the Redis packages.
15:41:13 <berick> right it only affects opensrf
15:41:27 <Dyrcona> I think we should maybe get Ubuntu 24.04 installation support first. https://bugs.launchpad.net/evergreen/+bug/2054842
15:41:27 <pinesol> Launchpad bug 2054842 in OpenSRF "Add Installation on Ubuntu 24.04" [Wishlist,In progress] - Assigned to Jason Stephenson (jstephenson)
15:41:33 <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:55 <Dyrcona> Redis is more like tennis elbow... :)
15:41:59 <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:03 <csharp_> I used to not care, but the pain over the last few versions/ubuntu releases has been signficant
15:42:20 <csharp_> jeff: that was my understanding too
15:42:41 <Dyrcona> csharp_: Ubuntu 24.04 just works with ejabberd this time. We got lucky. :)
15:43:06 <kmlussier> Dyrcona: I have tennis elbow. It's quite painful.
15:43:07 <csharp_> the thin ice we're skating on held!  (this is fine dog)
15:43:18 * kmlussier is hoping reddis isn't quite so painful.
15:43:27 <Dyrcona> jeff csharp_: Yeah, that was my suggestion about the numbering.
15:43:38 <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:06 <Dyrcona> kmlussier: I'm sorry, didn't mean to make light of it. All software is some kind of pain to use.
15:44:39 <Dyrcona> berick has done a great job making the Redis integration just work. Very little configuration required.
15:44:48 <Bmagic> agreed berick++
15:44:54 <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:01 <Bmagic> I don't know where all of this leaves us
15:45:03 <Dyrcona> So, are we at an impasse then?
15:45:19 <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:25 <berick> exactly, chicken and egg
15:45:28 <Bmagic> I will get it installed on a larger production environment and report back. Will that work for now?
15:45:37 <redavis> Bmagic++
15:45:38 <shulabear75> csharp++ berick++
15:45:41 <csharp_> or a game of chicken, or something about chickens
15:45:43 <redavis> GuineaPigs++
15:45:53 <shulabear75> csharp_++
15:45:54 <Dyrcona> Bmagic++
15:45:55 <csharp_> kaw ke kaw!
15:46:09 <Bmagic> alright, next
15:46:10 <Bmagic> #topic New Business - Backport guidelines? What should be backported? - Stephanie/code review team
15:46:32 <sleary> ah, this came up last week.
15:46:41 <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:44 <abneiman> this is a good question to revisit
15:47:06 <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:08 <sleary> changes.
15:47:41 <sleary> database updates, also, but strings are more common in potentially backportable things
15:47: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:18 <redavis> Dyrcona++
15:48:50 <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:17 <Dyrcona> We are updating strings for point releases, now, but we could stop if we say no string changes.
15:50:08 <abneiman> I agree with Dyrcona re backporting schema changes, unless it's critical. I can go either way about string changes.
15:50:09 <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:18 <mmorgan> If translations were more manageable, maybe it would make sense not to restrict backporting string changes.
15:50:42 <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:00 <redavis> agreed with mmorgan and abneiman
15:51:09 <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:23 <redavis> LindaJansova++
15:51:26 <redavis> Noted
15:51:31 <sleary> LindaJansova++
15:51:49 <EvaCe> LindaJansova++
15:51:50 <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:04 <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:25 <abneiman> which I think is currently 3rd Wednesdays (for point releases)
15:52:50 <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:04 <sleary> we could plan those a little better and put things on the community calendar if we need to
15:53:12 <redavis> sleary++
15:53:25 <mmorgan> sleary++
15:53:53 <Bmagic> not sure I'm seeing an action item
15:53:55 <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:17 <LindaJansova> sleary++
15:54:23 <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:13 <redavis> LindaJansova, I think we can better utilize the community calendar to include release activities including string freezes.
15:56:08 <Bmagic> redavis: would you like that action? Editing the calendar along these lines?
15:56:57 <redavis> Bmagic, yes...but I am not exactly sure when that will happen since there's some cat herding to happen prior...
15:57:34 <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:41 <eeevil> Dyrcona: every release is a major release?
15:57:43 <Dyrcona> redavis: I think for 3.14 we can discuss a schedule with time set aside for translation work.
15:58:04 <redavis> Dyrcona++ email to you and the rest of the team headed out tomorrow.
15:58:24 <Bmagic> #action redavis will look at making a regular calendar event for translation work in lock step with point releases
15:58:29 <kmlussier> If we have a clearer idea of what the release schedule should be, it would help with scheduling the translations.
15:58:44 <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:59 <Bmagic> we're coming up to our hour
15:58:59 <Dyrcona> I honestly don't think we have the human resources to do monthly point releases.
15:59:10 <kmlussier> A conversation for another day? :)
15:59:18 <Dyrcona> I won't be there.
15:59:25 <redavis> kmlussier, I think we're talking about that on Thursday.
15:59:26 <eeevil> I agree with the resource vs monthlies point, fwiw
15:59:47 <Bmagic> Next month's regular meeting would be July 9th, I'm not going to be able to make that
15:59:53 <mmorgan> If we can better streamline the release process, it would take fewer resources.
16:00:07 <kmlussier> redavis: Yes, Thursday at 12 p.m. Eastern.
16:00:11 <abneiman> yes, I strongly encourage everyone who's interested in the release conversations to attend the discussion kmlussier is hosting this Thursday!
16:00:19 <kmlussier> Sorry Dyrcona. I went by what was in the Doodle poll.
16:00:20 <eeevil> but, all software has bugs, so I'm not sure I'm on board with every-release-is-an-island
16:00:38 <redavis> kmlussier++ abneiman++
16:00:50 <Dyrcona> eeevil: I'm not saying that either exactly.
16:01:02 <Bmagic> anyone want to take this July 9th meeting?
16:01:10 * redavis hums "features in the stream...that is what we are."
16:01:54 <Bmagic> #topic Announcements
16:02:02 <abneiman> Bmagic: I can lead the 7/9 meeting
16:02:05 <eeevil> redavis: great, now /that'll/ be in my head for 2 hours... :P
16:02:06 <kmlussier> Bmagic: If nobody else volunteers, I can take it. But I'll be running back from a dental appointment.
16:02:06 <Bmagic> #info Next Meeting is Tuesday, July 9th 2024
16:02:07 <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:14 <kmlussier> Never mind. abneiman beat me to it.
16:02:25 <redavis> eeevil, success is my only aim...muahahahahah
16:02:40 <Bmagic> abneiman++ # it's yours! I'll do the wiki dance after this one, you get July 9th's privilege
16:02:51 <abneiman> ta
16:02:56 <redavis> terranm, I was going to email you about that too!
16:03:22 <kmlussier> August 26 to be exact.
16:03:28 <eeevil> redavis: "no release between, how can it be wrong"
16:03:40 <terranm> We could do August 26-30
16:03:45 <redavis> eeevil++++++++++++++++++++
16:03:55 <Bmagic> terranm: looks good for me
16:04:13 <redavis> terranm, perfect
16:04:13 <sleary> terranm++
16:04:14 <terranm> Maybe we'll have the new circ/patron interfaces to test then?
16:04:22 <LindaJansova> terranm++
16:04:25 <redavis> terranm++
16:04:29 <Bmagic> terranm++
16:04:33 <mmorgan> terranm++
16:04:43 <terranm> Thanks, I'll put it on the calendar and all that
16:04:44 <Bmagic> thanks everyone! Good turn out this month
16:04:45 <kmlussier> I have questions about the new circ/patron interfaces, but I'll send it in an email.
16:04:47 <Bmagic> #endmeeting