15:01:32 #startmeeting 2020-10-06 - Developer Meeting, Agenda Available at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2020-10-06 15:01:32 Meeting started Tue Oct 6 15:01:32 2020 US/Eastern. The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:32 The meeting name has been set to '2020_10_06___developer_meeting__agenda_available_at_https___wiki_evergreen_ils_org_doku_php_id_dev_meetings_2020_10_06' 15:01:34 :) 15:01:41 #topic Introductions 15:01:45 Who have we here? 15:01:58 I'm here :) 15:01:59 #info Dyrcona = Jason Stephenson, CW MARS 15:01:59 #info JBoyer = Jason Boyer, EOLI 15:02:06 #info phasefx = Jason Etheridge, EOLI 15:02:08 #info jeffdavis = Jeff Davis, BC Libraries Coop (Sitka) 15:02:11 #info abowling = Adam Bowling, Emerald Data Networks 15:02:19 #info dluch is Debbie Luchenbill, MOBIUS (here for DIG) 15:02:29 #info mmorgan is Michele Morgan, NOBLE 15:02:31 #info shulabear = Shula Link, GCHRL in GPLS 15:02:37 #info mantis1 = Gina Monti, Bibliomation 15:02:41 #info dbwells = Dan Wells, Hekman Library (Calvin University) 15:02:44 #info abneiman = Andrea Buntz Neiman, EOLI 15:03:09 #info rfrasur = Ruth Frasur, Indiana/lurking 15:03:22 #info csharp = Christopher J. Sharp, The Georgia Public Library Service 15:03:22 #info alynn26 = Lynn Floyd, Evergreen Indiana 15:03:23 #info berick Bill Erickson, KCLS 15:03:24 If anyone joins midstream feel free to info it up. 15:03:33 #topic Action Items from Last Meeting 15:03:53 #info berick and csharp to consider approaches to lp 1627373 15:03:54 Launchpad bug 1627373 in Evergreen "Acq: We need to fully implement EDI availability codes" [Wishlist,Confirmed] https://launchpad.net/bugs/1627373 15:03:54 heh - nope! 15:03:54 I know you're both interested in seeing EDI improved; does this dev meeting reminder help or would you like to table this action item until there's more to report? 15:03:54 * berick punts again 15:04:02 same 15:04:03 I'm here sitting in 15:04:10 csharp: /The/ Georgia Public Library Service ? 15:04:19 mrisher: welcome! 15:04:19 #info gmcharlt = Galen Charlton, EOLI 15:04:26 #info mrisher = Mike Risher, KCLS 15:04:36 dbwells: feeling frisky today :-) 15:04:42 #info terranm = Terran McCanna, PINES 15:04:46 :D 15:04:48 Borrowing inflections from OSU, heh. 15:05:18 So thoughts on the Q above berick and csharp ? 15:06:11 probably be good if we could pause it for a few months 15:06:19 +1 15:06:37 Sounds good. We'll be happy to hear where there's more to report. :) 15:07:03 next previous action item was 15:07:03 #info sandbergja is Jane Sandberg, Linn-Benton Community College 15:07:05 #info gmcharlt will cut OpenSRF 3.2.1 around Evergreen point release time 15:07:12 And so it was, more on that very soon. 15:07:21 #topic OpenSRF Release Info 15:07:28 gmcharlt? 15:07:38 as noted, 3.2.1 is released 15:07:55 and I'd like to briefly ask what folks would like to see as dev priorities for OpenSRF 3.3 15:08:05 with SASL support being one of them, presumably 15:08:15 Are Python and Java gone, yet? 15:08:30 no 15:08:42 Well, I'd like to see Java gone, at least. 15:09:05 I *think* I had a branch somewhere... 15:09:08 Python will come up under a later agenda item. 15:09:35 All right. 15:09:55 And I have my "kind of works, for perl only" SASL changes at least moved over to my work machine, just need to finally push it up somewhere and do the rest. 15:10:04 bug 1827051 15:10:05 Launchpad bug 1827051 in OpenSRF "Removal of OpenSRF and Evergreen Java Libraries" [Low,New] https://launchpad.net/bugs/1827051 15:10:59 csharp++ 15:11:30 I'll dust that branch off after the meeting and make sure it still works. 15:11:51 Well, those branches.... 15:12:30 Seems like there are some good thoughts on how to make progress for 3.3. Does anyone have anything to add before moving on to Evergreen updates? 15:12:51 right-o 15:12:55 #topic Evergreen Release Info 15:13:16 #info Release candidate due 2020-10-07 15:13:18 so, I put up the two points here 15:13:53 and at this point, I'm curious if there's been additional testing of the Bootstrap OPAC from the betas 15:14:17 and would like to identify any absolute showstoppers that should go into the -rc 15:14:26 noting, also, that we're in string freeze 15:14:35 gmcharlt: it's on mine and terranm's to-do, but we haven't gotten there yet 15:14:59 I did some testing of the Bootstrap OPAC on festivus, but I'm not sure if that has the most recent version 15:15:02 (bootstrap opac) 15:15:17 terranm: it does 15:15:28 (AFAIR, anyway) 15:16:18 I think this bug summarizes the main issues - https://bugs.launchpad.net/evergreen/+bug/1895398 15:16:19 Launchpad bug 1895398 in Evergreen "Bootstrap OPAC: follow up needed" [Undecided,New] - Assigned to Christopher Burton (cburton) 15:16:19 * mmorgan plans to finish up testing bug 1889128 for the rc 15:16:20 Launchpad bug 1889128 in Evergreen "Angular Staff Catalog: Place Another Hold & Multi-Holds" [Undecided,Confirmed] https://launchpad.net/bugs/1889128 15:16:25 there is a patch out there as well 15:16:46 The advanced search screen filters not working was the biggie for me 15:17:09 Yeah. That's fixed in the patch 15:17:17 nfBurton11++ 15:17:23 It was versioning on the Bootstrap that knocked it out 15:17:49 I don't think that's on festivus yet 15:17:55 #info Bmagic = Blake GH, MOBIUS 15:18:18 There are a number of bugs the OPAC will render obsolete. How do we proceed with those? I've been putting notes, but should they be tagged too 15:18:55 #fixedinbootstrap ? 15:19:03 +1 15:19:05 comments to start, but note that "render obsolete" depends on when exactly when TPAC gets deprecated, then removed 15:19:09 They could perhaps have a "legacyopac" tag or similar IIF they definitely don't apply to the new opac. 15:19:31 I like that 15:19:34 certainly the deprecation isn't planned before 3.7, and as folks know, there's current disagreement about scheduling renewal 15:19:42 I suggested #fixedinbootstrap because I think we had #fixedinwebby before. 15:19:52 Yeah, the window should be small, but I certainly wouldn't expect all fixes to halt on the existing opac next week. 15:19:57 +1 to 'legacyopac' as it can probably be applied to *cough* even older bugs :) 15:20:26 (also, regarding Bootstrap, after 1895398 is dealt with, I would like to make a plea that we move away from big omnibus patches) 15:20:39 :) 15:20:44 ++ 15:21:28 gmcharlt: You don't want to spend 6 hours reconciling them against master, either, huh? :) 15:21:52 +1 15:22:10 +1 15:22:28 terranm: could you turn your comment #6 into a separate bug, please? 15:22:36 sure 15:22:40 thanks 15:23:04 otherwise, unless we can declare a set end point for 1895398, I can't guarantee it making it into the -rc 15:23:36 +1 I'm all for smaller bugs and smaller patches. 15:23:54 but providing that the branch doesn't change out from underneath me, I can make a committment to review the current pull request for 1895398 tonight for potential inclusion in the -rc 15:23:54 +1 15:24:02 Ok, anything further for Evergreen updates? 15:24:10 +1 l 15:24:24 #topic Hatch Release Info 15:24:56 I don't have anything and haven't seen much change recently. 15:25:36 Hopefully that means it's mature and working well. 15:25:47 We do however, have 15:25:51 #topic New Business 15:26:02 Wait, what about Documentation? 15:26:09 Ah, as I accidentally skip docs. :/ 15:26:18 Need ot update my script. :) 15:26:22 :-) 15:26:25 #topic Documentation 15:26:47 So, some exciting stuff going on with documentation: 15:26:51 on 9/8/20 gmcharlt merged Bmagic 's Antora branch to master 15:27:04 then gmcharlt is going to update the main docs page to point to the new files 15:27:11 (did that happen?) 15:27:17 it was :)collab 15:27:32 https://eg-docs.georgialibraries.org/ has the latest and greatest 15:27:32 Cool 15:27:51 and at this point, unless there are any objections, I think it would be safe to point the docs.evergreen-ils.org name to the new server 15:27:53 Also, DIG has a recommendation-slash-request that if you write new features and have docs for them, we are happy to take them and make them adocs and commit them 15:28:10 gmcharlt++ dluch++ DIG++ 15:28:18 +1 to that, gmcharlt! 15:28:32 gmcharlt++ Bmagic++ 15:28:40 one more thing... 15:28:52 and Bmagic++ # of course 15:29:02 wait, no two more things, lol 15:29:10 dluch++ rfrasur++ 15:29:12 one quick thing... THe database schema Maps need updating for 3.3 -3.5 15:29:31 JBoyer: Bmagic: I didn't pay complete attention to your conversation yesterday about the lunr bits 15:29:31 dluch raises a question that just occurred to me. Had the inclusion of Antora changed what we need to do for release notes? Did I miss something about that? 15:29:35 are things squared away there? 15:29:47 Finally, yes. 15:29:51 As the two docs committers and the facilitator of DIG, @abneiman, @sandbergja and I made an executive decision that there will be no backporting of older docs 15:29:55 gmcharlt: ping me about that - probably want a hostname change too (if we're talking about docs-testing) 15:30:03 yep! JBoyer++ 15:30:04 csharp: no, eg-docs 15:30:09 After (mumble) minutes staring at it I added an @import line and the CSS was pleased. 15:30:11 oh - great! 15:30:12 csharp: but yes, I'll follow up with you 15:30:17 I just built off Evergreen master a few minutes ago, and the site search is working once more 15:30:22 gmcharlt++ 15:30:38 alynn26: indeed. we'll need to reverse-engineer what was used to produce the older schemas 15:30:56 although the floor is certainly open to newer tools that might produce a more usable schema doc/sub-site 15:31:18 Dyrcona: as far as release notes are concerned, they're not part of the Antora framework to date 15:31:27 and are still built the same way for release 15:31:49 though abneiman did adjust the 3.6 release notes to use the same style of marking headings that the rest of the docs now do 15:32:01 I was initially intrigued by the tool that Koha uses for their schema site, but with a many links as we have it seemed less useful when I last tried playing with it. (which has been a bit) 15:32:38 OK, thanks. 15:32:40 dluch, I see one of your two more things, was there more you wanted to share? 15:32:53 DIG will be at the hack-a-way, with a focus on 3.6 documentation 15:32:56 That's all! 15:32:57 a schema browser even without pretty graphics might be a win 15:33:18 dluch++ 15:33:21 phasefx++ 15:33:29 dluch++ 15:33:41 dluch++ 15:34:13 phasefx, yeah, any graphics are pretty much a one-way ticket to a big black smear of lines going hither an yon. That's one way to fingerprint a software project I suppose. :) 15:34:30 Thanks for the doc updates! 15:34:32 #topic New Business 15:35:31 #info Next scheduled meeting is Tuesday, November 3rd, reschedule? 15:35:35 I'm certainly +1 to moving the next meeting in line with this first item. How about everyone else? 15:36:13 +1 15:36:17 +1 15:36:23 +1 15:36:25 maybe Tuesday, Nov 10 specifically? (same time) 15:36:40 +1 15:36:42 +1 to that as well 15:36:42 +1 15:36:43 oh that's US election day, +1 15:36:51 Skip or nudge was going to be my next Q. 15:36:51 +1 15:37:30 I can do the 10th (If anyone is +1-ing that, you may need to spell that out. :) ) 15:38:02 +1 to the 10th 15:38:07 10th +1 15:38:11 I don't see any conflicts on the community calendar for the 10th 15:38:19 +1 11/10 15:38:27 +1 15:38:34 Sounds like a winner to me. 15:39:16 Do we have a volunteer to update the community calendar? 15:39:51 I can do it I think 15:40:05 I think I can do it if terranm doesn't have permission. 15:40:13 #info Next meeting is 2020-11-10 at 3p Eastern / 12 p Pacific 15:40:22 Hmm, maybe I don't have permission 15:40:30 I know that I don't, so didn't want to forget. :) 15:40:42 I've updated the calendar 15:40:48 gmcharlt++ 15:41:03 wait, hold on, wrong calendar 15:41:04 one moment 15:41:34 :) 15:42:05 gmcharlt++ 15:42:06 ok, there we go 15:42:30 With that, who would like to talk about Antora CI ? (I mean, I have an idea, but go for it. :) ) 15:42:37 Oh, that was me! 15:42:46 I was mistaken! 15:43:01 #info Continuous integration for Antora 15:43:12 So, a long-standing issue with docs is that getting an environment to build the docs is tricky 15:43:21 especially on Windows 15:43:44 especially for occassional (sp?) docs contributors 15:43:54 with Antora, it's still complicated 15:44:05 although JBoyer has done a lot to simplify it 15:44:08 JBoyer++ 15:44:24 So, I made a thing: https://github.com/sandbergja/Evergreen/pull/4 15:45:12 sandbergja++ 15:45:13 Basically, if somebody makes a pull request to this github repo, CircleCI will build the docs with the proposed change, then a bot replies with a link to the built docs 15:45:29 sandbergja++ 15:45:33 sandbergja++ 15:45:53 sandbergja++ 15:45:59 There are a lot of refinements that ought to be made, and also some discussions about whether we want to start relying on CircleCI and Github to this extent 15:45:59 sandbergja++ 15:46:53 We could discuss those at the hackaway perhaps? 15:47:02 yeah 15:47:05 * phasefx wants to put doc building back into the live tester as well, but really likes CI 15:47:10 https://circleci.com/open-source/ <== seems promising 15:47:29 Could it be integrated with gitlab? 15:47:39 Dyrcona: good question! 15:48:07 And, I'm not looking for an answer today, but it could help us decide what to do about git. 15:48:21 putting on my board hat, the main immediate caution is that we don't end up depending on a tool that would require an unexpected expenditure to keep using 15:48:47 That does make sense! 15:48:58 And CircleCI is far from the only option out there 15:49:00 so that's a consideration, but services that are willing to give free services to open source projects and/or nonprofits of course are good to consider 15:49:31 Although not all CI services out there will build and store artifacts in a publicly accessible place 15:49:53 So... feel free to ask me any questions before the hackaway, and we can talk about it further then? 15:50:14 And on that point, while it proves they work and you can view them to verify, it's not really intended to be used from the CI output, right? 15:50:22 (just making sure I'm following) 15:50:40 The build outputs, I mean. 15:50:55 JBoyer: correct. It's set up more for building than testing 15:51:04 ok 15:51:08 (if I understood your question right) 15:51:33 quick preview for doc writers is the primary use case, I take it? 15:51:36 there is an annoying issue with Antora where it always returns an exit code of 0, even if you give it a million errors :-( 15:51:46 gmcharlt: at this point, yes 15:52:05 sandbergja++ 15:52:35 sandbergja++ 15:52:45 although I could totally see it being beneficial to run the test suites we have for code, too 15:52:52 sandbergja++ 15:53:02 but we can get there eventually 15:53:06 :-) 15:53:36 (sandbergja: Bmagic: JBoyer: side note - I would like to build a Git repo (or set of repos) that cover all aspects of the entire docs site) 15:54:00 It might be interesting to get the previous buildbot (or something like it, anyway) going again, or finding out if Evergreen would fit within someone's free plan, outside of just docs. 15:54:12 gmcharlt, +1 15:55:08 It seems to me that the current docs server could trigger a build -> /dev/ when the repo receives a new push to X branch ? 15:55:41 that wouldn't be too hard to set up 15:56:14 but I think that distinct from CI of PRs in progress 15:57:45 We'll have to keep moving but I'm looking forward to how this moves forward in the future, sandbergja++ 15:57:51 #info Ubuntu 20.04, Python, Syrup 15:58:19 jeffdavis, was this yours or did you just happen to notice that Python was going to come up later? 15:58:35 Yeah, I added it. 15:59:01 We don't support 20.04 yet and IIRC changes in Python support are the big stumbling block there. 16:00:14 At this point I think Syrup is the main reason we haven't dropped Python yet (which would help us get 20.04 supported), and I wonder if the inclusion of the course reserves module changes where we are with that. 16:00:17 There's also a Lp bug suggesting that we update to Python 3 or drop Python support. Lp 1827055 16:00:18 Launchpad bug 1827055 in OpenSRF "Python binding for OpenSRF and Evergreen" [Undecided,New] https://launchpad.net/bugs/1827055 16:00:54 Well, Syrup is a whole other issue. 16:01:22 AFAICT, Syrup is dead software. 16:01:40 https://www.youtube.com/watch?v=Jdf5EXo6I68 16:02:05 though more seriously, have any of the sites who are still running Syrup had an opportunity to compare it with the new module? 16:02:14 gmcharlt++ 16:02:22 gmcharlt++ 16:02:23 We don't run Syrup any longer. 16:02:40 jeffdavis: do y'all still run Syrup? 16:03:02 No. 16:03:09 NOBLE feels that it has all the building blocks we need. 16:03:20 (Actually we never did, we use the old Conifer thing.) 16:03:57 We're still running Syrup, but ran into an issue when we upgraded to 3.4 16:04:03 dbwells, did/do you use Syrup? 16:04:17 Yes, we do. 16:04:23 I thought your name came up the last time it was discussed but may be misremembering. 16:04:27 Ah 16:04:41 (In another meeting now, sorry...) 16:04:59 The time has gotten away from me a little today. 16:05:47 I'm inclined to drop Python, but I feel less strongly about that than I do Java. However, someone needs to step up and maintain the Python bindings if we don't remove it. 16:06:39 If there are no other current active Syrup users (in-channel at least) it's difficult to tell how much impact dropping Python would have at this point, Java is easier since as I understand it it's been completely broken for some time. 16:07:27 possible action item is putting out a call for Syrup users to identifty themselves (which I think Dyrcona had done a couple years ago? but wouldn't hurt to repeat) 16:07:29 IIRC, Syrup doesn't actually need the Evergreen Python bindings, either. 16:07:50 I could be mistaken/misremembering. 16:07:53 NOBLE plans to move to the new module as soon as we upgrade to 3.6 16:09:02 +1 to gmcharlt's suggestion, we can probably defer further discussion 16:09:10 Well, The good news is that we likely won't be dropping it in a point release, so there will be whatever functional support that there currently is through 3.6. 16:09:40 gmcharlt++ 16:10:08 Dyrcona: I checked, I think it does import some osrf.* stuff from OpenSRF 16:10:28 So we could look at removing Java and removing / updating Python for 3.7. And yes, a quick survey of evergreen-general (or -users?) would be a good thing to have for that duscussion. 16:10:38 gmcharlt: OK. I had some bad information. 16:11:09 Since I opened my big mouth, I can email the lists re: Syrup. 16:11:15 jeffdavis++ 16:11:17 confirmed 16:11:18 jeffdavis++ 16:11:23 jeffdavis++ 16:11:32 just a brief sniff of syrup.git: 16:11:41 #action jeffdavis to gather information re:current Syrup users 16:11:48 26 OPENSRF_AUTHENTICATE = "open-ils.auth.authenticate.complete" 16:11:48 27 OPENSRF_AUTHENTICATE_INIT = "open-ils.auth.authenticate.init" 16:11:48 28 OPENSRF_BATCH_UPDATE = "open-ils.cat.asset.copy.fleshed.batch.update" 16:11:53 Dyrcona: to be fair, what it's importing seems to be client wrappers that could just be folded into Syrup itself and which should continue to work unless we take away the gateway 16:12:14 whatever the outcome, it's a sticky situation eh? 16:12:23 csharp: hi-o! 16:12:27 ba dum dum 16:12:28 :) 16:12:32 I for one think it's time to stop waffling on Python support. 16:12:38 jeffdavis++ 16:12:41 csharp++ 16:12:41 oh. dear. god. 16:12:45 jeffdavis++ 16:12:47 see what you started?! 16:13:15 * csharp high-fives jeffdavis 16:13:45 :) 16:13:55 JBoyer: quick, end the meeting lest the puns grow! ;) 16:14:10 Ok, I'm looking forward to seeing how we can get from here to supports-ubuntu-20.04. Anyone else have any further discussion? 16:14:17 Do we want to continue discussion Ubuntu 20.04 or end the meeting. I think there are other things that we'll run into. 16:14:36 do we know what some of those pain points are? 16:14:44 Pg 12, for one. 16:14:51 Pg 11, possibly, too. 16:15:00 * csharp is installing a 20.04 VM right now to start poking at 16:15:15 I have a 20.04 VM, but haven't really started looking. 16:15:44 Do we not use the pgdg repo on Ubuntu? I'm not saying we should ride 9.6 over a cliff but does that specifically affect 20.04 support? 16:16:32 We do use the pgdg repo, but 9.6 is EOL in 1 year. Pg 13 is being released. 16:17:16 Ah, ok. So not 100% tied to 20.04 but still really timely. :/ 16:17:40 Pg 12 is the default on 20.04. 16:18:23 It bothers me that core parts of the infrastructure are falling behind, and I don't have time to keep up with everything. 16:18:38 Given the time and the fact that we've likely lost some folks, do you want to make this one of the major points of the 11/10 meeting (which also gives people time to look specifically into it also)? 16:19:17 * JBoyer misses Slack's ability to edit his grammar crimes. 16:20:23 JBoyer: +1 16:20:33 (for pushing this to 11/10) 16:20:35 * abowling votes to pick back up on the 20.04 talk on 11/10 16:20:36 We're going to have to discuss it some time. I plan to spend most if not all of the hackaway looking at Ubuntu 20.04 and newer Pg releases. 16:20:55 Dyrcona++ 16:21:17 I'll go ahead and make that assumption (and setup the agenda for the next meeting today). It is an important discussion. 16:21:29 Dyrcona++ 16:21:47 Ok, with that those of you still with us are free to go! See you on the 10th. 16:21:51 #endmeeting