15:00:02 <Bmagic> #startmeeting 2024-01-09 - Developer Meeting
15:00:02 <pinesol> Meeting started Tue Jan  9 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_01_09___developer_meeting'
15:00:11 <Bmagic> #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2024-01-09
15:00:17 <Bmagic> #topic Introductions
15:00:20 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:00:22 <Dyrcona> #info Dyrcona = Jason Stephenson, C/W MARS
15:00:32 <shulabear> #info shulabear = Shula Link, GCHRL in PINES
15:00:32 <Bmagic> feel free to introduce yourselves
15:00:52 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:00:54 <Stompro> #info Stompro = Josh Stompro, LARL & NWRL
15:00:54 <GalenCharlton> GalenCharlton = Galen Charlton, Equinox
15:01:15 <sleary> #info sleary = Stephanie Leary, Equinox
15:01:15 <berick> #info berick Bill Erickson, KCLS
15:01:31 <Bmagic> This is probably going to be a short meeting
15:01:34 <terranm> #info terranm = Terran McCanna, PINES
15:02:05 <Bmagic> #topic Action Items from Last Meeting
15:02:09 <Dyrcona> We could talk about releases some more.
15:02:20 <Bmagic> #info mmorgan will explore moving LP stats to community site and automating same
15:02:30 <JBoyer> #info JBoyer = Jason Boyer, EOLI
15:02:44 <eeevil> #info eeevil = Mike Rylander, EOLI
15:02:58 <sandbergja> #info sandbergja = Jane Sandberg, PUL and independent
15:03:00 <mmorgan> No significant updates yet.
15:03:07 * mmorgan is looking at some Launchpad API scripts that Dyrcona shared.
15:03:10 <Bmagic> ok, no prob
15:03:12 <abneiman> #info abneiman = Andrea Buntz Neiman, Equinox
15:03:20 <mmorgan> Dyrcona++
15:03:44 <Bmagic> #action mmorgan will explore moving LP stats to community site and automating same
15:03:50 <Bmagic> #info sandbergja will see if gh actions can run the pgtap tests
15:04:04 <sandbergja> no progress on pgtap in github actions
15:04:16 <Bmagic> #action sandbergja will see if gh actions can run the pgtap tests
15:04:22 <Bmagic> #info Dyrcona will summarize release coordination discussion and followup on the development mailing list.
15:04:24 <Dyrcona> #info Done!
15:04:35 <Bmagic> suhweet
15:04:40 <collum> #info collum = Garry Collum, KCPL
15:04:47 <Bmagic> anyone have anything for OpenSRF?
15:05:07 <Bmagic> or Evergreen or Hatch?
15:05:16 <GalenCharlton> I do
15:05:30 <Bmagic> which?
15:05:49 <GalenCharlton> re OpenSRF, I've identified some bugfixes and minor enhancements that I intend to cut 3.3.x (maybe a final 3.2.x) release for
15:05:53 <Bmagic> #topic OpenSRF
15:06:40 <GalenCharlton> I will also be putting RediSRF through some more paces (read: throw all the kitchen sinks at it) in preparation for cutting 4.0-alpha or beta in the next few weeks
15:07:09 <berick> GalenCharlton++
15:07:17 <GalenCharlton> but upshot: if anybody has any favorite bugfixes for the XMPP OpenSRF, please call them out to me
15:07:25 <Bmagic> GalenCharlton: thanks!
15:07:39 <GalenCharlton> there is also one new bug for OpenSRF that I want to call out for feedback
15:07:45 <Bmagic> GalenCharlton: typing your nick is, eh, different feeling
15:08:08 <GalenCharlton> (yeah, I need to re-set-up Quassel for myself)
15:08:22 <GalenCharlton> namely, https://bugs.launchpad.net/opensrf/+bug/2047707 - track browser and tab for staff interface logging
15:08:22 <pinesol> Launchpad bug 2047707 in OpenSRF "track browser and tab for staff interface logging" [Wishlist,New]
15:08:57 <GalenCharlton> upshot of that one: will help us deal with runaway pcrud explosions and general load monitoring
15:09:26 <Bmagic> interesting!
15:10:25 <Bmagic> I have a VM setup to test the redis branch(es), I really need to get back to that
15:10:27 <eeevil> GalenCharlton: since the agenda is otherwise thin, I have a question about that!
15:10:50 <GalenCharlton> eeevil: go for it
15:11:40 <eeevil> do you imagine being able to make it a hard client requirement (think: soft API key) or just (for now) some extra info a client /should/ pass so we can know who's who?
15:12:36 <GalenCharlton> I was thinking soft to start (especially since I don't really want to require it for any AJAX that the OPAC might do)
15:13:41 <GalenCharlton> but it doesn't seem like it would be difficult to mandate it for staff-side methods if we wish (via a flag on the method signature, presumably)
15:14:04 <eeevil> get outta my head! ;)
15:14:49 <eeevil> I was thinking about something along those lines, yes. down the road.
15:15:35 <Bmagic> There's a bug somewhere having to do with closing the tab, causing the pcrud wall-o-requests
15:15:40 <GalenCharlton> ayup
15:16:42 <GalenCharlton> and while I _also_ have some thoughts on ameliorating that from the Angular and AngularJS code, the ability to detect that a specific browser is spamming requests and doing a block (or even just a forced WS connection reset) would be very useful
15:17:00 <Bmagic> coolio! Anyone here want to chime in on testing redis and/or adding comments on the tab-tracking proposal bug
15:18:19 <Bmagic> I suppose we can move on now
15:18:26 <Bmagic> #topic Documentation
15:18:48 <Bmagic> dluch won't make it today. abneiman, any update?
15:19:31 <abneiman> #info DIG met last week and discussed plans for 2024, including documenting things from 3.12 that are needed
15:19:52 <Bmagic> abneiman++
15:19:59 <abneiman> #info We are also working with an intern who is reviewing Evergreen Indiana documentation & revising it for inclusion in main
15:20:32 <terranm> abneiman++
15:20:45 <abneiman> #info and this bug from sandbergja could use a little love & would make some DIGgers very happy lp1930099
15:20:58 <abneiman> er bug 1930099
15:20:58 <pinesol> Launchpad bug 1930099 in Evergreen "generate_docs.pl should be able to run on Windows" [Medium,Confirmed] https://launchpad.net/bugs/1930099
15:21:02 <abneiman> there we go
15:21:18 <abneiman> thus concludes my off the cuff DIG update
15:21:26 <Bmagic> oh yeah! I'm interested in that one too. I considered some code to make that work a couple of years ago when she reported that bug
15:21:37 <Bmagic> #info Next DIG Meeting: Thursday, February 1
15:21:42 <abneiman> Jane posted a recent branch for review
15:21:44 <abneiman> sandbergja++
15:21:50 <Bmagic> sandbergja++
15:22:23 <sandbergja> happy to zoom with anybody on a windows box who wants to give it a try, btw
15:22:50 <mmorgan> GalenCharlton++ abneiman++ sandbergja++
15:22:54 <Bmagic> sandbergja: sweet!
15:22:58 <Bmagic> incoming paste bomb
15:23:06 <Bmagic> #topic Launchpad Status (as of noon Eastern)
15:23:11 <Bmagic> #info Open Bugs - 3076
15:23:11 <Bmagic> #info Pullrequests - 95
15:23:11 <Bmagic> #info Signedoff - 5
15:23:14 <Bmagic> #topic Launchpad Status since last meeting
15:23:18 <Bmagic> #info Bugs Added - 58
15:23:19 <Bmagic> #info Pullrequest tag Added - 29
15:23:19 <Bmagic> #info Signedoff tag Added - 10
15:23:19 <Bmagic> #info Fix Committed - 14
15:23:39 <Bmagic> #topic New Business - The Voluntary Product Accessibility Template / Accessibility Conformance Report on the OPAC is available, and new Launchpad bugs have been filed for all the issues noted in the report
15:23:51 <Bmagic> #link https://wiki.evergreen-ils.org/doku.php?id=accessibility:vpat
15:24:02 <sleary> some of those are pretty bite-sized, if anyone wants to tackle them
15:24:23 <sleary> I've linked to the accessibility dev guide where I could
15:25:33 <sleary> I was working from VERY terse comments from the report, so let me know if I have not totally fleshed out the explanation of the problems or recommended solutions
15:26:11 <Bmagic> sleary++
15:26:18 <sandbergja> sleary++
15:26:24 <mmorgan> sleary++
15:26:34 <abneiman> sleary++
15:27:02 <shulabear> sleary++
15:27:09 <Bmagic> Dyrcona: you mentioned at the beginning that you might want to open a discussion?
15:27:12 <terranm> sleary++
15:27:24 <Bmagic> #topic talk about releases some more
15:28:21 <GalenCharlton> if folks are amenable, I would also like to discuss my release note proposal here
15:28:38 <Bmagic> plenty of time! Go for it
15:29:31 <GalenCharlton> so, as I mentioned, I would like to propose that, for the cases where a fix can be adequately described by a one-liner, to include those in commit messages with a structured tag such as Release-note
15:30:00 <GalenCharlton> idea is that they can be gathered up by the script that starts the initial notes for each release
15:30:30 <GalenCharlton> and save time (including, I must say, time spent dealing with merge conflicts on miscellaneous.adoc - they're trivial, but do add up)
15:30:48 <GalenCharlton> for anything that is bigger, docs/RELEASE_NOTES_NEXT should still be sed
15:30:57 <Dyrcona> :) I was about to mention miscellaneous.adoc....
15:31:16 <GalenCharlton> main advantages I see: patch authors have to write _something_ in a commit message anyway
15:31:32 <Dyrcona> I think this should apply to bug fixes only. New features require  actual release notes.
15:31:38 <GalenCharlton> and patch reviewers (and especially committers) have plenty of opportunity to tweak wording
15:32:21 <GalenCharlton> so since folks are _right there_, hopefully this can be maintainable
15:32:41 <GalenCharlton> (and personally, I'm happy to commit as a comitter, as it were, to providing them for any patches that I review or merge)
15:33:01 <abneiman> commit as a committer to commit commit messages...
15:33:15 <GalenCharlton> abneiman++
15:33:16 <eeevil> +1, and also +1 to a commit message template that sets stuff up how we want them to look at pick-to-main time
15:33:18 <Bmagic> I'm all for using "Release-note" - an easy enough thing to start with. And it's not required, or sometimes doesn't make sense, depending. Omitting is is still fine. But having the general etiquette is nice
15:33:31 <abneiman> in all seriousness I am +1(0000) to GalenCharlton 's proposal with Dyrcona 's caveat of "actual features need actual release notes"
15:33:39 <Dyrcona> I'm OK with this for bug fixes. There was some discussion of adding a commit message template to the repository. is that still being floated?
15:34:04 <sandbergja> how would the commit tag work if a bug fix includes multiple commits?
15:34:15 <Stompro> +1 - seems like a nice time saver.
15:34:24 <GalenCharlton> as far as bug fixes only vs new features - I think it will work out that way in practice. I think a "literally must fit in a single line" should cover it, but if a new feature is truly tiny enough, no need to belabor it
15:34:38 <eeevil> sandbergja: the "main"-est commit would carry the tag, I think
15:34:58 <GalenCharlton> well, any commit in the series should do
15:35:56 <GalenCharlton> I think the scripting that grabs these tags doesn't need to care whether its the first or last patch in a series; just (eventually) complain if _none_ of the patches for a given bug have an entry
15:36:05 <eeevil> but, again, in practice if it's that small of a fix needing only 1 line, it probably should be 1 commit
15:36:27 <sandbergja> makes sense
15:36:47 <Bmagic> GalenCharlton++ gmcharlt++
15:36:48 <GalenCharlton> (and also, this is just to _start_ the release notes; there would still be human review)
15:36:58 <eeevil> +1
15:37:02 <GalenCharlton> Dyrcona: re commit message templates - yes, I think we should do that
15:37:33 <GalenCharlton> (and thanks to Josh Stompro for the suggestion!)
15:38:09 <Bmagic> we really do need something* to get these release notes wrangled for streamlining the releases. This is a great step forward
15:38:22 <shulabear> +1
15:38:22 <sandbergja> FWIW: at PUL, we maintain a gitmessage, and it includes all of our teams and frequent collaborators: https://github.com/pulibrary/pul-it-handbook/blob/main/gitmessage.md
15:38:53 <GalenCharlton> sandbergja++
15:39:00 <Bmagic> GalenCharlton: would you like an action item for writing/committing the git voodoo to generate said release note file?
15:39:08 <sandbergja> so adding somebody to a commit is just a case of uncommenting a line in the gitmessage.  I could picture something like that for Signedoff-by lines
15:39:14 <GalenCharlton> (though I will take this moment to shake my fist at the only-50-characters for the first line convention)
15:39:40 <Dyrcona> Well, we don't always follow that convention anyway.
15:39:46 <GalenCharlton> well, git commit --amend -s I think handles the signed-off lines better
15:39:59 <GalenCharlton> Bmagic: I'll take two action items, actually
15:40:06 <Bmagic> There's a convention? (lol)
15:40:18 <GalenCharlton> first, open an LP bug and propose a git commit message template there
15:40:18 <Dyrcona> sandbergja++ Nice gitmessage.
15:40:47 <GalenCharlton> second: update the release note script to look for the release-note tags
15:41:05 <Bmagic> #action GalenCharlton will open LP bug with the official proposal for git commit message release-note
15:41:05 <GalenCharlton> actually, let's see
15:41:23 <GalenCharlton> also a third: write up the release-notes convention for the dev wiki somehwere
15:41:52 <Bmagic> #action GalenCharlton update the release note script to look for the release-note tags
15:42:08 <Bmagic> #action GalenCharlton write up the release-notes convention for the dev wiki somehwere
15:42:14 <Bmagic> how's that?
15:42:57 <Dyrcona> Well, thats a lot to throw at 1 person.
15:43:32 <Bmagic> you want to grab one or two?
15:43:51 <Bmagic> anyone else for that matter?
15:44:19 <Stompro> I can write something up for the wiki.
15:44:28 <Bmagic> Stompro++
15:44:36 <shulabear> stompro++
15:44:40 <Bmagic> I don't know if the meetingbot can delete action items
15:45:04 <Bmagic> but I'll make a repeat for Stompro, and we'll all just have to remember that Josh stole it
15:45:26 <Dyrcona> We can delete strike them in the agenda of the next meeting or edit them.
15:45:27 <GalenCharlton> @   action GalenCharlton will forget about the wiki... ;)
15:45:27 <pinesol> GalenCharlton: WORKSFORME WONTFIX
15:45:37 <terranm> lol
15:46:02 <Bmagic> #action Stompro write up the release-notes convention for the dev wiki somehwere (stolen action from GalenCharlton)
15:46:02 <shulabear> lol
15:47:28 <JBoyer> On the commit template topic I had hoped there was a way to make it "automagical" as part of the repo but that hope has been dashed because it's explicitly not supported. It can be included, but actually turning it on will always be a manual process (once).
15:48:09 <Bmagic> There's another 11 minutes and change. I feel like we left Dyrcona dry. Dyrcona: would you like to comment on the release work R&D you've been doing?
15:48:32 <JBoyer> not supported as in it's considered a security issue, so there goes my hope of building in a bunch of fancy git hooks to make sure things like template usage and lint passing and so on too. :)
15:48:42 <GalenCharlton> curl https://evergreen-ils.org/set-up-clone.sh | bash
15:48:47 * GalenCharlton runs away
15:49:08 <shulabear> lol
15:49:24 <Bmagic> ::starts seeing nicks getting mysteriously logged off::
15:49:33 <Dyrcona> JBoyer: We can commit a .gitmessage, but the user has to configure it to be used locally.
15:50:33 <Dyrcona> Bmagic: I'm not doing much R&D. I just have a couple of scripts to simplify setting up a git branch for a custom release with DB upgrade. I think in the long run we should make-release up into smaller scripts that as a whole are more flexible to use.
15:51:21 <Bmagic> dividing and conquering sounds feasible to me
15:51:30 <Bmagic> ansible is a thing
15:51:37 <Dyrcona> i dropped a verb in that second sentence: We should split it up. I've not actually started on that.
15:52:12 <Dyrcona> Ansible is a thing, but I don't know if that should be the standard way to install Evergreen.
15:52:15 <sandbergja> JBoyer: there are also packages like this -- https://github.com/toplenboren/simple-git-hooks -- which does what you described as long as you have run `npm install`
15:52:32 <JBoyer> re: ansible = standard: 100% not.
15:52:39 <Bmagic> I was thinking more like ansible driving the make-release stuffs
15:53:17 <JBoyer> sandbergja, I saw reference to that, but that's a flavor of magic I don't much like either.
15:53:35 <Dyrcona> Well, make-release just builds a tarball, and if you do autotools "correctly" it should be as simple as typing "make release."
15:54:14 <Dyrcona> Well, make-release does more than "just build a tarball."
15:54:33 <Bmagic> I think what we have now is pretty good, just throwing out ideas
15:54:52 <Bmagic> 5 minutes left, anyone want to add?
15:54:59 <Dyrcona> yeah, I hesitate to add ansible to the packager requirements.
15:56:26 <Bmagic> #topic Announcements
15:56:31 <Bmagic> #info Next Meeting is Tuesday, February 13th
15:56:38 <Bmagic> #endmeeting