15:01:41 <JBoyer> #startmeeting 2021-04-13 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-04-13
15:01:41 <pinesol> Meeting started Tue Apr 13 15:01:41 2021 US/Eastern.  The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:41 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:41 <pinesol> The meeting name has been set to '2021_04_13___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2021_04_13'
15:01:48 <JBoyer> #topic Introductions
15:01:53 <JBoyer> Explain yourselves.
15:02:02 <rhamby> #info rhamby = Rogan Hamby,  equinoxOLI
15:02:05 <abowling> #info abowling = Adam Bowling, Emerald Data Networks
15:02:09 <JBoyer> #info JBoyer = Jason Boyer, equinoxOLI
15:02:24 <gmcharlt> #info gmcharlt = Galen Charlton, equinoxOLI.
15:02:28 <phasefx> #info phasefx = Jason Etheridge, equinoxOLI
15:02:32 <gmcharlt> To explain myself, several billion years ago...
15:02:47 <miker> #info miker = Mike Rylander, EOLI, intermittent today
15:02:57 <JBoyer> When a proton and an electron cool below a certain temperature...
15:03:16 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:03:36 <Dyrcona> #info Dyrcona = Jason Stephenson, CWMARS
15:03:37 <rhamby> when a gluon and a quark spin just right ...
15:03:52 <JBoyer> That's amore?
15:03:52 <phasefx> life is strange
15:03:54 <miker> (intermittently available, not intermittently me)
15:03:56 <csharp> #info csharp = Chris Sharp, GPLS
15:04:20 <csharp> @who is miker, really?
15:04:20 <pinesol> phasefx is miker, really.
15:04:26 <rhamby> miker: schrodinger's mike, you're both here and not until we ping you?
15:04:36 <miker> my wave function has collapsed
15:04:40 * phasefx channels his inner miker
15:04:49 <csharp> phasefx++
15:05:07 <JBoyer> ok, as people continue to arrive they can info in, and apparently treat us to a quantum mechanical quotable, if that's the way the wave collapses.
15:05:13 <JBoyer> #topic Action Items from Last Meeting
15:05:25 <JBoyer> #info Dyrcona to start documenting where Dojo and XUL are still required so they can be completely removed.
15:05:39 <JBoyer> I took a look at the doc and I'm hoping some chunks of that just need a cursory glance before being discarded because they've been reimplemented in Angular(/JS).
15:06:34 <Dyrcona> Well, I think there's a lot of work to do to remove Dojo.
15:06:49 <JBoyer> And I was also searching for an LP bug to drop it in but either I've been launched pad, or we don't have one yet. (Not the same as removing dojo from the opac for replacement with jQ)
15:07:20 <Dyrcona> I don't think there is a Lp bug, yet.
15:08:04 <JBoyer> #action JBoyer will file a bug about laying dojo and xul to rest, Viking style
15:09:10 <JBoyer> But seeing your mention of it in some eg2 bits does imply that it will be a little more sleuthing than I was initially hoping
15:09:39 <Dyrcona> Yeah, it may not actually be used in eg2. I just noted that dojo is loaded in a file or two.
15:09:50 <JBoyer> Here's hoping.
15:09:52 <JBoyer> Does anyone want to take an action to get a collab branch started to strip both of those out?
15:10:39 <jeff> sure, I'll give it a go.
15:10:40 <JBoyer> I'm hopeful the xul cleanup will largely be removing one half of a conditional but I have many irrational and unrealistic desires.
15:10:47 <JBoyer> jeff++
15:10:56 <jeff> Are we looking at one each for xul and dojo, or combined, or whatever I decide?
15:11:47 <Dyrcona> I'm OK with whatever you decide, jeff.
15:11:58 <JBoyer> I think it may touch enough stuff that having 2 separate branches will cause more trouble merging / testing than it would save by having 2 slightly more focused branches.
15:12:56 <JBoyer> And I just realized there's no english in the second half of that.
15:13:17 <Dyrcona> Some features are going to require implementation in a different toolkit or be removed, so that could warrant multiple bugs/branches, but IDK.
15:13:32 <JBoyer> I think merge conflicts and a general difficulty in getting branches tested means that 1 might be easier for all involved, is what I was trying to say.
15:13:48 <abowling> JBoyer: it might have been a little clunky, but I think you established the point well enough
15:14:07 <Dyrcona> Yeah, that makes sense, but I'm a bit wary of massive branches.
15:14:36 <JBoyer> Dyrcona, I can see there being a separate branch for removing dojo (and xul) from this or that major section, but I don't think we should have this collection of branches to remove dojo and that collection to remove xul, for instance.
15:15:10 <berick> #info berick = Bill Erickson, KCLS
15:15:38 <gmcharlt> would we be OK with an approach that started off nibbling the problem with a lot of ducks^W small commits
15:16:06 <Dyrcona> What I'm trying to say is that it isn't just removing Dojo. Whole subsystmes, like Ovedrive integration, need to be implemented over again.
15:17:46 <JBoyer> Given my experience with the autocomplete branch that didn't get updated for 3.7 I'd be fine with small bites, yeah. Where you thinking small commits on jeff's collab branch or keeping track of a lot of small-ish branches in a single bug, or something else entirely gmcharlt ?
15:18:07 <jeff> I think the XUL removal may be easier than the Dojo removal, and could be its own branch, but we shall see! I think (and Dyrcona's research appears to confirm!) that Dojo is more... intertwined.
15:18:18 <gmcharlt> off the top of my head, one central bug linking to a bunch of smaller bugs
15:18:44 <JBoyer> That's probably more managable.
15:19:10 <JBoyer> In that case jeff, getting started on the xul branch might be the best way to make some headway for now.
15:19:58 <JBoyer> Though I suspect there may be a place here or there that stuck a fake XUL object in the dom for simplicity, I have to think that was rare.
15:20:58 <phasefx> good ole xulG
15:21:29 <JBoyer> I can try to put together a small collection of bugs based on Dyrcona's doc, though I'm certain we'll have more to add later.
15:21:47 <JBoyer> Would anyone like to see what
15:21:51 <jeff> sounds good!
15:22:28 <JBoyer> the low hanging Dojo fruit may be? Possibly the Bootstrap opac since it's fairly new?
15:22:41 <JBoyer> jeff++
15:22:45 <gmcharlt> yeah, establishing a firewall there would be good
15:23:47 <JBoyer> I think jQ might already be among the dependencies, that would certainly help with replacement.
15:25:38 <JBoyer> Perhaps this will become a regular topic so we don't lose track of things.
15:25:56 <JBoyer> Any other dojo / xul thoughts before moving on?
15:26:04 <jeff> I can create a pair of bugs for Dojo and XUL removal, and start a XUL removal collab branch, and if JBoyer wants to start some Dojo removal bugs tied to the main Dojo removal bug using Dyrcona's doc/research, is that a good start?
15:26:49 <JBoyer> jeff, Sounds good to me.
15:26:54 <JBoyer> Dyrcona++
15:27:08 <JBoyer> Thanks for puting that together
15:27:08 <jeff> Dyrcona++
15:27:42 <JBoyer> ok
15:27:43 <JBoyer> #topic Evergreen Release Updates
15:28:09 <JBoyer> I know the plan is that 3.7.0 drops tomorrow, but I'm also seeing concerns in the scrollback, how do things look?
15:30:09 * mmorgan has concerns about bug 1923225
15:30:10 <pinesol> Launchpad bug 1923225 in Evergreen "ISBN display includes code in traditional catalogue" [Undecided,Confirmed] https://launchpad.net/bugs/1923225
15:30:48 <gmcharlt> I will tackle that bug, though for the purpose of the release, I do view strictly as a cosmetic bug
15:31:11 <gmcharlt> certainly not ideal, and definitely needs to be fixed by the time of the regular maintenance releases
15:31:14 <gmcharlt> but not IMO a 3.7.0-blocker
15:32:32 <gmcharlt> (long run: I do strongly feel that the search API should move away from embedding HTML in its output in favor of returning a data structure that the TT templates can use to put together the markup for highlights)
15:33:58 <JBoyer> That certainly sounds good, and would stop this from being a game of highlight whack-a-mole
15:34:23 <jeffdavis> just want to mention bug 1918362 - it will be a good load/performance improvement, but I *think* not release-critical
15:34:24 <pinesol> Launchpad bug 1918362 in Evergreen 3.6 "Unchanged workstation settings are re-applied on every checkin" [Medium,Confirmed] https://launchpad.net/bugs/1918362
15:35:01 <jeffdavis> I can commit it post-release if we don't want to slip it in
15:35:07 <JBoyer> By this point in the timeline I'd expect it to be an early 3.7.1 inclusion
15:36:02 <JBoyer> (and backports, etc.)
15:36:34 <gmcharlt> agreed
15:36:47 <JBoyer> Hurray for removing unnecessary duplicate calls though.
15:36:58 <JBoyer> Any other release updates?
15:37:22 <gmcharlt> a question: has anybody not-me tested the 3.6.2 to 3.7 schema update?
15:37:58 <Dyrcona> gmcharlt: No, I haven't, but I have tried a 3.2.10 to 3.7 schema upgrade. It takes a long time. :)
15:38:17 <gmcharlt> Dyrcona: but succeeded?
15:38:32 <Dyrcona> Yeah, once that one update was removed.
15:38:36 * phasefx noticed a qatest failure with geosort, will poke at that
15:38:47 <gmcharlt> which update?
15:39:08 <Dyrcona> I'm trying to remember. Hang on a sec. You dropped it, IIRC.
15:39:20 <JBoyer> phasefx, I'm wondering if its a timeout or something weird about the environment, I ran some local tests and it was fine.
15:39:34 <jeffdavis> gmcharlt: I've done 3.6.2-3.7 beta minus a couple big updates on real data, haven't tried the RC.
15:39:35 <JBoyer> Dyrcona, gmcharlt : The materialized payment by billing type update
15:39:48 <Dyrcona> Yeah, that's it. 1257 was the number.
15:40:00 <phasefx> @JBoyer probably; maybe a failure to retrieve the dependency
15:40:01 <pinesol> phasefx: git diff origin/hamster Fleshing children complete
15:40:15 <phasefx> oof, I've lost my IRC-fu
15:40:20 <gmcharlt> Dyrcona: jeffdavis: thanks. That's making me confident enough that SELECT randomize_marc_tags(); isn't part of the schema update
15:41:05 * JBoyer cackles, "I have spelled it auditor.update_auditors(); Ha!"
15:42:18 <JBoyer> I may also have a 3.6.2-ish db to test against tonight.
15:42:34 <JBoyer> but if not it's just concerto, which I suspect would obviously work.
15:43:12 <JBoyer> I think that and the clock takes us to new business.
15:43:20 <JBoyer> #topic New Business
15:43:30 <JBoyer> #info Our current mailman settings can cause DMARC (dmarc.org) failures
15:43:52 <JBoyer> Taking the temp of the room here, since I'd like to change our settings to set the list itself as the From: address and move the original sender to Reply-To to help with both SPF and DKIM (we could add DKIM to the outgoing messages in that case to also help things look good to email providers but that's a separate thing)
15:44:47 <JBoyer> This came up because a library had asked me why they got a DMARC quarantine report for a post made to one of the evergreen lists.
15:44:59 <gmcharlt> is list-as-sender and reply-to default to the list an option?
15:45:02 <jeff> +1 to adjusting Mailman to the current email landscape/reality
15:45:31 <JBoyer> gmcharlt, I believe it's an option so long as we don't mind losing the original posters email.
15:46:29 <Dyrcona> That is the recommended set up these days.
15:46:32 <JBoyer> This page has the available options: https://wiki.list.org/DEV/DMARC
15:47:40 <JBoyer> Well, looking at that page again I'm not sure there is a From == Reply-To == List option
15:47:55 <JBoyer> Munge From was my preferred optoin
15:48:30 <gmcharlt> hmm, reply-to = list address,sender address appears to be supported by RC5322. not sure about mailman
15:48:58 <gmcharlt> (to articulate my concern: reply-to=only-sender risks atomizing the discussion)
15:49:13 <jeff> generally the "reply all" option in your MUA replies to the sender (via Reply-To) and the list (as an address in the To that isn't seen by your MUA as "you").
15:49:23 <JBoyer> And having just checked that's the same way it works today, unless I reply-all it only goes to the poster.
15:49:35 <jeff> and the "reply (not to all)" replies to the sender (via Reply-To).
15:49:44 <JBoyer> Unless my mail client is doing something "smart"
15:50:13 <gmcharlt> well, in that case, if it's not an actual change in effect, I withdraw my concern
15:50:40 <jeff> in the MUA in front of me (Gmail), the behavior is identical between a current-config Evergreen list and another list that does the Fron-munge + Reply-To for original sender.
15:50:55 <jeff> reply-all goes to list + sender, reply goes to sender only.
15:51:17 <JBoyer> ok, I'll coordinate with csharp and send out a heads-up just so everyone knows whats up.
15:51:41 <Dyrcona> In Thunderbird, Reply goes to the sender, then there's also a Reply to list option.
15:51:49 <JBoyer> (I say csharp, but whoever can make that change is fine with me, I just know it's not me.)
15:52:09 <jeff> I have seen the occasional case where someone's address book had gotten populated with "John Smith via list-name <list@example.org>" and they compose a message to "John Smith" and end up sending it to the list, but I'm not sure which MUA is the frequent offender there.
15:52:14 <abowling> JBoyer: we *might* have access to that box, too
15:52:44 <JBoyer> Possibly, it's PINES
15:52:45 <abowling> but sign-off/involvement of csharp will be requisite, nonetheless
15:53:07 <JBoyer> Who may already be out for the afternoon, so I'll just work with him directly.
15:53:08 <gmcharlt> I have access as well
15:53:40 <JBoyer> Ah, been a while since the stupidest keyboard shortcut in all of editing has bitten me.
15:53:41 <abowling> leaving your own meeting is sort of a d move
15:53:48 <gmcharlt> but yeah, should be done with at least csharp's ackowledge foreknowlege
15:53:50 <jeff> "And like that – poof – he's gone!"
15:53:57 <abowling> gmcharlt++
15:54:07 <JBoyer> "Email's fixed!" - Mic drop.
15:54:16 <JBoyer> abowling++ gmcharlt++
15:54:16 <Dyrcona> :)
15:54:53 <JBoyer> #action JBoyer will work with csharp to update mailman settings and make an announcement to the lists ahead of time.
15:55:08 <abowling> that, or total baller
15:56:08 <JBoyer> And I may see if there's a simple way to get both addresses in Reply-To, but I suspect that might take some template editing or something (if that's even possible, I really don't know.)
15:56:24 <gmcharlt> might also be overkill
15:56:48 <jeff> that would remove the easy ability for a user to reply not-to-all.
15:57:10 <JBoyer> Mmm, true. And we do seem to have decent traffic as-is.
15:57:17 <JBoyer> Huzzah! I'm already done.
15:57:34 <jeff> (and is the general case of "reply-to munging considered harmful")
15:58:17 <jeff> with DMARC/DKIM it's more "reply-to munging an unfortunate but mostly-tolerable necessity" :-P
15:58:34 <JBoyer> Since I don't see that anyone has sneakily added to the agenda since I typed up my script or bailed on my own meeting, if there's nothing left I'll throw out the next meeting and we can call it a day.
15:59:03 <Dyrcona> JBoyer++
15:59:05 <JBoyer> jeff, yeah, I wondered if one possibility was just spreading more DKIM around, but not if we modify Subject:, so here we are. :)
15:59:09 <abowling> JBoyer++
15:59:15 <JBoyer> #topic Announcements
15:59:18 * csharp appears, reads scrollback frantically
15:59:20 <JBoyer> #info Next meeting is May 11, 2021
15:59:29 <JBoyer> YOU GOT SO MANY ACTIONS
15:59:38 <JBoyer> #endmeeting