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