15:00:24 <Dyrcona> #startmeeting 2023-12-12 - Developer Meeting
15:00:24 <pinesol> Meeting started Tue Dec 12 15:00:24 2023 US/Eastern.  The chair is Dyrcona. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:24 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:24 <pinesol> The meeting name has been set to '2023_12_12___developer_meeting'
15:00:43 <Dyrcona> #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2023-12-12
15:00:52 <Dyrcona> #topic Introductions
15:01:03 <Dyrcona> #info Dyrcona = Jason Stephenson, CW MARS.
15:01:14 <Dyrcona> Feel free to introduce yourself as you join.
15:01:16 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:01:20 <dluch> #info dluch = Debbie Luchenbill, MOBIUS (and DIG)
15:01:27 <JBoyer> #info JBoyer = Jason Boyer, EOLI
15:01:28 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:01:30 <sandbergja> #info sandbergja = Jane Sandberg, PUL and independent
15:01:34 <briank> #info briank = Brian Kennedy, Sitka
15:01:35 <collum> #info collum = Garry Collum (KCPL)
15:01:44 <sleary> #info sleary = Stephanie Leary, EOLI
15:01:50 <abneiman> #info abneiman = Andrea Buntz Neiman, EOLI
15:02:09 <shulabear> #info shulabear = Shula Link, GCHRL in GPLS
15:02:56 <Dyrcona> OK.
15:02:59 <Dyrcona> #topic Action Items from Last Meeting
15:03:27 <Dyrcona> #info jeff will make tutorial: "Add missing field to print template"
15:03:27 <Dyrcona> #info jeff will write tutorial "Retrieve a user's setting and do something based on its value"
15:03:27 <Dyrcona> #action jeff will write tutorial "Retrieve a user's setting and do something based on its value"
15:03:53 <Dyrcona> Oops. How did that action get in there?
15:04:02 <jeff> dunno!
15:04:08 <Dyrcona> I think the lines doubled up when I copy/pasted to my cheat sheet.
15:04:35 <Dyrcona> #info sandbergja will write tutorial: "Do a database call (Galen’s cat counter)"
15:04:42 <scottangel> #info scottangel = Scott Angel, MOBIUS
15:04:56 <Dyrcona> #info jeff is not taking that action this meeting, and we'll see about striking it in the minutes.
15:05:06 <sandbergja> no progress from me
15:05:17 <jeff> I support your previously-mentioned idea of striking the three tutorials from the action items: several tutorials were made, there's room for more, but they don't seem to be of a priority that needs to be reviewed at this level.
15:05:36 <Dyrcona> I put the tutorial actions together because I think that 1) they have not been done, and 2) we don't need to carry them forward to future meetings.
15:05:36 <berick> #info berick Bill Erickson, KCLS
15:06:16 <sandbergja> mine is just missing some examples.  I can add more examples eventually, but also don't let me keep others from adding examples (it is a wiki after all)
15:06:16 <eeevil> #info eeevil Mike Rylander, EOLI
15:06:24 <Dyrcona> If they do get done, I think they can be shared via the development and/or newdevs lists.
15:06:46 <jeff> sounds good. thanks!
15:07:43 <Dyrcona> Is anyone opposed? We could put it to a vote.
15:08:37 <sleary> I would be fine with reevaluating the tutorial wish list and pestering people about it after the holidays
15:09:08 <Dyrcona> sleary++
15:09:43 <Dyrcona> Moving on, I won't action that one, but we'll get to the other two action items.
15:10:00 <Dyrcona> #info mmorgan will explore moving LP stats to community site and automating same
15:10:10 <Dyrcona> mmorgan: Any updates?
15:10:13 <mmorgan> No updates this month due to release business, but I'm fine with keeping it as an action item.
15:10:38 <Dyrcona> #action mmorgan will explore moving LP stats to community site and automating same
15:10:47 <Dyrcona> OK. Carrying it forward.
15:11:00 <Dyrcona> #info sandbergja will investigate getting more tests into gh actions
15:11:22 <sandbergja> bug 2044141 adds the OPAC js tests to run in github actions
15:11:22 <pinesol> Launchpad bug 2044141 in Evergreen "Run OPAC javascript unit tests in github actions" [Undecided,New] https://launchpad.net/bugs/2044141
15:11:35 <Dyrcona> Awesome sauce.
15:11:42 <sandbergja> I'm interested in seeing if gh actions can run the pgtap tests next
15:12:05 <Dyrcona> #info  bug 2044141 adds the OPAC js tests to run in github actions
15:12:16 <sandbergja> I'm okay keeping this item assigned to me
15:12:26 <Dyrcona> I was just about to ask.
15:12:50 <Dyrcona> #action sandbergja will see if gh actions can run the pgtap tests
15:13:29 <Dyrcona> Ok. Unless anyone has anything else to say about previous action items, I'll move on to
15:13:41 <Dyrcona> #topic OpenSRF Releases
15:13:41 <Dyrcona> #info OpenSRF 3.2.4 and 3.3.0-beta released 2023-12-05
15:14:01 <Dyrcona> I would post a link to the email, but I think that got trickier recently.
15:14:48 <JBoyer> I'm planning to take a look at the beta for some testing soon
15:15:32 <Dyrcona> I've been using the main branch on most of my test systems so far, so I guess I'm using the beta now... I'll check and make sure.
15:16:13 <Dyrcona> i added to the next topic before the meeting, so if you haven't yet, you might want to reload the agenda in your browser.
15:16:27 <Dyrcona> #topic Evergreen Releases
15:16:27 <Dyrcona> #info Evergreen 3.12 release candidate available 2023-12-06
15:16:49 <Dyrcona> Do we have an ETA on the final release?
15:17:07 <abneiman> Toooooomorrow, tomorrow, it's 3.12.0, tomorrow
15:17:12 <jeffdavis> Big thanks to the folks who got the fixes for bug 1999823 into the various RCs - much appreciated!
15:17:12 <pinesol> Launchpad bug 1999823 in OpenSRF 3.3 "Name collision causes apache gateway modules to fail when mod_shib is installed" [Medium,Fix released] https://launchpad.net/bugs/1999823
15:17:15 <abneiman> ahem that is to say
15:17:28 <abneiman> #info 3.12.0 build & release planned for 12/13/2023
15:17:30 <Dyrcona> release-team++
15:17:38 <Dyrcona> abneiman++
15:18:02 <dluch> abneiman++ (and now that will be stuck in my head)
15:18:05 <abneiman> sandbergja++ # actually doing the builds
15:18:10 <dluch> release-team++
15:18:25 <abneiman> gmcharlt++ # guidance and advice
15:18:26 <Dyrcona> sandbergja++
15:19:08 <Dyrcona> I'd like to move the next Evergreen topic to new business, since it also appears there in the agenda with a link to kmlussier's email.
15:19:11 <abneiman> collum++ sleary++ redavis++ mmorgan++ terranm++ smayo++ # rest o' the team
15:19:17 <JBoyer> works for me
15:19:37 <Dyrcona> collum++ sleary++ redavis++ mmorgan++ terranm++ smayo++ gmcharlt++
15:19:56 <Dyrcona> Do we have anything for Hatch? It's usually no, but thought I'd ask before skipping it.
15:21:12 <Dyrcona> Ok, moving on...
15:21:19 <Dyrcona> #topic Documentation
15:21:19 <Dyrcona> #info Lots of new documentation has been merged into main!
15:21:19 <Dyrcona> #info Problem with Antora docs build has been identified and fixed (thanks BMagic!)
15:21:19 <Dyrcona> #info A PINES library employee, who is also a technical writing grad student, will be tackling a Docs project at the beginning of 2024! DIG is very excited!
15:21:20 <JBoyer> Only that berick and I are looking into the whole Chrome Manifest V3 thing and so far it looks like no big deal (though it will take a rebuild to actually use it)
15:21:21 <jeff> Manifest 2 is going away, and we can probably get ahead of the game, but I haven't personally looked into how involved it will be.
15:21:21 <dluch> The Documentation stuff is pretty much just informational, unless anyone has questions. Or unless abneiman wants to add anything.
15:21:55 <abneiman> nothing from me other than Bmagic++ #fixing docs build
15:22:10 <Dyrcona> OK. I should have waited longer....
15:22:14 <dluch> Bmagic++
15:22:34 <dluch> And abneiman++ for all the committing!
15:22:38 <Dyrcona> I'll throw a quick Hatch topic and info in her for the minutes.
15:22:43 <Dyrcona> #topic Hatch
15:23:13 <Dyrcona> #info JBoyer and berick are looking into changes required for Chrome Manifest V3, since V2 is going away.
15:24:05 <Dyrcona> Ok, another text dump. Hope I don't get throttled/kicked.
15:24:18 <Dyrcona> #topic Launchpad Status (as of noon Eastern)
15:24:18 <Dyrcona> #info Snaphot
15:24:18 <Dyrcona> #info Open Bugs - 3069
15:24:18 <Dyrcona> #info Pullrequests - 87
15:24:18 <Dyrcona> #info Signedoff - 3
15:24:18 <Dyrcona> #info Updates Since Last Meeting
15:24:18 <Dyrcona> #info Bugs Added - 75
15:24:19 <Dyrcona> #info Pullrequest tag Added - 36
15:24:19 <Dyrcona> #info Signedoff tag Added - 23
15:24:20 <Dyrcona> #info Fix Committed - 34
15:24:42 <Dyrcona> That's the Launchpad bug status. I didn't double check it, so I assume it is accurate-ish.
15:25:26 <Dyrcona> If anyone feels rushed, let me know, and I'll slow down, but I think we might have a lot of discussion on the new business.
15:27:45 <Dyrcona> #topic New Business
15:27:59 <Dyrcona> #topic Point Release Schedule -> http://list.evergreen-ils.org/pipermail/evergreen-dev/2023-December/000696.html
15:28:08 <Dyrcona> And, go! :)
15:29:06 <Bmagic> #info Bmagic=Blake GH, MOBIUS
15:29:22 <Dyrcona> Bmagic++
15:29:29 <Bmagic> :)
15:30:41 <JBoyer> I'm pretty sure that no one is going to argue against any of kmlussier's points or requests. The only issues are making it actually happen.
15:30:50 <abneiman> yes, what @JBoyer said
15:31:05 <JBoyer> Which is really what my point was about, so there's really just the 1 New Business entry.
15:31:29 <sleary> agreed
15:31:32 <dluch> Agreed
15:31:44 <Bmagic> Makin' it happen
15:31:56 <Dyrcona> I kind of wonder about the schedule and if we have enough folks to make it happen.
15:32:11 <JBoyer> Because of some local scheduling I can't do anything on the third Wednesday of the month, and no one else seems to be tapping on the calendar.
15:32:51 <JBoyer> I also like the thought of bimonthly or quarterly releases, I'm not sure we have the momentum to warrant monthlies anymore.
15:33:13 <jeff> Do we want a 3.10 point release, and do we want to try quarterly point releases as a way of easing back into regregular releases?
15:33:20 <Dyrcona> TBH, dbwells used to tap on the calendar and kept us mostly on time. I wonder if there are hurdles we could remove from point releases that might help, like dropping release notes (it was my idea to add them to point releases, I know.)
15:33:22 <sandbergja> To me, doing releases *very* frequently, at least for a while, would provide a lot of benefits.  More opportunity for knowledge sharing, more incremental releases == less to troubleshoot in the upgrade script, and less chance for the process to get forgotten or rusty.  Also, if we run into the annoying parts of the process frequently enough, it will motivate us to fix them.
15:33:29 <sandbergja> But, again that wouldn't help with the capacity issue
15:34:11 <shulabear> sandbergja++
15:34:11 <JBoyer> we should put out one more 3.10.X release because in the past that's been done as a final send-off for the outgoing release (usually at the same time the new one is being built)
15:34:28 <mmorgan> sandbergja++
15:34:31 <jeff> sandbergja: it doesn't address capacity, but it's a good point that more frequent may actually have hidden advantages over infrequent.
15:34:37 <Dyrcona> Well, related to the db upgrade and removing hurdles. I have been thinking about whether we should or should not add schema changes to point releases.
15:34:44 <Bmagic> I "tapped" the calendar once, but we ultimately didn't build that day for lack of notes and I think translations
15:35:36 <Dyrcona> Translations are another minor issue. I wonder if they need to be included in releases, or if there is some way that we could enable them to be added at installation time?
15:36:10 * Dyrcona stops throwing crazy ideas out there to let things settle a minute.
15:37:17 <sandbergja> As an aside: I think the translations part of the release process is a bit odd: like, we upload the translations to lp and poeditor for the translators to translate them, and then a few minutes later, we download them again, as if anybody has had the chance to translate anything in the meantime. :-D
15:38:01 <Dyrcona> yeah. i think the assumption is that things will get translated eventually.
15:39:03 <Dyrcona> The only other project where I deal with translations is Battle for Wesnoth, and it is probably not a good comparison. They keep the translations in the main git repository.
15:39:07 <jeff> on the mention of dropping release notes to make point releases easier, I just wanted to point out that release notes was specifically mentioned as one of the advantages / arguments for point releases. :-)
15:39:25 <dluch> Question from the peanut gallery: What does tapping the calendar mean?
15:39:34 <sandbergja> jeff++
15:39:42 <sandbergja> dluch++ # i was wondering that too
15:39:46 <JBoyer> It means that I am bad at metaphor. :)
15:39:53 <dluch> jeff++
15:39:55 <abneiman> corollary question from the peanut gallery: Does calendar tapping happen anywhere other than IRC? Like, the listservs?
15:40:02 <mmorgan> If release note entries were consistently included with fixes, it would be less onerous to compile them at release time.
15:40:11 <JBoyer> I'm thinking tapping a calendar on the wall while saying "Hey! Date XYZ is coming up, who's doing what?"
15:40:11 <abneiman> agreed mmorgan
15:40:14 <Dyrcona> "Tapping the calendar" means someone reminding us it is time to do releases.
15:40:31 <sandbergja> JBoyer++
15:40:36 <dluch> thank you
15:40:59 <Dyrcona> So, I think requiring releases notes with every patch is too crazy of a requirement.
15:41:00 <abneiman> because, I can almost always help with / do release notes, but I'm honestly rarely in IRC unless it's a meeting
15:41:07 <JBoyer> abneiman, it certainly should. I think "who's doing what" emails went out for the last point release build
15:41:20 <Dyrcona> Wait! That came out wrong. I don't think it is too crazy.
15:41:50 <mmorgan> Dyrcona++
15:42:17 <Dyrcona> What used to happen, is sometimes there would be emails, but very often the discussion of who is doing what would happen in the #evergreen-release channel. That's what it was created for.
15:43:13 <Dyrcona> There is also this Google sheet (still owned by dbwells): https://docs.google.com/spreadsheets/d/1gZayHfF7qK0zwLMEAXt-PbKBMiAM_F6EZguqzIYceBY/edit#gid=0
15:43:24 <JBoyer> It's also intended for helping each other figure things out day-of
15:44:09 <mmorgan> #evergreen-release was never publicized. And it isn't logged so the info isn't available to anyone not in the channel.
15:44:24 <Dyrcona> The reason for the release channel was also to keep the chatter in here down because some may not really be interested in the details of the release.
15:44:46 <abneiman> does the activity level in either channel justify having two channels?
15:44:52 <JBoyer> The fact that multiple days can now go by here without a message means that particular issue may not matter
15:45:21 <dluch> Yeah, and I'm thinking that there might be a way for some of us who are good at wrangling and organizing but not doing the actual technical work could help, maybe. And we're not on the other channel, as far as i know
15:45:24 <Dyrcona> We had that discussion recently, and I think the consensus was that we don't need the release channel.
15:45:29 <abneiman> Can we maybe have one channel, and a calendar-tapper who posts to at least general & dev?
15:45:41 <sleary> +1
15:45:48 <dluch> abneiman++
15:45:52 <dluch> +1
15:46:04 <mmorgan> release chatter could educate and get folks interested in the release process.
15:46:07 <jeff> My impression was that it was more to keep the release stuff focused on release things, especially over multiple days. The exact opposite of what reason many have cited about its purpose. That said, I wasn't involved or present at its creation, so I could be way wrong.
15:46:22 <abneiman> (or at least who says "hey listservs, release discussion in IRC at DATETIME so those of us who don't hang in IRC can make it a point to show up)
15:46:35 <jeff> (this is not to argue for or against another channel, just trying to add context) :-)
15:46:45 <Dyrcona> jeff makes a valid point. We have had multiple day long releases in the past, particularly with security patches.
15:46:52 <mmorgan> Google is good at sending reminders for calendar entries :)
15:47:11 <abneiman> 3.12 team has mostly been meeting over Zoom, thanks to sandbergja hosting regular code review & other meetings
15:47:25 <mmorgan> meetings++
15:47:29 <JBoyer> We need someone to make some noise, because I play the "ignore calendar reminders" game at an expert level.
15:47:40 <dluch> lol
15:47:43 <abneiman> I mean
15:47:59 <abneiman> You can lead a horse to water but you can't make JBoyer listen to his calendar reminders :D
15:48:20 <Dyrcona> I'm not fond of coordinating over Zoom or Slack, since they are less open than IRC.
15:49:02 <abneiman> I find that it's been very effective for 3.12 since it faciliates screensharing
15:49:16 <sandbergja> There is always jitsi if we want to do a collaborative release with video calls using open source software too
15:49:30 <abneiman> and, if it's the community Zoom channel, it can be recorded and posted like other community Zoom meetings
15:49:34 <sandbergja> it's been a while since I've used it
15:49:55 <Bmagic> the alternate channel issue was already resolved: we're dropping it. A few meetings ago
15:49:57 <sleary> I don't see how they are less open given that the project has accounts. I mean, I get that everyone here is very committed to open source tools, but at a certain point we are cutting ourselves off from industry standard practices.
15:50:17 <abneiman> not to mention building walls ...
15:50:25 <JBoyer> That is extremely a case where the ends do justify the means (one of the few times that phrase actually applies)
15:50:45 <Dyrcona> I think we can table the discussion of channels and Zoom, etc., for another time.
15:51:04 <Dyrcona> My opinion should not rule the group. either.
15:51:42 <Dyrcona> Related to calendar tapping: Are we going to attempt point releases tomorrow, since it is on the calendar? Do we want to focus on the 3.12.0 release exclusively?
15:52:03 <abneiman> well, if we're discussing how to find tuits and wrangle release builds, tooling is relevant
15:52:52 <sandbergja> One question I've been wondering about: if somebody wants to just roll a release, no coordination, no calendar tapping, they just have an hour free: can they?
15:53:12 <sandbergja> not that I've had too many hours free lately, hahaha, very hypothetical question
15:53:12 <JBoyer> It depends on how much overlap there is on the various release teams. There's no reason that all 3 can't be built simultaneously provided there are enough people to do it.
15:53:33 <dluch> Good question, sandbergja!
15:53:37 <Dyrcona> sandbergja: One person could do it, provided they have all of the proper access.
15:53:59 <Dyrcona> It might be considered a bit rude, but it's technically possible.
15:54:06 <JBoyer> sandbergja, I'm not sure we want that to happen often, certainly, but yeah, it doesn't necessarily take a significant amount of time.
15:54:32 <sandbergja> that makes sense.  Thanks!
15:55:00 <jeff> do we see release teams "owning" a major release through, similar to how RMs worked in the past? if not, do we think the release team will put out the point releases, or do we need a different subset of folk doing those?
15:55:34 <Dyrcona> i was typing a thought about RMs (release maintainers/managers) when jeff asked his question....
15:56:01 <sandbergja> I've also wondered: typically we try to release point releases for all supported versions at the same time.  Definitely we need to do that for security releases, but for non-security?
15:56:03 <abneiman> it seems that even independent RMs had gotten away from owning releases, so maybe maintainer / calendar-tapper needs to be a separate role
15:56:03 <jeff> if it's the same people, then it's worth asking if the current release team is interested in point releases (and on what schedule, and what help they need)
15:56:10 <Dyrcona> Would it help if someone took "ownership' for a release series?
15:56:41 <Dyrcona> Someone could be more than 1 person.
15:57:09 <mmorgan> Or took ownership for the point release process?
15:57:33 <jeff> often the RM maintaining point releases for a major release was running that release, took ownership of getting the point releases out the door.
15:57:51 <jeff> it's not a requirement, but it was sometimes the case.
15:58:09 <Dyrcona> Well, it could go either way: someone inherits dbwells' role of "tapping the calendar" or some could adopt each release series. The only time that different releases need to be coordinated is when there are security patches.
15:59:00 * Dyrcona took over 2.0 back in the day when we started trying the release manager/maintainer model.
15:59:57 <JBoyer> and to answer sandbergja's earlier question, it's absolutely important to coordinate security releases, but while it's not necessary for non-security releases we probably don't want to let them drift too much, if the goal is to get back to some degree of regularlity.
16:00:23 <Dyrcona> JBoyer++
16:00:30 <sandbergja> JBoyer++
16:00:45 <mmorgan> JBoyer++
16:01:06 <abneiman> the crux of the issue, which we've been attempting to ameliorate with 3.12, is the lack of knowledge and documentation about the actual building. If more people knew how to do that, there would be less of an issue of the same people doing the same things
16:01:07 <jeff> we would want to avoid "that minor bug is fixed in 3.10 but not 3.11 until next month". :-)
16:01:45 <mmorgan> Also the lack of access needed to completely build and publish the release.
16:01:51 <Bmagic> I'd say that if it's one person's job to do something, you have a better chance of getting it. Because that person knows that no one else is involved, and we don't have the "well I was waiting for you"
16:01:52 <abneiman> sandbergja & gmcharlt have done a great job documenting and passing on knowledge but as someone new to the major release process, I can tell you a WHOLE LOT of this is still locked up in peoples heads
16:02:13 <abneiman> and to mmorgan's point, things like lupin access ... POeditor access ... etc. are all things we have run up against
16:02:19 <Dyrcona> I wonder how may sites use point releases? After a point they make upgrades harder.
16:03:25 <Dyrcona> We do, sort of, but we also build our production from git.
16:04:10 <jeff> lacking a larger pool of resources, do we want to say "there's now a maintenance team", and anyone interested (perhaps some subset of the release team) can work to put together a 3.10 and start to put out point releases on a schedule to be determined outside of this meeting, subject to discussion and re-evaluation after gaining some experience with the next point release?
16:04:21 <JBoyer> all of our Eg customers use them, though that's a bit easier for them than it is for me. :) I do think that the lack of a straightforward upgrade from 3.X.Y to 3.Z.U discourages their use after the main upgrade release is out.
16:04:26 <jeff> goals of the maintenance team being very similar to the release team, it might be 1:1 folk to start, with some joiners-on.
16:05:07 <jeff> and the maintenance team would have a similar goal of documenting and improving the process and ensuring that things get out of heads and into suitable community repositories of knowledge?
16:05:41 <jeff> also, feel free to say "we don't need another team, let's just make it part of the release team, and they could use a few more people to do some of these specific things"
16:06:17 <Dyrcona> We've gone a bit over our usual 1 hour time, and I'd like to come away from this discussion with 1 concrete thing, namely an answer to "Are we doing point releases tomorrow?"
16:06:27 <JBoyer> I could see that possibly helping. Not having to worry about some of the major release issues might make it a little easier to "just" handle point releases.
16:07:11 <Dyrcona> JBoyer: I have a couple of programs for that... I'd like to split the current release script up into pieces that can be run independently.
16:07:45 <JBoyer> I would love to see point released tomorrow, but I'm not available. Are enough people interested in making it happen for 3.10 and 3.11?
16:08:03 <Dyrcona> Do we want to vote on point releases tomorrow, or will we just say we'll do them, since 3.12 is being released. I could build one, maybe two of them.
16:08:27 <jeff> also, riffing on (I think it was) sandbergja's question of if anyone could build a release, we might want to ensure that building a release (even/especially one that isn't intended to be actually tagged and "published") is possible, because that's how we know we can run through all the paces frequently and find and fix rough edges / annoying things about the process.
16:08:30 <Dyrcona> Two would be all of them, woudn't it?
16:08:38 <JBoyer> I'm not sure voting will do much unless a "yes" vote is taken as volunteering to take part
16:09:11 <JBoyer> and yes, it's just 3.10.4 and 3.11.2 tomorrow
16:09:18 <Dyrcona> jeff: That's possible already. I've done it for test releases.
16:09:19 <JBoyer> (or whenever)
16:09:42 <jeff> Dyrcona: good! it's possible that no "ensuring" is needed.
16:09:47 <Dyrcona> I'll volunteer to build and upload 3.10.whatever, if we can get other roles fileld.
16:09:57 <Dyrcona> filled, that is.
16:10:27 <mmorgan> Dyrcona++
16:10:43 <abneiman> I'm not available for the rest of this week, so I can't commit to release notes
16:10:49 <dluch> Dyrcona++
16:10:53 <Bmagic> I'm in, I'll build stuffs
16:11:38 <mmorgan> Bmagic++
16:11:57 <Dyrcona> I'm off Thursday and Friday but will have some availability Friday if things run over.
16:13:15 <Bmagic> tomorrow then!
16:13:28 <Bmagic> It'll be the Dyrcona and Bmagic show!
16:13:30 <jeff> isn't the usual schedule "third wednesday" and wouldn't that be 2023-11-20? oddly, I have at least one Google calendar recurring event that seems to think tomorrow is the third wednesday. That seems... incorrect.
16:13:40 <Dyrcona> I've updated the buildmaster spreadsheet with 3.10.4, 3.11.2, and 3.12.0. If people can fill in what they're doing, that would help.
16:13:50 <dluch> Bmagic++
16:14:28 <Dyrcona> My Google calendar says monthly maintenance releaes are tomorrow.
16:14:54 <Dyrcona> I think that's actually the community development calendar.
16:15:00 <shulabear> Dyrcona++ Bmagic++
16:15:20 <jeff> (which is probably deprecated)
16:15:23 <Bmagic> I'll bring the card tricks, you bring the git repo
16:15:57 <Dyrcona> So, I think we can end the meeting on this. I'll take an action to summarize a bit of the discussion and follow up on kmlussier's emails to the development list about releases. We can continue the discussion there for now.
16:16:08 <JBoyer> Dyrcona++
16:16:14 <Bmagic> Dycrona++
16:16:28 <mmorgan> Dycrona++
16:16:39 <dluch> Dyrcona++
16:16:40 <Dyrcona> #action Dyrcona will summarize release coordination discussion and followup on the development mailing list.
16:16:42 <collum> Dyrcona++
16:16:43 <JBoyer> I think a discussion of a new regular schedule would be good too (obviously via email at this point)
16:16:43 <scottangel> Dycrona++
16:16:58 <Dyrcona> #topic Announcements
16:17:12 <Dyrcona> #info Next meetting is Tuesday, January 9, 2024
16:17:32 <Dyrcona> I'll wait a few minutes to see if anyone has any other announcements.
16:18:31 <Bmagic> I'll do the wiki stuff Dyrcona
16:18:39 <Bmagic> (For the meeting pages)
16:18:51 <Dyrcona> Bmagic++ Thanks!
16:18:58 <Dyrcona> And on that note...
16:19:02 <Dyrcona> #endmeeting