15:03:57 <JBoyer> #startmeeting 2021-12-14 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2021-12-14
15:03:57 <pinesol> Meeting started Tue Dec 14 15:03:57 2021 US/Eastern.  The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:03:57 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:03:57 <pinesol> The meeting name has been set to '2021_12_14___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2021_12_14'
15:04:04 <JBoyer> #topic Introductions
15:04:10 <abowling> #info Adam Bowling, Emerald Data Networks
15:04:15 <JBoyer> Hi! Who are you?
15:04:28 <JBoyer> #info JBoyer = Jason Boyer, EOLI
15:04:32 <shulabear> #info Shula Link, Greater Clarks Hill Regional in PINES
15:04:32 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
15:04:36 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:04:42 <berick> #info berick Bill Erickson, KCLS
15:04:47 <abowling> #info abowling = Adam Bowling, Emerald Data Networks
15:04:47 <alynn26> #info alynn26 is Lynn Floyd, Evergreen Indiana
15:04:51 <phasefx_> #info phasefx = Jason Etheridge, EOLI
15:04:55 <abowling> forgot who i was for a second
15:04:58 <rhamby> #info rhamby = Rogan Hamby, EOLLI
15:05:02 <shulabear> #info shulabear = Shula Link, Greater Clarks Hill Regional in PINES
15:05:15 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka)
15:05:16 <miker> #info miker = Mike Rylander, eoli
15:05:36 <JBoyer> You also type too fast for my jokes abowling. :p
15:05:44 <Dyrcona> #info Dyrcona = Jason Stephenson, CW MARS
15:06:10 <abowling> sorry, jboyer. i'll turn the speed knob down.
15:06:22 <sandbergja> #info sandbergja = Jane Sandberg, Linn-Benton Community College
15:06:28 <csharp_> #info csharp_ = Chris Sharp, GPLS
15:06:29 <JBoyer> Just need to sharpen my wit.
15:07:00 <abowling> if you figure out the secret, let me in on it
15:07:13 <abneiman> #info abneiman = Andrea Buntz Neiman, Equinox
15:07:32 <Dyrcona> Mechanical wit, but then it runs out and you have to buy more. Plus it leaves bits all around.
15:07:32 <JBoyer> Ok, people should feel free to #info up as they continue to join.
15:07:42 <JBoyer> #topic Action Items from Last Meeting
15:08:07 <JBoyer> #info JBoyer will test out the branch in lp 1947595
15:08:07 <pinesol> JBoyer: Error: Could not gather data from Launchpad for bug #1947595 (https://launchpad.net/bugs/1947595). The error has been logged
15:08:26 <JBoyer> I'm as surprised as you all may be, but that did happen and the branch was even signed off on because it does the thing. Dyrcona ++
15:08:50 <Dyrcona> JBoyer++
15:09:11 <JBoyer> So it should be a sound base for the rest of the Pg14 stuff that we'll get to later.
15:09:20 <JBoyer> Next up is
15:09:21 <JBoyer> #topic OpenSRF Release Updates
15:09:39 <JBoyer> With this spicy Q
15:09:44 <JBoyer> #topic Is it time for OpenSRF 3.3.0?
15:10:16 <Dyrcona> Well, I added the question because it came up in channel that with the Python removal or something, it was not possible to install everything from a tarball.
15:10:34 <JBoyer> Oh, on Bullseye?
15:10:43 <Dyrcona> Yeah, something like that.
15:11:25 <Dyrcona> I figure we should either backport the Python removal or roll a 3.3.0 release and recommend that going forward, at least for newer distros.
15:11:28 <JBoyer> I forgot the excise python branch wasn't already in a release.
15:11:57 <gmcharlt> it's certainly time for a 3.2.3, given some of the reliability pull requests that have cropped up in the past couple weeks
15:12:24 <gmcharlt> and yeah, it doesn't hurt to just get a 3.3.0 out the door ("the new OpenSRF: Now With Less!")
15:12:48 <Dyrcona> :)
15:13:01 <Dyrcona> Less can be a good thing.
15:13:18 <gmcharlt> looks like we have a couple minor wishlist PRs as well that could go in to 3.3.0
15:14:03 <gmcharlt> is anybody aware of anything that would be a significant new feature waiting in the wings?
15:14:07 <JBoyer> I think if there's going to be a 3.2.3 that backporting the python branch would be a good idea since it isn't supported and breaks new installs.
15:15:29 <Dyrcona> I'll second that.
15:15:54 <gmcharlt> I disagree. provided that 3.3.0 is done at the same time, 3.2.3 can continue as a thing that can go in via a configure/make install dance
15:16:04 <csharp_> @decide The Python Branch or The No-Python Branch?
15:16:04 <pinesol> csharp_: That's a tough one...
15:16:18 <alynn26> lol
15:16:18 <gmcharlt> I would not expect any additional 3.2.x releases, however, barring a log4opensrf-shell situation
15:16:36 <berick> heh
15:16:48 <JBoyer> Of the ~50 open bugs for OpenSRF I don't think any of the major new feature contenders are near ready (I'm mostly thinking of sasl support, which I haven't touched in ages)
15:16:57 <Dyrcona> Well, to be honest I'm happy either way as long as the no python code gets "released."
15:17:21 <Dyrcona> Well, who says a new release has to add features?
15:17:26 <JBoyer> Works for me also. 3.2.3 can be the going away present for < bullseye
15:17:26 <gmcharlt> well, the wishlist PRs that could go into 3.3.0 are collectively things that look quick to review
15:17:48 <JBoyer> Dyrcona, just a response to the Q asking if any others were near ready.
15:17:50 <gmcharlt> so I think I'm mostly lobby for attention to several specific PRs prior to a release
15:17:58 <gmcharlt> bug 1953057
15:17:58 <pinesol> Launchpad bug 1953057 in OpenSRF "Perl listener can fail to clean up children during post-crash restart" [Medium,New] https://launchpad.net/bugs/1953057
15:18:02 <Dyrcona> I think this is a problem on Ubuntu Focal also, but I usually install via git.
15:18:13 <gmcharlt> bug 1953047
15:18:13 <pinesol> Launchpad bug 1953047 in OpenSRF "Perl services can crash with a "Can't kill a non-numeric process ID" error" [Medium,New] https://launchpad.net/bugs/1953047
15:18:26 <gmcharlt> and bug 1953044
15:18:26 <pinesol> Launchpad bug 1953044 in OpenSRF "Perl services can crash with a "Use of freed value in iteration" error" [Medium,Confirmed] https://launchpad.net/bugs/1953044
15:18:56 <gmcharlt> the latter two are currently in production at Equinox
15:19:04 <gmcharlt> the first one is a little more prospective
15:19:05 <Dyrcona> I'll see if I can make some time to test a couple of those.
15:19:32 <csharp_> these are the "think of the children!" branches you mentioned before
15:19:56 <gmcharlt> yup
15:21:59 <JBoyer> Sounds like a plan, hopefully all 3 of those can get some testing and make it in soon. Any other OpenSRF discussion?
15:22:24 <jeffdavis> (testing some of those is on my todo list fwiw)
15:22:47 <JBoyer> jeffdavis++ (and Dyrcona ++ and gmcharlt ++ )
15:22:58 <JBoyer> If not, and given the placholders holding places we can skip down to
15:23:09 <JBoyer> #topic Launchpad Status
15:23:16 <JBoyer> #info Snapshot
15:23:25 <JBoyer> #info Open Bugs - 2566
15:23:31 <JBoyer> #info Pullrequests - 90
15:23:37 <JBoyer> #info Signedoff - 34
15:23:46 <JBoyer> #info Updates Since the November Meeting
15:23:52 <JBoyer> #info Bugs Added - 63
15:23:59 <JBoyer> #info Pullrequest tag Added - 19
15:24:05 <JBoyer> #info Signedoff tag Added - 6
15:24:12 <JBoyer> #info Fix Committed - 15
15:24:49 <JBoyer> One benefit of not getting a script done is that I don't have to worry about hitting flood prevention.
15:25:00 <JBoyer> And now, for something completely different
15:25:06 <JBoyer> #topic New Business
15:25:21 <JBoyer> #topic Further opinions re: support for Microsoft Edge
15:25:45 <JBoyer> Who would like to collect these opinions
15:26:22 <Dyrcona> I don't have an opinion, since I don't have any experience with Edge.
15:26:52 <JBoyer> Hah. Well, it looks like I put it on the agenda. Mystery solved.
15:27:08 <csharp_> do we have a sense of how well Edge Just Works™?
15:27:36 <csharp_> and to be clear, we're talking about Edge that's based on Chrome, yes?
15:27:49 <Dyrcona> I believe so.
15:27:51 <JBoyer> So, with the fact that it's literally Chromium + MS sync instead of Google Sync it works pretty well. shulabear took the client for a test drive and found no potholes.
15:27:56 <alynn26> I know of several people who use it.  it works great for them.
15:28:18 <csharp_> maybe support it with a huge YMMV warning?
15:28:22 <JBoyer> Yeah, Not-Chromium Edge is no bueno, even for MS.
15:28:41 <shulabear> I've encountered no issues with it in testing, as long as it's the Chromium version.
15:28:44 <csharp_> that's the way we support MacOS here in PINES
15:28:56 <csharp_> "feel free, but it's on you"
15:29:16 <mmorgan> What does "supporting Edge" entail?
15:29:17 <gmcharlt> csharp_: any brickbats tossed in your direction as a consequence, or are the Edge users happy?
15:29:24 <berick> i've heard it called Chredge as clarification ;)
15:29:36 <csharp_> gmcharlt: I've heard literally nothing
15:29:42 <csharp_> lol Chredge
15:30:28 <JBoyer> mmorgan, basically if something only affected Edge we would still make changes to fix it. Which we only do for things like Safari if it's the OPAC or a dev just really wants it to work. (which Safari mostly does, but I wouldn't use it for work.)
15:30:29 <gmcharlt> mmorgan: IMO (a) a statement that we believe that all functionality will work on Edge and (b) if something doesn't work, it would get the same amount of general effort as a Chrome- or Firefox-specific bug
15:31:00 * mmorgan nods
15:31:04 <gmcharlt> whereas yeah, Safari currently would get no such promise
15:31:26 <csharp_> I guess Hatch should be in the mix of what "support" means too?
15:32:11 <JBoyer> csharp_, it works fine as-is, just isn't yet on the Edge Extension thing. (though you can install it via the chrome web store I believe)
15:32:31 <csharp_> I don't have a strong feeling/preference either way, which I guess is effectively "yes"
15:34:12 <JBoyer> It's also possible to test the Angular client with the linux version by setting CHROMIUM_BIN to the right path. (I don't actually recommend using my branch to add the edge npm launcher because there's no good way to handle missing browsers. :/ )
15:35:36 <JBoyer> I'm for it personally because it's extremely low effort and it's possible that local IT may standardize on it anyway so staff may as well know we'll make sure it works.
15:36:20 <alynn26> +1
15:36:29 <gmcharlt> +1
15:36:31 <Dyrcona> Do we want a vote?
15:36:42 <JBoyer> It's been a while, why not.
15:37:00 * csharp_ blows the dust of the #vote command
15:37:02 <Dyrcona> I was thinking that we probably don't need a vote.
15:37:28 <JBoyer> #startvote Should Microsoft Edge (Chromium Version) be Considered a Support Browser for the Evergreen Staff Client? yes no abstain
15:37:28 <pinesol> Begin voting on: Should Microsoft Edge (Chromium Version) be Considered a Support Browser for the Evergreen Staff Client? Valid vote options are yes, no, abstain.
15:37:28 <pinesol> Vote using '#vote OPTION'. Only your last vote counts.
15:37:38 <csharp_> #vote yes
15:37:44 <shulabear> #vote yes
15:37:46 <JBoyer> #vote yes
15:37:47 <abowling> #vote yes
15:37:49 <miker> #vote yes
15:37:51 <mmorgan> #vote yes
15:37:56 <rhamby> #vote yes
15:37:59 <sandbergja> #vote yes
15:38:04 <berick> #vote yes
15:38:19 <phasefx_> #vote yes
15:38:21 <Dyrcona> #vote abstain
15:38:34 <JBoyer> If nothing else this way we can call the discussion done and move on to the next topic. :)
15:38:41 <Dyrcona> :)
15:38:45 <JBoyer> #endvote
15:38:45 <pinesol> Voted on "Should Microsoft Edge (Chromium Version) be Considered a Support Browser for the Evergreen Staff Client?" Results are
15:38:45 <pinesol> yes (10): csharp_, shulabear, miker, abowling, berick, mmorgan, JBoyer, phasefx_, rhamby, sandbergja
15:38:45 <pinesol> abstain (1): Dyrcona
15:38:52 <gmcharlt> #vote yes
15:38:56 <gmcharlt> (got distracted, sorry)
15:39:20 <JBoyer> oops. Let the minutes show that's 11, 0, 1, not that it was a close call. :)
15:39:46 <JBoyer> #topic Support for Newer PostgreSQL Versions
15:39:54 <JBoyer> Dyrcona, how's things?
15:40:07 <Dyrcona> Well, there are branches, one of which has been tested and signed off.
15:40:48 <miker> soon to be committed :)
15:40:52 <Dyrcona> mker looked at the other and had some questions about the XML changes. I'll go back an make them more consistent, using local-name() instead of namespaces.
15:41:27 <Dyrcona> I'd like to get this in before the next Evergreen release. (3.9?)
15:41:57 <miker> seems likely, imo
15:42:02 <Dyrcona> The tests all pass, but I think there are places, like located URIs where performance suffers on newer Pg versions.
15:42:52 <miker> I think I owe eyes on an old branch for that, in particular
15:43:12 <Dyrcona> my three big questions are: 1. I'd like the Stretch removal branch to go in first, so that we don't have to mess with stretch prerequisites.
15:43:46 <JBoyer> That shouldn't be an issue for 3.9
15:43:55 <Dyrcona> 2. I'd like to make Pg 14 the default client on distros where we use the pgdg repository: Debian and Ubuntu.
15:44:13 <miker> +1
15:44:15 <Dyrcona> 3. I think we should make Pg 10 the default server and remove prerequisites for 9.6.
15:44:51 <JBoyer> +1 to removing 9.6, though I'm less sure about preferring 10
15:44:53 <Dyrcona> Of course, Pg 10 is EOL in November 2022.
15:45:07 <miker> do we want to push farther?
15:45:16 <Dyrcona> Well, Pg 10 is known to work well with our current code.
15:45:34 <Dyrcona> CW MARS uses 10 in produciton, fwiw.
15:45:39 <gmcharlt> yeah - Pg 10 is a safer choice for a minimum at the moment
15:45:56 <JBoyer> Other than the speed regressions Dyrcona noted I'd like to go up to 14 so we don't have to change as often, though 10 could certainly stay an option.
15:46:52 <gmcharlt> speed regression of any sort are a significant probleml - I'd want more assurance that we've got them sorted out before pushing for new versions
15:46:57 <miker> that complicates or delays dealing with some performance issues in 11+ re CTEs, but that's just timing I guess
15:47:22 <Dyrcona> Well, we could remove the non-versioned db prerequisite and word the read me to recommend 10 in production environments.
15:48:00 <miker> And by that I mean CTEs may need 11+ only syntax changes to avoid speed regressions
15:48:14 <JBoyer> True, I kind of meant "if we can knock them out" when I said "other than these problems" :) but since we've had 9.6 and 10 available for some time we should probably have 10 and 14 available for those who want to test
15:50:29 <gmcharlt> yeah, "it works" is sufficient for offering the option to install with newer versions, but I think the production recommendations need to avoid known performance regressions
15:50:55 <JBoyer> I can +1 that.
15:51:41 <mmorgan> +1
15:51:42 <shulabear> +1
15:53:21 <Dyrcona> I still have to do the prerequisite installation bits. I was waiting on having this conversation. :)
15:54:16 <Dyrcona> So my takeway is we want to use PostgreSQL 14 Client with the option of any server 10 through 14, but recommend 10 for production.
15:54:49 <miker> seem like a good summary
15:55:11 <miker> Dyrcona++
15:55:12 <JBoyer> So long as the client will work as expected. I know there are problems with 9.6 clients talking to 14 dbs (some slash commands don't work anymore) but I don't know if the reverse is true.
15:55:32 <Dyrcona> #action Dyrcona will finish up the branch on https://bugs.launchpad.net/evergreen/+bug/1937294
15:55:32 <pinesol> Launchpad bug 1937294 in Evergreen "Updating Evergreen for Newer PostgreSQL Versions" [Undecided,In progress] - Assigned to Jason Stephenson (jstephenson)
15:55:55 <JBoyer> Dyrcona ++
15:56:28 <Dyrcona> JBoyer: Newer clients have always worked with older servers in my experience, and I think that's a promise from the PostgreSQL devs.
15:56:30 <sandbergja> Dyrcona++
15:56:44 <JBoyer> That would be ideal.
15:57:16 <JBoyer> better move along, we've had a busy agenda today.
15:57:17 <shulabear> Dyrcona++
15:57:24 <JBoyer> #topic Migrating to Angular 12 sooner than later?
15:57:46 <JBoyer> berick, how does it look?
15:58:31 <berick> oh sorry
15:58:59 <berick> minus a few broken unit tests, my initial Ang 12 upgrade process worked as expected
15:59:13 <JBoyer> The angular update site makes it look like we can make that jump without any real code changes, which is good.
15:59:20 <berick> if we want to update before EG 3.9 I'd prefer sooner than later
15:59:27 <sandbergja> berick: does the linter still work?  I remember something about some linting changes
15:59:28 <berick> yeah, it was not such a big doeal
15:59:47 <berick> sandbergja: don't recall if I tested.  I can, though, when I rebase
15:59:58 <sandbergja> berick++
15:59:59 <sandbergja> thanks
16:00:45 <berick> ideally we could pick a merge date and me and whoever else can help will get it merged
16:01:54 <sandbergja> I can be a helper, especially if it is in December or late January
16:02:32 <berick> thanks sandbergja .  i'll rebase and try the linter within the next week or so and reach back out
16:02:49 <JBoyer> berick ++
16:02:51 <berick> any general objections to merging Ang 12 to master (only) from the group?
16:02:51 <JBoyer> sandbergja ++
16:03:01 <berick> potentially before end of month
16:03:24 <JBoyer> I think it's a good idea, no point in getting too far behind, especially while few are required.
16:03:43 <miker> as long as there's a "do this to update your env" note, no objections from me
16:04:02 <berick> yeah, there's one on the bug, but I can post to list oo
16:04:04 <berick> er, too
16:05:16 <miker> even just in the commit message is probably enough. just so I can go look it up again when I forget what to do :)
16:05:27 <berick> can do
16:05:41 <JBoyer> Sounds like a .plan.
16:06:06 <JBoyer> #topic Setting up 2-factor auth for chromestore@evergreen-ils.org so we can update Hatch
16:06:22 <berick> yes, I didn't feel in a position to set up the 2-factor auth
16:06:32 <berick> but we need it to update the chrome store Hatch
16:06:33 <JBoyer> Understandable that it's required, but annoying for our use case.
16:07:10 <JBoyer> Did I see somewhere that you can have an organization with multiple separate users? That would simplify it a little
16:07:37 <JBoyer> (I thought it was either berick or jeff that mentioned that)
16:08:22 <berick> don't think it was me.  makes sense, though
16:08:42 <Dyrcona> I recall jeff saying something about that.
16:09:29 <JBoyer> I suppose email isn't allowed to be the second factor? :)
16:10:18 <Dyrcona> jeff said something about sharing a TOTP.
16:11:16 <berick> JBoyer: phone # or auth app
16:11:39 <Dyrcona> http://irc.evergreen-ils.org/evergreen/2021-12-13#i_496907
16:11:41 <berick> we need an Evergreen Headquarters phone
16:11:45 <JBoyer> I figured.
16:12:02 <Dyrcona> I thought he was talking about email at the time, but it is probably connected.
16:13:10 <berick> https://developer.chrome.com/docs/webstore/group-publishers/
16:13:24 <berick> my concern for the moment, though, is we have lots of sites that want the new Hatch version
16:13:31 <berick> it's causing real problems
16:13:42 <mmorgan> Indeed!!
16:13:48 <berick> re: taking time to set up group publishing
16:14:58 <berick> i don't mind setting up 2FA -- if I use Authenticator IIRC it makes me scan a QR code (TOTP) which I could presumably share
16:15:32 <jeff> Yep, that was my simplest suggestion. The catch is to share the token before it's in Authenticator -- it's easier.
16:15:33 <JBoyer> Yeah, you could take a screenshot of it before scanning with your phone or password manager.
16:16:54 <JBoyer> I'm fine with you doing that in order to get this moving, and finding a backchannel way to share the totp code with me and jeff and (I think?) csharp_
16:17:21 <berick> ok, great, I'll do that then.
16:17:26 <berick> thanks for the input everyone
16:17:41 <JBoyer> While we *also* setup the group publishing thing. It's annoying that it looks like we can't just use the existing group (since I thought chromewebstore@ was a group already)
16:18:32 <mmorgan> berick++
16:18:36 <JBoyer> Since it'll involve evergreen-ils.org addresses, do you want to get in touch with the board berick or should I?
16:19:19 <berick> JBoyer: get in touch and say what?
16:19:34 <jeff> There are a lot of challenges with sharing a Google account between multiple users, though some of those issues go away if/when the shared account is in a Workspace domain. That aside, once initially set up and shared (preferably by sharing a TOTP seed), any of the trusted individuals can add one or more of their hardware tokens to the account, which then requires no further coordination other than to not
16:19:40 <jeff> remove each other's keys.
16:19:57 <jeff> JBoyer: that email address is an alias on lupin.
16:20:21 <jeff> (whatever the address is -- not looking it up right now)
16:20:56 <JBoyer> Ah, so I may be a little behind there then. Google wants a google group to do this, which can be setup since I believe evergreen-ils.org has gsuite access.
16:21:44 <jeff> Ah, but you found the secret "you can only have one owner, but that one owner can be a group" bit. That's handy.
16:21:55 * jeff scans
16:22:36 <jeff> Hefty caveats.
16:23:10 <JBoyer> Yeah, don't ever want to delete anything.
16:26:45 <jeff> The middle ground between "carefully make a group the owner" and "share a single Google account among trusted individuals" is what I was talking about the other day, where you can add users to your Play Console developer dashboard, granting them rights (almost but not quite owners) to publish updates, etc.
16:31:47 <JBoyer> Sorry, have been distracted by other things
16:33:14 <JBoyer> Needing to vanish over here, I can work with the board to setup group publishing if that's what we want to going forward
16:33:30 <JBoyer> Otherwise we can keep going with the shared totp code for a while.
16:34:09 <jeff> keep going with shared totp seed for now would be my preference. revisit after Hatch extension update is published and come up with a plan.
16:34:42 <JBoyer> jeff, can do. we can always revisit.
16:36:26 <berick> Hatch extension submitted to Goog for review.  They now say "it can take weeks" depending on the extension.  Fun.  it's never taken more than a day before, though, so fingers crossed
16:36:46 <alynn26> yea
16:37:43 <JBoyer> Time for me to ghost, FF does also need updating though it seems it's less pressing than Chrome. At least there isn't an MFA requirement I can see.
16:37:47 <JBoyer> #endmeeting