15:00:02 <Bmagic> #startmeeting 2024-05-14 - Developer Meeting
15:00:02 <pinesol> Meeting started Tue May 14 15:00:02 2024 US/Eastern.  The chair is Bmagic. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:02 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:02 <pinesol> The meeting name has been set to '2024_05_14___developer_meeting'
15:00:10 <Bmagic> #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-05-14
15:00:16 <Bmagic> #topic Introductions
15:00:20 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:00:30 <Dyrcona> #info Dyrcona = Jason Stephenson, CW MARS
15:00:34 <kmlussier> #info kmlussier = Kathy Lussier, NOBLE
15:00:36 <sandbergja> #info sandbergja = Jane Sandberg, PUL
15:00:39 <dluch> #info dluch = Debbie Luchenbill, MOBIUS
15:00:46 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:00:47 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka)
15:01:01 <jvwoolf> #info jvwoolf= Jessica Woolford, Bibliomation
15:01:22 <shulabear> #info shulabear = Shula Link, GCHRL
15:01:59 <mantis1> # info mantis = Gina Monti, Bibliomation
15:02:14 <scottangel> #info scottangel = Scott Angel, MOBIUS
15:02:18 <berick> #info berick Bill Erickson, KCLS
15:03:03 <Stompro> #info Stompro = Josh Stompro, Lake Agassiz Regional Library (LARL)
15:03:19 <Bmagic> feel free to add yourself as you arrive
15:03:33 <Bmagic> #topic Action Items from Last Meeting
15:03:41 <Bmagic> #info gmcharlt - create a Git commit message type and update bug 2051946
15:03:41 <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:18 <Bmagic> gmcharlt_ may not be here atm
15:04:32 <Bmagic> carry forward
15:04:34 <Bmagic> #action gmcharlt - create a Git commit message type and update bug 2051946
15:04:42 <Bmagic> #info mmorgan will explore moving LP stats to community site and automating same
15:04:47 <collum> #info collum = Garry Collum, KCPL
15:04:50 <mmorgan> Nothing new this month, please carry forward.
15:05:04 <Bmagic> #action mmorgan will explore moving LP stats to community site and automating same
15:05:09 <Bmagic> #info Bmagic will write announcement+blog post for deprecation of open-ils.circ.title_hold.is_possible and open-ils.circ.holds.create[.override]
15:05:28 <Bmagic> This was done, albeit, revised by the community and re-blog-posted
15:05:45 <Bmagic> I think we can mark it off :)
15:06:01 <Bmagic> #info JBoyer will throw a branch on lp 1017990 to loudly inform the logs something is still calling that ^
15:06:01 <pinesol> Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990
15:06:53 <Bmagic> hmmm, I feel blind sided by this one. It's not merged for 3.13 (yet)
15:07:35 <Bmagic> JBoyer++
15:07:43 <Bmagic> csharp++
15:07:54 <Bmagic> Stompro++
15:08:05 <redavis> #info redavis = Ruth Davis, ECDI
15:09:50 <Bmagic> gmcharlt++ jeffdavis++ berick++ kmlussier++ phasefx++ # shoulda taken stake of the full list before I started karma-ing
15:10:25 <Dyrcona> Uh huh. So is someone going to review it and commit it? Maybe after beta is official?
15:11:06 <Bmagic> Haven't seen Thomas Berezansky's nick in a long time, not sure what it is
15:11:18 <kmlussier> tsbere++
15:11:37 <Bmagic> Dyrcona: I think it needs to be merged for 3.13
15:11:56 <kmlussier> Honestly, I feel like the staute of limitations has run out for some of to receive karma for that bug.
15:12:09 <Dyrcona> :)
15:12:14 <Bmagic> :)
15:12:27 <kmlussier> So somebody needs to take that as an action item?
15:12:33 <Bmagic> good idea
15:12:41 <Bmagic> anyone want to?
15:13:02 <Dyrcona> I'll take it if no one else wants to.
15:13:09 <Bmagic> sold
15:13:24 <mmorgan> Dyrcona++
15:13:26 <sandbergja> Dyrcona++
15:13:37 <kmlussier> Dyrcona++
15:13:40 <Bmagic> #action Dyrcona will take a look at bug 1017990 for merging into main and 3.13
15:13:40 <pinesol> Launchpad bug 1017990 in Evergreen "Possible to bypass holds placement limits via direct API calls" [Medium,Confirmed] https://launchpad.net/bugs/1017990
15:13:41 <shulabear> Dyrcona++
15:14:16 <Bmagic> thank you Dyrcona!
15:14:31 <Bmagic> I suppose that wraps that one for now
15:14:40 <Bmagic> #info eeevil will open a bug for cross-column stats targets
15:15:28 <Bmagic> not here, anyone else have a bead on that?
15:15:40 <eeevil> ah! here now
15:15:45 <Bmagic> !!
15:16:25 <eeevil> I will do that soon (for some definition of "soon")
15:16:34 <Bmagic> carrying it then
15:16:40 <eeevil> +1
15:16:46 <Bmagic> #action eeevil will open a bug for cross-column stats targets
15:16:59 <Bmagic> eeevil++
15:17:38 <Bmagic> skipping down the agenda unless anyone wants to ad hoc plug into OpenSRF/Evergreen/Hatch/Documentation (yes, I refreshed the page, nothing added as of 3 seconds ago)
15:18:50 <Bmagic> It's probably worth mentioning:
15:19:09 <Bmagic> #topic Evergreen 3.13 beta release tarball is available
15:19:27 <redavis> !!!
15:19:30 <Bmagic> #link https://evergreen-ils.org/downloads/Evergreen-ILS-3.13-beta.tar.gz
15:19:42 <sandbergja> nice!  woohoo!
15:20:20 <Bmagic> If anyone has some time, testing that would be sweet
15:20:37 <mmorgan> Bmagic++ berick++ shulabear++ sleary++ abneiman++
15:20:38 <dluch> releaseteam++
15:20:47 <redavis> Bmagic++ berick++ shulabear++ sleary++ abneiman++
15:21:14 <kmlussier> Bmagic++ berick++ shulabear++ sleary++ abneiman++
15:21:19 <dluch> Bmagic++ berick++ shulabear++ sleary++ abneiman++
15:21:32 <Dyrcona> I'll have a look at it.
15:21:33 <shulabear> bmagic++ sleary++ berick++ abneiman++
15:21:42 <jvwoolf> Bmagic++ berick++ shulabear++ sleary++ abneiman++
15:21:44 <Bmagic> berick++ shulabear++ sleary++ abneiman++
15:21:51 <Bmagic> karma party!
15:22:01 <Dyrcona> Bmagic++ berick++ shulabear++ sleary++ abneiman++
15:22:39 <Bmagic> next up
15:22:43 <Bmagic> #topic Launchpad Status (as of noon Eastern)
15:22:46 <Bmagic> incoming paste
15:22:53 <Bmagic> #info Open Bugs - 3087
15:22:53 <Bmagic> #info Pullrequests - 88
15:22:53 <Bmagic> #info Signedoff - 8
15:23:00 <Bmagic> #topic Launchpad Status since last meeting
15:23:05 <Bmagic> #info Bugs Added - 47
15:23:05 <Bmagic> #info Pullrequest tag Added - 30
15:23:05 <Bmagic> #info Signedoff tag Added - 22
15:23:05 <Bmagic> #info Fix Committed - 36
15:23:17 <Bmagic> #topic New Business - LP#2042158 - should we recommend disabling Postgres JIT?
15:23:22 <Bmagic> #link https://bugs.launchpad.net/evergreen/+bug/2042158
15:23:22 <pinesol> Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [Undecided,Confirmed] - Assigned to Galen Charlton (gmc)
15:24:28 <jeffdavis> I think the consensus at the last meeting was that we should recommend disabling it for now. Not sure if there is more to discuss?
15:25:05 <Bmagic> I remember some good nuggets from eeevil on this one. The jist was "we wrote Evergreen to basically do jit before jit existed, and now that PG has this feature, it's jit on top of jit, which is anti-jit (slow)"
15:25:18 <csharp_> so the effect of JIT is slow queries?
15:25:40 <Bmagic> The one place that caused me pain was saving a MARC record, timed out!
15:25:43 <csharp_> ah - just read the eeevil quote
15:25:44 <eeevil> heh ... csharp_, no, not necessarily
15:26:10 <eeevil> (that isn't a direct quote, fwiw :P)
15:26:15 <Dyrcona> Bmagic: Saving MARC records can be slow regardless of JIT.
15:26:17 <redavis> lol
15:26:19 <Bmagic> right, I was paraphrasing
15:26:19 <csharp_> (we're still on PG 11 fwiw)
15:26:45 <csharp_> "twasn't me" --eeevil
15:26:54 <eeevil> JIT introduces the possibility of plan instability, depending on ... details
15:27:47 <Bmagic> the branch for that bug updates a single documentation file, fyi
15:28:43 <Dyrcona> Well, push it, then. :)
15:28:52 <redavis> not as a derail question, but out of curiosity, would it be a worthwhile endeavor to eventually unravel the "jit"ing behavior from EG and leverage JIT in Postgres?
15:28:53 <csharp_> push it real good
15:29:09 <Bmagic> ok, lol, I typed some stuff, then waited, then backspaced, the waited
15:29:46 <csharp_> redavis: maybe worth experiments for someone with the tuits
15:29:50 <eeevil> redavis: yes, but JIT is a level 10 spell and I would council that we should figure out the level 3 spells of better stats generation first
15:29:55 <csharp_> (and the knowledge)
15:30:12 <Bmagic> redavis: yes! I think the general idea is that "we" could see about what sort of speeds we could get using it
15:30:19 <Bmagic> eeevil++ # level 10 spell, lol
15:30:21 <eeevil> but if anyone wants to deep dive on JIT, please!
15:30:24 <redavis> That was my thinkin's.  Cool.  Thanks for the spell wisdom.  Makes sense.
15:30:44 <Bmagic> ok, that's another branch to merge.....
15:30:52 <Bmagic> someone else should probably do it
15:30:55 <Dyrcona> FWIW, I don't disable JIT on my test db with Pg12+.
15:31:09 <csharp_> I would have to watch a tutorial - my scant reading doesn't have me grokking it yet
15:31:37 <Bmagic> (since I authored it) - anyone want to take the action item?
15:31:45 <csharp_> could be one of those things that tests fine but causes havoc at scale
15:31:50 <Bmagic> or I guess I should back up and ask if it needs* to make it in before 3.13 is official
15:32:13 <csharp_> I think since PG11 is dead, we should push it asap
15:32:22 <Dyrcona> csharp_: Depends on a number of factors from what I understand.
15:32:24 <Bmagic> IMO it's worth pointing it out in our documentation for folks to "remember" it's there
15:32:40 <eeevil> Bmagic: I'll doublecheck the branch and merge if there's nothing sticking out to me
15:32:47 <csharp_> eeevil++
15:32:51 <Bmagic> eeevil++
15:32:54 <redavis> eeevil++
15:32:58 <kmlussier> eeevil++
15:33:00 <Dyrcona> eeevil++
15:33:05 <Bmagic> #action eeevil will see about merging bug 2042158
15:33:05 <pinesol> Launchpad bug 2042158 in Evergreen "Postgres 12+ needs to have JIT disabled" [Undecided,Confirmed] https://launchpad.net/bugs/2042158 - Assigned to Galen Charlton (gmc)
15:33:11 * eeevil engages karma generator, apparently
15:33:21 <redavis> yeah boi
15:33:25 <Bmagic> lol
15:33:34 <Dyrcona> Meetings are for karma.
15:33:36 <csharp_> actual_evil--
15:33:42 <shulabear> eevil++
15:33:44 <Bmagic> the next thing is a multi-part thing
15:33:49 <shulabear> eeevil++
15:34:03 <Bmagic> #topic New Business - commit formatting and "infrastructure" commits (see discussion in LP#2039609)
15:34:16 <Bmagic> #link https://bugs.launchpad.net/evergreen/+bug/2039609
15:34:16 <pinesol> Launchpad bug 2039609 in Evergreen "wishlist: Acquisitions Sprint A - Z39.50 and other fixes" [Wishlist,Fix committed]
15:34:34 <Bmagic> #info Should LP bug references be required in commit messages?
15:34:46 <Bmagic> I'll stop here for discussion
15:34:47 <Dyrcona> Yes.
15:35:07 <kmlussier> @quote add <Dyrcona> Meetings are for karma
15:35:07 <pinesol> kmlussier: 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:35:08 <Bmagic> I also think: yes
15:35:11 <redavis> Yes - if LP is forever(ish)
15:35:21 <kmlussier> +1 from me.
15:35:33 <dluch> +1
15:35:34 <mmorgan> +1
15:35:36 <eeevil> I mean, sure. but that only matters at the final merge/pick
15:35:45 <csharp_> @quote add <Dyrcona> Meetings are for karma
15:35:45 <pinesol> csharp_: The operation succeeded.  Quote #244 added.
15:35:56 <kmlussier> csharp_++
15:36:18 <kmlussier> I often use the LP numbers in the commit to refer back to whatever discussion may have happened around the commit.
15:36:23 <Bmagic> dont we have a wiki page with this mentioned?
15:36:23 <berick> huh, thought we agreed on that like 12 years ago
15:36:24 <csharp_> there's lots o' text on that bug - can someone summarize the context?
15:36:26 <Dyrcona> Following up on what eeevil said, don't be afraid to tell the author to fix their commits.
15:36:41 <kmlussier> Bmagic: I added a link to that wiki page in the agenda.
15:37:10 <kmlussier> #link https://wiki.evergreen-ils.org/doku.php?id=dev:git#commit_messages
15:37:18 <Bmagic> kmlussier: lol, we're not to that part yet, which is why I didn't see it
15:37:21 <Bmagic> lol
15:37:23 <Bmagic> kmlussier++
15:37:52 <jeffdavis> I think in the context of the bug, there were some changes to shared components, and the question was whether to tag those changes with the LP bug of the feature that the changes were made for, given that the effects of the changes are broader than that.
15:38:23 <csharp_> jeffdavis: thank you
15:38:32 <Bmagic> right! jeffdavis++
15:38:45 <jeffdavis> Mike didn't want to bury shared component changes in a big commit focused on other stuff, but the result was that folks weren't sure which commits they were supposed to look at.
15:38:45 <eeevil> I'm not convinced that every commit needs an LP prefix, tbh ... some commits happen because of, but not for, an LP bug ... but ... well, what jeffdavis just said
15:39:05 <csharp_> I hates omnibus bugs because tracking that kind of thing can be very time consuming
15:39:37 <Bmagic> I like the commits to mention the bug in the title line, so I know how far back to cherry pick :)
15:39:39 <eeevil> csharp_: the flip side, of course, is that 50 tiny bugs never get synchronized and committed
15:39:51 <redavis> An omnibus bus is better than no bug though.  And in the case of some new features, they grew out of some bugs but have way more.
15:39:54 <mmorgan> When reviewing branches, it has sometimes been confusing if the number of commits isn't specified, and there are no lp numbers in the commits.
15:40:00 <csharp_> 1 bug <--> 1 issue is the kind of granularity I try for
15:40:06 <mmorgan> Commits can get missed.
15:40:10 <csharp_> but I'm not developing big ol' UIs and things
15:40:16 <kmlussier> But if the commit with the shared component is added to a specific launchpad bug, and then somebody has feedback on that shared component as part of testing, won't that discussion be on that specific LP bug even if it's for a distinct feature?
15:40:35 <csharp_> mmorgan: I agree
15:41:11 <kmlussier> csharp_: So are you saying those shared components should get their own distinct bug?
15:41:12 <redavis> (s/omnibus bus (that's funny)/omnibus bug)
15:41:28 <Bmagic> omnibug bus
15:41:32 <kmlussier> redavis: lol. I hadn't even noticed!
15:41:34 <csharp_> kmlussier: I'm not sure...
15:42:01 <sandbergja> I think distinct bugs for shared components can be helpful
15:42:01 <csharp_> I think mmorgan expressed my problem with omnibugs
15:42:16 <Dyrcona> I don't mind the number of commits so long as there's nothing extra in the branch.
15:42:29 <Bmagic> if the commit was needed for a bug you're working on, but does something to shared components, I still think it needs some* LP number on the title line. And if your bug is the only one that exists, tag it!
15:42:29 <redavis> It seems like there is a need for flexibility.  Of course some things are harder to track than others.  But a good faith attempt to corral the infos is worthwhile.
15:42:40 <eeevil> to be clear, I'm not saying I refuse to add LP prefixes. the example has context, which jeffdavis pointed out -- "here's some prereq stuff. it changes shared components and should be considered outside the feature targeted by LPxyz"
15:43:14 <Dyrcona> I think if the change is made because of a LP bug, then it should get tagged with that LP bug number.
15:43:25 <redavis> Dyrcona++
15:43:27 <mmorgan> Agree
15:43:51 <eeevil> I didn't want to anyone (including myself, selfishly) to have to engage in extra intermediate work /at that moment/ to review things
15:44:26 <Bmagic> I'm not sure, but this doesn't seem like a vote
15:44:32 <redavis> lol
15:44:41 <Dyrcona> Well, it's not hard to review things honestly. Just checkout the branch and rebase it on main if its not up to date.
15:44:42 <csharp_> there's not a consensus for anything
15:45:13 <mmorgan> Extra intermediate work may save work further down the line...
15:45:16 <csharp_> yeah, and hints in the bug comments usually say "the top 10 commits on <branch>"
15:45:22 <eeevil> if all commits on a branch attached to an LP must have that LP prefix before being pushed to working, I'm fine with that rule. but that's not ... what I though the rule was, and wanted to avoid extra work that would 1) delay testing 2) make everyone that wanted to look at it move to another branch
15:45:27 <redavis> Does it need to be a vote? since it's already in the guidelines?
15:45:45 <berick> i don't think we're talking about working bracnches eeevil
15:45:52 <berick> just the final product
15:45:53 <csharp_> can we just keep it as a guideline and just strongly recommend or something?
15:46:22 <Dyrcona> I think we're talking a bit about both. Some find it difficult to review a working branch if the commits are not tagged.
15:46:24 <csharp_> obvs this isn't my issue, so I'm hoping that's not a bad suggestion
15:46:27 <eeevil> berick: ok, that was my understanding too ... and that was a working branch. as in, pushed to the working/Evergreen repo
15:47:20 <kmlussier> If you don't have the LP bug numbers in the working branch, then you're expecting the core committer to udpate the commit message before merging it?
15:47:20 <jeffdavis> I don't think working branches need to be in a final state with proper LP tagging and everything...
15:47:33 <csharp_> I will say that the untagged commit messages in the code can get confusing when trying to retrace history
15:47:35 <jeffdavis> ...but maybe that should be the expectation at review/pullrequest time?
15:47:53 <Dyrcona> I think they should be before the pullrequest tag is added, or I might tell you to fix it. :)
15:47:55 <berick> OK, so it should have them by the time the pullrequest tag is added.
15:47:59 <csharp_> "the code" == "main"
15:48:01 <berick> jinx
15:48:12 <kmlussier> OK, got it. That makes sense to me.
15:48:13 <Bmagic> yes, I like the pullrequest rule
15:48:24 <csharp_> also, use squash/fixup where possible
15:48:28 <mmorgan> +1 to the pullrequest rule
15:48:33 <csharp_> nobody needs to see your process :-)
15:48:36 <Bmagic> Anyone want to clairify this in our guideline wiki page?
15:48:49 <kmlussier> I can do that.
15:48:53 <mmorgan> Also, as csharp_ said, "the top 10 commits on <branch>" type comments are helpful
15:48:58 <redavis> kmlussier++
15:49:12 <dluch> kmlussier++
15:49:14 <mmorgan> kmlussier++
15:49:32 <Dyrcona> kmlussier++
15:49: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:50:03 <kmlussier> As far as missing commits for those big omnibus branches, Dyrcona, didn't you have a special command to pick the whole branch? quickpick?
15:50:20 <shulabear> fwiw, the newdevs:git wiki suggests a good practice is prefacing your working branch with the related launchpad bug
15:50:21 <shulabear> https://wiki.evergreen-ils.org/doku.php?id=newdevs:git:create
15:50:29 <eeevil> (and, yeah, I do think the committer can amend the commits as appropriate -- or ask the author for a cleanup "final" branch)
15:50:46 <Dyrcona> kmlussier: I do, but I don't use it any more. I do this `git cherry-pick ^HEAD working/user/whoever/branch`
15:51:15 <Dyrcona> Or, I check out the branch and rebase on master. That's why I don't like extraneous commits, i.e. not related to what's being tested.
15:51:57 <csharp_> I've been doing 'git cherry-pick commit1^..commit10', but I'll experiment with Dyrcona's method
15:52:23 <Bmagic> Dyrcona: I could see an issue with that command if the working branch was based on a different working branch? That would bring in more than just the feature you wanted to checkout?
15:52:54 <Dyrcona> Yes, you have to start from the same or similar bases.
15:53:16 <csharp_> ah - then I'll keep doin' what I'm doin' :-)
15:53:36 <Dyrcona> You can also specify another branch: git cherry-pick ^main remote/branch
15:53:48 <Dyrcona> Or a specific commit hash.
15:53:57 <csharp_> git++
15:54:11 <Bmagic> anywho, great work yall! kmlussier is going to galvanize it on the wiki. The rest of the sub-bullets were basically discussed as spawned from the first sub-bullet, go us
15:54:48 <Bmagic> #topic New Business - Scheduling a release discussion - https://doodle.com/meeting/participate/id/av9JXRme - Kathy
15:55:22 <jeffdavis> I do want to say there is value in sharing your work early even before you've had time to clean it up, especially for a huge job like the Angular acq sprint. So like, "here's my working branch, fyi it's not cleaned up/ready for pullrequest yet" is still a good thing to do.
15:55:32 <kmlussier> I extended an offer a while back to help facilitate a discussion around our release process with actions coming out of the discussion. The above link is the scheduling poll.
15:55:40 <Bmagic> jeffdavis++
15:55:44 <csharp_> jeffdavis: I agree
15:56:14 <kmlussier> I wanted to do it before July, but meeting time is limited, especially when working around the other community meetings. If we don't get much participation, I can try to schedule it at another time.
15:56:22 <Bmagic> kmlussier++ # thanks for taking the lead
15:56:54 <kmlussier> If anyone wants to help me prep, let me know. I've already recurited sandbergja.
15:57:22 <Bmagic> sandbergja++
15:57:35 <mmorgan> kmlussier++
15:57:42 <mmorgan> sandbergja++
15:57:44 <shulabear> kmlussier++ sandbergja++
15:57:47 <sandbergja> kmlussier++
15:57:53 <Bmagic> this meeting is working out to exactly an hour, super duper
15:58:08 <Bmagic> #topic Announcements
15:58:15 <Bmagic> #info 3.14 has a roadmap
15:58:19 <Bmagic> #link https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.14
15:58:43 <redavis> Thanks to sleary for that
15:58:46 <dluch> kmlussier++ sandbergja++
15:58:48 <redavis> sleary++
15:58:49 <Bmagic> You heard right! 3.14 already!
15:58:59 <Bmagic> sleary++
15:59:00 <dluch> sleary++
15:59:04 <shulabear> sleary++
15:59:11 <kmlussier> sleary++
15:59:24 <mmorgan> sleary++
15:59:35 <Bmagic> and if you like these:
15:59:38 <Bmagic> #info Next Meeting is Tuesday, June 11th 2024
15:59:44 <csharp_> <sam_gamgee>SHARE THE LOAD</sam_gamgee>
15:59:56 <Bmagic> csharp_++
16:00:10 <Bmagic> #endmeeting