15:01:41 #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 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:41 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 #topic Introductions 15:01:53 Explain yourselves. 15:02:02 #info rhamby = Rogan Hamby, equinoxOLI 15:02:05 #info abowling = Adam Bowling, Emerald Data Networks 15:02:09 #info JBoyer = Jason Boyer, equinoxOLI 15:02:24 #info gmcharlt = Galen Charlton, equinoxOLI. 15:02:28 #info phasefx = Jason Etheridge, equinoxOLI 15:02:32 To explain myself, several billion years ago... 15:02:47 #info miker = Mike Rylander, EOLI, intermittent today 15:02:57 When a proton and an electron cool below a certain temperature... 15:03:16 #info mmorgan = Michele Morgan, NOBLE 15:03:36 #info Dyrcona = Jason Stephenson, CWMARS 15:03:37 when a gluon and a quark spin just right ... 15:03:52 That's amore? 15:03:52 life is strange 15:03:54 (intermittently available, not intermittently me) 15:03:56 #info csharp = Chris Sharp, GPLS 15:04:20 @who is miker, really? 15:04:20 phasefx is miker, really. 15:04:26 miker: schrodinger's mike, you're both here and not until we ping you? 15:04:36 my wave function has collapsed 15:04:40 * phasefx channels his inner miker 15:04:49 phasefx++ 15:05:07 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 #topic Action Items from Last Meeting 15:05:25 #info Dyrcona to start documenting where Dojo and XUL are still required so they can be completely removed. 15:05:39 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 Well, I think there's a lot of work to do to remove Dojo. 15:06:49 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 I don't think there is a Lp bug, yet. 15:08:04 #action JBoyer will file a bug about laying dojo and xul to rest, Viking style 15:09:10 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 Yeah, it may not actually be used in eg2. I just noted that dojo is loaded in a file or two. 15:09:50 Here's hoping. 15:09:52 Does anyone want to take an action to get a collab branch started to strip both of those out? 15:10:39 sure, I'll give it a go. 15:10:40 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 jeff++ 15:10:56 Are we looking at one each for xul and dojo, or combined, or whatever I decide? 15:11:47 I'm OK with whatever you decide, jeff. 15:11:58 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 And I just realized there's no english in the second half of that. 15:13:17 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 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 JBoyer: it might have been a little clunky, but I think you established the point well enough 15:14:07 Yeah, that makes sense, but I'm a bit wary of massive branches. 15:14:36 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 #info berick = Bill Erickson, KCLS 15:15:38 would we be OK with an approach that started off nibbling the problem with a lot of ducks^W small commits 15:16:06 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 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 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 off the top of my head, one central bug linking to a bunch of smaller bugs 15:18:44 That's probably more managable. 15:19:10 In that case jeff, getting started on the xul branch might be the best way to make some headway for now. 15:19:58 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 good ole xulG 15:21:29 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 Would anyone like to see what 15:21:51 sounds good! 15:22:28 the low hanging Dojo fruit may be? Possibly the Bootstrap opac since it's fairly new? 15:22:41 jeff++ 15:22:45 yeah, establishing a firewall there would be good 15:23:47 I think jQ might already be among the dependencies, that would certainly help with replacement. 15:25:38 Perhaps this will become a regular topic so we don't lose track of things. 15:25:56 Any other dojo / xul thoughts before moving on? 15:26:04 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 jeff, Sounds good to me. 15:26:54 Dyrcona++ 15:27:08 Thanks for puting that together 15:27:08 Dyrcona++ 15:27:42 ok 15:27:43 #topic Evergreen Release Updates 15:28:09 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 Launchpad bug 1923225 in Evergreen "ISBN display includes code in traditional catalogue" [Undecided,Confirmed] https://launchpad.net/bugs/1923225 15:30:48 I will tackle that bug, though for the purpose of the release, I do view strictly as a cosmetic bug 15:31:11 certainly not ideal, and definitely needs to be fixed by the time of the regular maintenance releases 15:31:14 but not IMO a 3.7.0-blocker 15:32:32 (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 That certainly sounds good, and would stop this from being a game of highlight whack-a-mole 15:34:23 just want to mention bug 1918362 - it will be a good load/performance improvement, but I *think* not release-critical 15:34:24 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 I can commit it post-release if we don't want to slip it in 15:35:07 By this point in the timeline I'd expect it to be an early 3.7.1 inclusion 15:36:02 (and backports, etc.) 15:36:34 agreed 15:36:47 Hurray for removing unnecessary duplicate calls though. 15:36:58 Any other release updates? 15:37:22 a question: has anybody not-me tested the 3.6.2 to 3.7 schema update? 15:37:58 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 Dyrcona: but succeeded? 15:38:32 Yeah, once that one update was removed. 15:38:36 * phasefx noticed a qatest failure with geosort, will poke at that 15:38:47 which update? 15:39:08 I'm trying to remember. Hang on a sec. You dropped it, IIRC. 15:39:20 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 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 Dyrcona, gmcharlt : The materialized payment by billing type update 15:39:48 Yeah, that's it. 1257 was the number. 15:40:00 @JBoyer probably; maybe a failure to retrieve the dependency 15:40:01 phasefx: git diff origin/hamster Fleshing children complete 15:40:15 oof, I've lost my IRC-fu 15:40:20 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 I may also have a 3.6.2-ish db to test against tonight. 15:42:34 but if not it's just concerto, which I suspect would obviously work. 15:43:12 I think that and the clock takes us to new business. 15:43:20 #topic New Business 15:43:30 #info Our current mailman settings can cause DMARC (dmarc.org) failures 15:43:52 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 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 is list-as-sender and reply-to default to the list an option? 15:45:02 +1 to adjusting Mailman to the current email landscape/reality 15:45:31 gmcharlt, I believe it's an option so long as we don't mind losing the original posters email. 15:46:29 That is the recommended set up these days. 15:46:32 This page has the available options: https://wiki.list.org/DEV/DMARC 15:47:40 Well, looking at that page again I'm not sure there is a From == Reply-To == List option 15:47:55 Munge From was my preferred optoin 15:48:30 hmm, reply-to = list address,sender address appears to be supported by RC5322. not sure about mailman 15:48:58 (to articulate my concern: reply-to=only-sender risks atomizing the discussion) 15:49:13 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 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 and the "reply (not to all)" replies to the sender (via Reply-To). 15:49:44 Unless my mail client is doing something "smart" 15:50:13 well, in that case, if it's not an actual change in effect, I withdraw my concern 15:50:40 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 reply-all goes to list + sender, reply goes to sender only. 15:51:17 ok, I'll coordinate with csharp and send out a heads-up just so everyone knows whats up. 15:51:41 In Thunderbird, Reply goes to the sender, then there's also a Reply to list option. 15:51:49 (I say csharp, but whoever can make that change is fine with me, I just know it's not me.) 15:52:09 I have seen the occasional case where someone's address book had gotten populated with "John Smith via list-name " 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 JBoyer: we *might* have access to that box, too 15:52:44 Possibly, it's PINES 15:52:45 but sign-off/involvement of csharp will be requisite, nonetheless 15:53:07 Who may already be out for the afternoon, so I'll just work with him directly. 15:53:08 I have access as well 15:53:40 Ah, been a while since the stupidest keyboard shortcut in all of editing has bitten me. 15:53:41 leaving your own meeting is sort of a d move 15:53:48 but yeah, should be done with at least csharp's ackowledge foreknowlege 15:53:50 "And like that – poof – he's gone!" 15:53:57 gmcharlt++ 15:54:07 "Email's fixed!" - Mic drop. 15:54:16 abowling++ gmcharlt++ 15:54:16 :) 15:54:53 #action JBoyer will work with csharp to update mailman settings and make an announcement to the lists ahead of time. 15:55:08 that, or total baller 15:56:08 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 might also be overkill 15:56:48 that would remove the easy ability for a user to reply not-to-all. 15:57:10 Mmm, true. And we do seem to have decent traffic as-is. 15:57:17 Huzzah! I'm already done. 15:57:34 (and is the general case of "reply-to munging considered harmful") 15:58:17 with DMARC/DKIM it's more "reply-to munging an unfortunate but mostly-tolerable necessity" :-P 15:58:34 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 JBoyer++ 15:59:05 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 JBoyer++ 15:59:15 #topic Announcements 15:59:18 * csharp appears, reads scrollback frantically 15:59:20 #info Next meeting is May 11, 2021 15:59:29 YOU GOT SO MANY ACTIONS 15:59:38 #endmeeting