15:00:03 #startmeeting 2024-03-12 - Developer Meeting 15:00:03 Meeting started Tue Mar 12 15:00:03 2024 US/Eastern. The chair is Bmagic. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:03 The meeting name has been set to '2024_03_12___developer_meeting' 15:00:11 #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-03-12 15:00:17 #topic Introductions 15:00:20 #info Dyrcona = Jason Stephenson, CW MARS 15:00:21 #info Bmagic = Blake GH, MOBIUS 15:00:23 #info dluch = Debbie Luchenbill, MOBIUS 15:00:37 #info Stompro = Josh Stompro, LARL 15:00:37 #info abneiman = Andrea Buntz Neiman, Equinox 15:00:41 #info terranm = Terran McCanna, Georgia PINES 15:00:43 #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka) 15:00:44 #info kmlussier = Kathy Lussier, NOBLE 15:00:46 #info sleary = Stephanie Leary, Equinox 15:00:52 #info mmorgan = Michele Morgan, NOBLE 15:01:01 #info berick Bill Erickson, KCLS 15:01:02 #info smayo = Steven Mayo, Georgia PINES 15:01:17 #info sandbergja = Jane Sandberg, PUL 15:01:25 feel free to add yourself as you arrive 15:01:27 #topic Action Items from Last Meeting 15:01:31 #info mmorgan will explore moving LP stats to community site and automating same 15:01:48 Please carry forward. Wanted to also note that some of today's stats came from the Launchpad API. 15:02:00 #action mmorgan will explore moving LP stats to community site and automating same 15:02:05 #info sandbergja will see if gh actions can run the pgtap tests 15:02:20 I have a pullrequest for that, bug 2055796 15:02:20 Launchpad bug 2055796 in Evergreen "Have github actions run pgtap tests for us" [Undecided,New] https://launchpad.net/bugs/2055796 15:02:35 sandbergja++ 15:02:48 sandbergja++ 15:02:56 sandbergja++ 15:03:10 sandbergja++ 15:03:13 nice! deprecating PG10 15:03:13 sandbergja++ 15:03:34 sandbergja++ 15:03:41 #info eeevil = Mike Rylander, EOLI 15:04:01 Bmagic: We should remove Pg 10 and Pg 11 from the prereqs, but that's another conversation. 15:04:10 #info gmcharlt_ - create a Git commit message type and update bug 2051946 15:04:10 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:18 Dyrcona: right, for another time 15:05:02 I suppose we can skip this, I didn't see him type 15:05:18 don't wanna forget though 15:05:29 #action gmcharlt - create a Git commit message type and update bug 2051946 15:05:29 Launchpad bug 2051946 in Evergreen "institute a Git commit message template" [Wishlist,New] https://launchpad.net/bugs/2051946 - Assigned to Galen Charlton (gmc) 15:05:30 Looks like it is in progress. I tested the other branch that makes release notes entries. 15:05:43 gmcharlt_ is traveling today, aiui. 15:05:53 ah, cool 15:05:59 #info Stompro will formalize the tense usage in the release-note message 15:06:06 Would anyone else like to take this on, I'm not much of a wordsmith after looking into it a bit. 15:06:33 Stompro: do we have a wiki page stub for it? 15:06:40 We should probably just use past tenses: Fixed bug bla bla bla 15:07:08 Bmagic, no, I was just starting with the notes for the release-notes tag. 15:07:22 +1 to just picking one and sticking with it. I have no problem with past tense. 15:07:28 see, I was favoring present tense. "Fixes bug bla bla bla" 15:07:37 #info collum = Garry Collum, KCPL 15:07:54 I tend to write release notes now in the present/active voice but whatever, let's just pick one 15:08:02 Inconsistent tense beats no notes erryday. 15:08:02 Bmagic I think it depends on context, but I'm not married to past tense. 15:08:05 I favor present tense too. It's more active. 15:08:11 Same 15:08:24 I thought JBoyer was doing beat poetry for a sec 15:08:33 lol 15:08:38 terranm: maybe he was 15:08:38 terranm++ 15:08:42 I prefer present tense also. ... I can keep working on it. 15:08:44 how's about a vote? 15:08:45 Had I but more time! 15:08:58 Then you could rhyme? 15:08:58 Consensus seems to be present tense. No need to vote. 15:09:05 ok then, easy 15:09:33 no need for pretense, let's stick with common sense, and go for present tense 15:09:33 we shall hence forth use present tense for our release-notes tag in git commit messages 15:09:56 abneiman++ lol 15:09:56 abneiman++ 15:10:01 abneiman++ 15:10:08 abneiman++ 15:10:13 * eeevil will have used present tense perfectly in the past 15:10:21 #info agreed that release-notes tag will use present tense: 'fixes', 'updates' etc. 15:10:21 haha 15:10:34 I will update the bug 15:10:44 thanks abneiman - perfect. It is written. It's in history 15:10:48 I am the very model of a present perfect prefect.... 15:10:58 abneiman++ 15:11:16 I think we're ready for: 15:11:18 #info terranm will make LP tag "caching" official 15:11:30 Uh... I think I did that already? Checking... 15:11:56 Yes, done 15:12:01 terranm++ 15:12:03 terranm makes an authoritative request because the information was not ... cached 15:12:06 man, we're killing it today 15:12:06 terranm++ 15:12:08 terranm++ 15:12:14 Past tense is appropriate in this case 15:12:14 hahaha 15:12:14 terranm++ 15:12:20 terranm++ 15:12:22 terranm++ 15:12:23 lol 15:12:32 (sleary, now that song is in my head!) 15:12:40 #topic Evergreen 15:12:42 dluch (sorry!) 15:12:47 #info The next point releases are scheduled for March 20th (during bug squashing week). Should we push them back a week to the 27th so that our energies aren't divided between the two? Also, who'd like to help with the release? 15:13:15 I think we should wait until the 27th, and right now, I think I can help. 15:13:29 Dyrcona++ 15:13:33 re the first part, I think that's smart (and then the release can get the squashed bugs) 15:13:49 +1 (and I can help with the building(s)) 15:13:51 +1 to 27th, I can test & eval the release-notes script as part of point releases 15:13:58 +1 to March 27, I can help also. 15:14:13 Bmagic++ 15:14:16 abneiman++ 15:14:19 mmorgan++ 15:14:26 And that's my daughters birthday too, double awesome 15:14:45 #topic Documentation 15:14:50 #info DIG met March 7, will meet again during Bug Squashing Week, then at the Hackfest 15:15:12 doesn't lend itself to discussion 15:15:18 ooh I snuck in another item under Releases - which was the updated release schedule 15:15:33 I have nothing else to add--it's mostly just for info purposes in the agenda 15:15:38 abneiman: alright, looping back 15:15:40 #info updated release schedule here: https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap 15:15:53 sorry dluch, proceed :) 15:16:03 ok, you got it, nice 15:16:27 I gotta set my browser to refresh that page every couple minutes during the meeting :) 15:16:45 #info Documentation for Angular Staff Catalog is almost done! 15:16:57 :-) Well, unless anyone else from the DIG meeting wants to add anything just see the agenda, lol. Or if anyone has any questions 15:17:17 Thanks to Spencer Pennington for those Angular Staff Catalog docs! 15:17:28 spencer_pennington++ 15:17:42 and now, he has to use that nick 15:17:52 lol 15:18:04 spencer_pennington++ 15:18:18 <-- trend setter 15:18:33 #info Pre-3.12 docs now have links to current Reports docs 15:18:51 #info We'll be identifying missing 3.12 documentation to work on for Bug Squashing Week 15:18:55 #link https://wiki.evergreen-ils.org/doku.php?id=evergreen-docs:documentation_needs 15:19:16 dig++ 15:19:32 dig++ # well deserved 15:19:38 dig++ 15:20:14 #topic Launchpad Status (as of noon Eastern) 15:20:26 incoming! duck and cover 15:20:31 #info Open Bugs - 3126 15:20:31 #info Pullrequests - 98 15:20:31 #info Signedoff - 12 15:20:40 #topic Launchpad Status since last meeting 15:20:44 #info Bugs Added - 59 15:20:44 #info Pullrequest tag Added - 27 15:20:44 #info Signedoff tag Added - 26 15:20:44 #info Fix Committed - 31 15:20:55 #topic New Business - Call for volunteer to give the development update at the conference 15:21:17 I vote Spencer 15:21:25 mmorgan++ # stats 15:21:27 I can definitely help with dev update, since redavis and I will have a lot of that content in our slides already 15:21:40 mmorgan++ 15:21:43 mmorgan++ abneiman++ 15:21:57 abneiman++ 15:22:05 abneiman++ # sounds like you're doing it 15:22:18 abneiman++ 15:22:30 sure, whatevs. If anyone has things they want to make sure I cover, you all know various ways to get ahold of me. 15:22:49 abneiman++ 15:22:51 awesome 15:23:08 #info redavis = Ruth Davis, Evergreen Indiana and other stuff 15:23:10 and now the one we've all been waiting for 15:23:12 #topic New Business - Barriers to getting things committed 15:23:17 I can start this off 15:23:25 please do 15:23:26 I want to commit more pullrequests, but when I try, I often run into the same barriers: 15:23:27 (1) no test environment available, (2) no test plan, (3) test plan is difficult to set up, (4) merge conflicts, esp with code that has sat uncommitted for months, (5) extra overhead required to backport and/or unsure whether to backport, (6) unresolved questions about the fix. 15:23:40 I wonder if there are things we can be doing to mitigate some of those barriers? 15:23:53 For example, would more community dev VMs be helpful? 15:24:14 For 5 we can backport fewer fixes, particularly those that touch the database. 15:24:23 I think the answer is: yes 15:24:58 do we need a system for people to "checkout" a VM so it's their's for a time? 15:25:27 It seems that if we address some of the others, 4 might take care of itself (i.e. if we have a quicker commit cadence, branches won't sit for as long) 15:25:39 4 is a problem, but especially a chicken-and-egg thing since the longer things sit without review the more conflicts they accumulate. For 2, I can commit to sharing test plans for Equinox-developed features. 15:25:45 we could use Evergreen to manage the checkouts 15:25:51 sandbergja: great minds, lol 15:25:52 i also think it is perfectly fair to comment on the bug that there is no test plan provided, and it's not obvious how to test the bug. 15:26:27 For 4, it's also perfectly fine to ask the original developer to rebase it, or at least comment that it needs a rebase if you're not comfortable doing it yourself. 15:26:59 If you are the person rebasing it, and the merge conflicts have to do with CSS or ARIA, please ping me here and I'll be happy to help. 15:27:03 +1, asking for dev rebases is totally fair game 15:27:09 sleary++ 15:27:34 I've also shared pullrequests and had to rebase them multiple times, which gets frustrating, so asking the dev to rebase is fair but only goes so far IMO. 15:28:18 so it sounds like we really have 4 communications problems, 1 technical problem (test environments), and 1 practice problem (when do we backport?) 15:28:27 jeffdavis: I do try to handle the rebases myself, but sometimes, its not obvious how to resolve it. 15:29:19 abneiman++ 15:29:21 abneiman: great point 15:29:24 Often, when somebody asks for a rebase, it's during a rare moment when the tester has time to look at the code. If the person doesn't rebase it quickly, that person may no longer be available to test. Not so much a communications problem, but a tuits problem. 15:30:08 I think that's more of a time problem. Most of us have "other jobs" or at least our job has more requirements than working on Evergreen code. 15:30:54 abneiman++ 15:31:37 perhaps if a tester and a dev had a quick conversation, though, everyone's time could be used more valuably - "hey I'm planning to test this in $timeframe, do you mind looking at a rebase?" "I can do rebase within $possibleothertimeframe and let you know when it's done" etc etc 15:32:09 I think the code review sessions have been great for getting folks together to tackle individual bugs, whatever their issues. 15:32:27 code review is GREAT for this 15:32:31 sandbergja++ 15:32:35 times a million 15:32:41 sandbergja++ 15:32:44 sandbergja++ 15:32:44 I wonder if this would be a great thing to work on at the conference hackfest. To get some procedures hashed out. 15:32:49 devs being available to do rebases during bug squashing weeks is also really helpful 15:32:50 sandbergja++ 15:32:52 sandbergja floated the idea of a rebasing party during the code review meeting on Monday. If people would like to do that this Friday, I can be available to help out with all the UI stuff that changed in the last couple of versions. 15:33:07 redavis: that's a good thought! 15:33:15 sandbergja++ sleary++ 15:33:23 don't want to lose terranm 's point about devs / committers being engaged with BSW 15:33:33 that's a time when a critical mass of people are testing, etc. 15:33:38 terranm++ 15:33:44 agreed 15:33:46 agreed 15:33:59 terranm++ 15:34:04 abneiman++ terranm++ 15:34:17 sleary I love the idea of a rebase party! (Unfortunately I'll be out on Friday, but next time!) 15:34:48 ain't no party like a rebase party 15:35:00 All about dat rebase 15:35:07 what time on Friday? 15:36:06 sleary: wanna take it to the mailing list? 15:36:22 @quote add All about dat rebase 15:36:22 abneiman: Error: You must be registered to use this command. If you are already registered, you must either identify (using the identify command) or add a hostmask matching your current hostmask (using the "hostmask add" command). 15:36:23 sure 15:36:41 sweet, I'll be there if I can 15:36:55 @quote add All about that rebase. 15:36:55 Dyrcona: The operation succeeded. Quote #242 added. 15:37:02 thanks, lol 15:37:09 the conversation seems to be winding down. We have another topic to go over 15:37:17 #topic New Business - Dev documentation: volunteer needed to update versioning page 15:37:26 re: bugs (and I'm not trying to call anyone out, just showing an example) see bug 1017990 - the last comment shows a dev needing to verify a particular use case that might need to be considered, then there's not a follow-up - so a bug with a proposed branch has lingered - my point is that the bug needs to be left in an actionable state 15:37:26 Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990 15:37:38 #link https://wiki.evergreen-ils.org/doku.php?id=versioning 15:37:40 is it winding down? I think we should hear from other devs / committers 15:37:51 maybe this is the "needsdiscussion" discussion, but thought I'd mention why I don't complete bugs some of the time 15:38:32 csharp_: I think that bug should be marked invalid. I think it is acceptable to bypass the holds limits that way. 15:38:55 Dyrcona: ha! so maybe it does need actual discussion :-) 15:39:16 needsdiscussion is the tag where bugs go to die. 15:39:27 :), nevermind on the winding down 15:39:30 Oh, my. That's an old bug. I even have comments on it. 15:39:35 Dyrcona: curious if you have an alternate suggestion? 15:40:35 Regarding test environments - community ones that can be checked out exclusively would be great 15:40:48 Maybe we need to have a needsdiscussion cleanup party, too 15:40:55 Bmagic++ mmorgan++ 15:40:56 terranm++ 15:40:57 abneiman: I'd have to read the whole bug and comments again, but I recall my initial reaction to the bug being filed was "that isn't a bug, it's a feature." 15:41:00 terranm++ 15:41:18 But I find a docker of virtualbox vm where I have full access is more useful. 15:41:22 Also agree that check-outable community dev environments would be awesome 15:41:23 Dyrcona: I meant about the process in general, not that specific bug 15:41:36 * mmorgan always needs access to the database 15:41:39 mmorgan: I used to do that with the masslnc server, but that server is long gone. 15:41:48 We're moving to a new environment later in the year that may be able to support a few dev VMs for committers, can't promise anything but I'll discuss with my org if that's useful 15:41:54 abneiman: i.e., alternative to "needsdiscussion"? 15:42:00 jeffdavis++ 15:42:00 IIRC the Koha community used to have an automated way of handling that. 15:42:09 mmorgan: I'm thinking the same: full access to root on a VM. 15:42:11 there's only 101 bugs tagged needsdiscussion out of 3106 open ones, so I'd argue the issue isn't needsdiscussion, it's general bug languishment 15:42:12 For me, it's mostly a matter of time. I have a lot of other stuff going on. Also, I notice several committers seem to be in a similar boat and don't participate as much as they used to. 15:42:18 (or docker machine) 15:43:13 I think we have a resource bottleneck when it comes to people with the time to devote. There are some processes that might help. 15:43:24 docker makes sense to me, but it adds some overhead 15:43:45 +1 to Docker 15:44:31 so I'm just throwing this out there - a lot of work goes into, and gets accomplished, in bug squashing weeks. Lower effort / less work accomplished (but still important work getting accomplished) in the code review sessions but they don't often have senior committers show up, except for sandbergja. Trust me I am very sympathetic to time constraints on devs. 15:44:41 but what I'm wondering is, is there a middle way? 15:44:58 I could tailor make a container for anyone who wants to host it (including us), for the purpose of including someone's key so they can ssh into the container and go to town 15:45:01 We might be able to help with VMs...have to discuss internally, though 15:45:08 Monthly half-day open code reviews or the like, with rotating responsibilty for hosting / VMs? 15:45:39 Bmagic: for me/us, the networking piece is an issue - PINES/GPLS machines are behind a finicky firewall :-/ 15:45:44 We're supposed to be requiring test plans and release notes, so enforce that. (I've been adding them for my recent branches.) 15:45:54 but we can talk logistics at that level later 15:45:58 and a committment from each senior committer to attend 1 per year or something 15:46:06 abneiman: I think a middle way is desireable. Smaller and more consistent contributions is a better approach than a mass of contributions / review happening at the same time. 15:46:07 csharp_: cool, I'm sure we can figure something out 15:46:13 abneiman: I'll start showing up 15:46:41 csharp_++ 15:46:47 To Dyrcona's point, with so many new core committers, have they received onboarding telling them they should be looking for these requirements and asking for them when needed? 15:47:18 For me, it's actually easier to set aside time on my calendar for a big chunk of time during bug squashing week than it is to do a little bit here and there. That might just be a "me" thing though. 15:47:27 Well. that's something that I thought of last week, and don't recall if I mentioned it. We ought to have something for new core committers. 15:47:39 kmlussier: yes, that's what I'm thinking - small & consistent, not everyone has to be at EVERY thing but can everyone be at A thing? Bonus if some learning transfer can happen from long-term committers to newer committers? 15:48:07 it's easier for me, if I can schedule it ahead of time, and bug squashing week is good because we encourage staff here to participate. 15:48:28 abneiman++ 15:48:50 terranm: +1 - was going to say earlier that rhythm/momentum (and lack thereof) is a problem for me in EG community dev 15:48:52 +1 to onboarding new committers--that seems really important 15:48:52 We walk through the committing process most weeks during the code review session 15:49:36 it's not just a matter of time/tuits - I just need to develop better habits 15:49:47 I'm just trying to think about ways to spread the load - if more people are doing things, we're relying less on the community unicorns (you know who you are lol) to shoulder so much 15:50:02 ++ 15:50:03 I've also been burned by not testing some big things thoroughly enough, so I like to set aside at least a day to test even small things. 15:50:35 (if you're in this meeting, you're a community unicorn) 15:50:45 redavis++ 15:50:46 kmlussier gmcharlt_ went over things with me, but I don't think there is much written down in the wiki on going from contributor to committer 15:51:02 redavis++ 15:51:09 🦄🦄🦄 15:51:12 redavis: No, I'm just here because I like talking to all of you. 15:51:30 we're coming up on our hour yall 15:51:31 Dyrcona made me think of something that would be helpful for me: if there is a way we could run the tests against each pull request automatically. 15:51:46 kmlussier: If you do want the commit bit back, just let me know. I can do it without a vote. :) 15:51:58 That green checkbox in Github saying "your tests passed" really helps me in other open source projects 15:52:02 redavis brought up earlier the idea of talkng about this at the hackfest. I've been thinking it might be worthwhile to have a monthly meeting where we could focus on one problem we want to solve. Because we could talk about this all day. 15:52:09 sandbergja: yes! a container that lauches with a branch and runs the test and dumps the results 15:52:44 * csharp_ feels us teetering on the edge of the "move Git" discussion - keep his mouth shut 15:52:46 it wouldn't catch everything for sure, but it would provide a bit of a confidence boost 15:52:47 Dyrcona: I won't ask for it back unless I know I have the time to contribute. 15:52:58 kmlussier++ 15:53:25 ok, yall wanna cover this one now? 15:53:31 #topic New Business - Dev documentation: volunteer needed to update versioning page 15:53:52 * dluch envisioning Captain America's "I can do this all day..." 15:54:40 Is there more detail behind the request? Mailing list thread, etc? 15:54:54 no, this came up when the release team met this morning 15:55:01 we can put it on the mailing list 15:55:10 https://wiki.evergreen-ils.org/doku.php?id=versioning 15:55:13 Are we talking about freshening up the examples and the OpenSRF / PostgreSQL deps? 15:55:14 ok, good idea, mailling list 15:55:16 OTOH I think more automated testing is always going to be a good thing but I will not teeter us into "move git" today 15:55:31 move Git tomorrow ;) 15:55:31 #topic New Business - Possible hackfest (or other date) discussion on Evergreen releases - see email (Kathy) 15:55:41 #link http://list.evergreen-ils.org/pipermail/evergreen-dev/2024-February/000740.html 15:56:07 heh 15:56:10 It's late, so I just want to know if there is support for this discussion and whether you want me to facilitate it. I'm okay with it if you don't want me there. 15:56:28 yes please!!! 15:56:30 kmlussier: yes, I for one support this discussion 15:56:37 kmlussier please do! 15:56:43 Also, I would like to suggest we not do it during the hackfest, but plan another day for it so that you all can accomplish other things during the hackfest. But I'll be happy to do it whenever. 15:56:44 kmlussier++ 15:56:49 kmlussier++ 15:57:00 kmlussier++ 15:57:02 +1 to not during hackfest 15:57:06 kmlussier++ 15:57:14 Again, I think we have plenty of big picture things we're working on to plan monthly in-depth discussions. 15:57:16 +1 to discussion and +1 to not-hackfest 15:57:23 +1 to not-hackfest, too. Especially since all the IGs are meeting then 15:57:34 are we thinking epic zoom call, or something else? 15:57:35 and also +1 to not doing it durning hackfest, since hackfest is positioned between slush & freeze for 3.13 15:57:46 OK, I'll begin planning for something post conference. 15:57:53 * abneiman waves the wild flag of subtle hint at the devs 15:58:01 its it's own thing 15:58:12 * csharp_ lets his freak flag fly 15:58:13 jeff: I'm thinking Zoom, but also offering opportunities for writen feedback for those who are not comfortable with speaking up. 15:58:24 EPIC.ZOOM.CALL 15:58:33 kmlussier: sounds good! 15:58:40 csharp_: You're too late. I cut my hair Saturday. 15:58:44 kmlussier: while you're up 15:58:46 #topic Community calendar (Kathy) 15:58:47 Dyrcona: I almost did 15:59:01 csharp_: I wonder why. :) 15:59:08 Dyrcona++ 15:59:32 I added this to the agenda because the releases still seem to be on the old dev calendar. Are the devs still maintaining that calendar or should everything be moved to the communtiy calendar? 15:59:47 I know I could have posted the question to the list, but I was already editing the wiki page and went wild with it. 15:59:48 oh! I thought the old calendar was dead 15:59:57 * sleary had no idea there was a dev calendar 16:00:02 kmlussier: I think that ^^ answers your question 16:00:14 yeah, I think old calendar is dead 16:00:16 Yeah, I thought everything was supposed to go on the community calendar now 16:00:18 we should use the community calendar for everything, yes 16:00:21 kmlussier: I can move them, I think, if that's the consensus. 16:00:28 delete the old calendar so there is no confusion 16:00:30 new calendar doesn't have release dates, but we just decided them this morning, and I can add those to community calendar 16:00:31 Dyrcona++ Thanks! 16:00:33 just be careful about alarms on those events :) 16:00:34 @blame The Old Calendar 16:00:34 csharp_: The Old Calendar 's bugfix broke csharp_'s feature! 16:00:44 lol 16:01:02 Dyrcona++ 16:01:05 abneiman: The point release dates were recurring and neverending as far as I can tell. 16:01:08 I was think of the point releases, is that correct, or are we talking about something else? 16:01:13 @praise The Community Calendar 16:01:13 * pinesol The Community Calendar can count to 1 billion 16:01:32 ah yes forgot about those 16:01:36 Dyrcona++ 16:01:37 but does it have sharks with laser beams? Are they ill tempered? 16:01:39 pinesol++ 16:01:42 +1 to moving them 16:01:52 and +1 to deleting the old calendar 16:01:53 Dyrcona++ # thanks! 16:02:09 Thanks all for letting me pretend I'm still a dev today! :) 16:02:12 @band add Frickin' Laser Beams 16:02:12 csharp_: Band 'Frickin' Laser Beams' added to list 16:02:22 +1 to moving point releases and deleting the old dev calendar 16:02:25 csharp_++ 16:02:28 kmlussier: you can checkout any time you like but you can never leave! 16:02:58 abneiman: I tried. Won't try it again. 16:03:19 I'll release everyone, but you can stay and chat if you want! 16:03:21 #info Next Meeting is Tuesday, April 9th 2024 16:03:22 kmlussier++ # one of us 16:03:28 #endmeeting