15:01:12 #startmeeting Evergreen Develpment Meeting 2019-12-03 15:01:12 Meeting started Tue Dec 3 15:01:12 2019 US/Eastern. The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:12 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:12 The meeting name has been set to 'evergreen_develpment_meeting_2019_12_03' 15:01:28 #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2019-12-03 15:01:32 #topic Introductions 15:01:57 please introduce yourself using the form "#info irc_nick = name, optional affiliation" 15:02:00 #info JBoyer = Jason Boyer, EOLI 15:02:03 #info gmcharlt = Galen Charlton, EOLI 15:02:13 #info alynn26 = Lynn Floyd, Evergreen Indiana 15:02:13 #info berick = Bill Erickson, KCLS 15:02:22 #info remingtron = Remington Steed, Hekman Library (Calvin University) 15:02:50 #info dbwells = Dan Wells, Hekman Library (Calvin University) 15:03:09 #info phasefx = Jason Etheridge, EOLI 15:03:59 #info Dyrcona = Jason Stephenson, CW MARS 15:04:27 so, starting the slate fresh 15:04:30 #topic OpenSRF 15:04:49 #info OpenSRF 3.2.0 was released on 2019-10-01 15:06:01 so as far as recent bugs are concerned 15:07:05 I see a couple installation-related things, including a pullrequest for Devuan support and issues registering ejabberd users as root on Ubuntu 15:07:37 #info dbs = Dan Scott, Laurentian University 15:07:43 is there anything that folks see as a particularly pressing issue at the moment? 15:09:28 I think we should be looking ahead to adding SASL and new style authentication for OpenSRF and ejabberd. 15:09:39 But, time... :( 15:10:53 Dyrcona: so going beyond the contents of bug 1703411? 15:10:54 Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411 15:12:18 Not necessarily beyond that bug, no. (I had to read it again.) 15:12:46 ok, just wanted to make sure that there weren't desiderata that should at least be added to LP 15:12:56 mod_legacy_auth hasn't been removed from ejabberd, yet, but it is not documented any longer. 15:13:39 #info SASL/new-style-authentication support (see bug 1703411) identified as a potential priority given that mod_legacy_auth is deprecated (and now, undocumented) in recent ejabberd 15:13:40 Launchpad bug 1703411 in OpenSRF "OpenSRF: XMPP Non-SASL auth is being phased out" [Medium,Confirmed] https://launchpad.net/bugs/1703411 15:13:48 anything else before we move on to Evergreen? 15:14:19 #topic Evergreen 15:14:30 handing the floor over to berick and (in spirt) csharp to discuss 3.5 15:14:38 hi 15:14:53 i've put the proposed schedule on the general roadmap page 15:15:06 https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap 15:15:14 let me know if there are concerns 15:15:29 ditto the EG dev calendar 15:15:55 also added a pile of stuff to the feature roadmap 15:15:57 https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.5 15:16:11 most recent being more piles of angular ports 15:16:37 Any other features expected for 3.5 should go into this list 15:17:01 and get tagged with the 3.5 milestone in LP 15:17:44 still pretty early in the cycle. next group activity will be Feedback Fest in Jan. 15:17:54 but i'm sure we'll have plenty to discuss before then 15:18:39 any questions for me? 15:18:52 oops, Feedback Fest in Feb. not Jan. 15:19:08 berick: next you'll be telling us that general release is on April Fool's Day! 15:19:08 ;) 15:19:24 that's the beauty, who knows if I'm making it up! 15:19:38 :) 15:19:58 the Neutral Chaos release 15:20:02 any questions / comments for berick regarding 3.5? 15:20:33 I hope to add something to the roadmap, soon. I want to actually make progress on it before I do, however. 15:21:00 great 15:21:19 so, moving on to maintenance releases, anything to say here? 15:23:22 We still have one blocker for dropping 3.1 releases 15:24:04 dbwells: namely bug 1773191? 15:24:06 Launchpad bug 1773191 in Evergreen "Untranslatable Last Billing Type values" [Undecided,New] https://launchpad.net/bugs/1773191 15:24:26 Yes. Actually, I see there is a security bug as well. 15:25:57 yeah 15:25:57 It seems like both are close, so just highlighting in hopes that someone can push them over the finish line. 15:26:02 both bugs have progress, indeed 15:27:35 I can provide forward progress for the security bug 15:28:24 and we can nudge csharp to see if he's progressed any further with testing for 1773191 15:28:52 #action gmcharlt will apply various code changes and nudges regarding the remaining webstaffblocker bugs 15:29:30 gmcharlt++ 15:29:55 gmcharlt++ 15:30:17 gmcharlt++ 15:31:04 ok, moving o 15:31:07 #topic Hatch 15:31:22 floor back to you, berick 15:32:26 hatch.. 15:33:08 fwiw, we'll be going live on using the omnibus hatch branch merged into our EG code 15:33:14 along w/ the hatch 0.3.2 build 15:33:27 i know there's some other interested parties in moving that bug forward 15:33:43 commit ade63709f4b51b jumps out at me 15:33:45 hoping we can help root out any final issues and encourage some confidence in the bug overall 15:33:54 done a fair amount of use and testing so far 15:34:15 was there anything adding dupes? and if so, should there be code checking that the new constraint is not violated? 15:34:23 or is that patch just belt-and-suspenders? 15:34:54 belt-and-suspenders ... i had a dupe on a dev VM but I was fairly confident it was not from natural causes 15:35:27 i can certainly add a check or at least an \echo 15:36:07 thanks 15:37:19 anyway, that's what I would expect to be the next hatch release 15:37:25 #info more eyes are wanted on the Hatch omnibus branch for bug 1830391 15:37:26 Launchpad bug 1830391 in Evergreen "Hatch omnibus circa 3.3 (Java updates and more)" [Undecided,New] https://launchpad.net/bugs/1830391 15:38:44 so, moving on 15:38:54 #topic Review of specific bugs 15:39:18 #info The SIP2 changes to accommodate a Hoopla change has a pull request at https://bugs.launchpad.net/evergreen/+bug/1853363 15:39:20 Launchpad bug 1853363 in Evergreen "SIP2: add setting to specify overriding certain flag fields" [Wishlist,New] 15:39:32 so, I brought this one up for two reasons 15:39:36 first, for eyes on the pull request 15:40:10 second, now that there's been a couple weeks since Hoopla started informing their customers about the fact that they will be taking certain additional flags into account 15:40:45 ... whether there are Evergreen users out there who ultimately are just fine with the status quo in Evergreen 15:41:07 i.e., that patrons who have blocks or lost cards in Evergreen will start getting blocked in Hoopla 15:41:32 This one is one our RADAR at CW MARS. I was going to wait to see if any one here started complaining about Hoopla blocking patrons unexpectedly. 15:42:07 * gmcharlt makes a note to never got caught in the beam of the caps-lock radar 15:42:13 on our radar too 15:42:16 heh 15:42:21 I think you'd want to block patrons from using Hoopla if they're blocked in Evergreen, but what I think is not always what members want or expect. 15:42:32 It's one I'm watching, 15:42:34 heh.. Well, it's an acronym/abbreviation.... 15:42:44 ah 15:43:01 ok, it sounds like there's sufficient interest in the work-around, dirty as it may be 15:43:15 so yeah, I reiterate my plea for eyes on the pull request 15:43:53 I note that in _principle_ we could really go for broke and teach Evergreen lots of options for managing SIP2 configuration options 15:44:04 (and move the settings in-DB) 15:44:18 gmcharlt ++ 15:44:20 but that's probably way more work on support for an old protocol than is warranted 15:45:12 Moving auth in-db sometime may be worth the effort, but yeah, no need to get *too* fancy with SIP. 15:45:13 I think there's a bug about moving sip settings in-db, or maybe I'm confusing it with something else. 15:45:13 any other bugs that people would like to highlight? 15:46:41 Dyrcona: I'm not immediately finding such a bug, not that that means much 15:46:48 JBoyer: I agree 15:47:16 Probably just something we've chatted about in the past. :) 15:47:42 although moving logins-at-least into the DB probably does mean also moving any per-SIP2-terminal-user settings 15:48:36 Mmm. Yeah, too many less-than-institution level settings. :/ 15:49:25 any other bugs to highlight? 15:50:13 then moving to the final topic 15:50:23 #topic QA-related bugs 15:50:45 this is a carry-over from an earlier version of the agenda, but the LP link for "qaproject"-tagged bugs turns up nothing 15:50:52 does anybody recall what this is? 15:50:58 no bugs there at the moment; I added that to the stock agenda way back when tests failed and no one had the itch to address it 15:51:08 ah, OK 15:51:14 for regressions 15:51:39 #info The "qaproject" LP tag is meant for bugs stemming from automated test failures that aren't immediately addressed 15:51:47 phasefx: ^^ fair summary? 15:51:49 the live test results page also inlines those bugs 15:51:57 gmcharlt++ fair 15:52:49 ok 15:52:55 so at the moment, we're golden! 15:53:04 any other topics that folks would like to raise for the last 8 minutes? 15:53:13 Except that tests failed earlier today. 15:53:22 we're not golden! :( 15:53:35 I think that may be from debian updates to the repo not being atomic, but I'm not sure 15:53:45 Dyrcona, that was some kind of upstream thing. (Not even npm!) 15:54:00 Hash sum mismatch on at least one package 15:54:03 Yeah, I was gonna add that it was probably distro-specific. 15:54:19 *sigh* 15:54:34 it shouldn't spew the channel with a ton of errors next time though, I have RSS just reporting the first one 15:54:36 So, we're silver-ish... :) 15:54:38 I'm not entirely kidding when I say that I wish the Javascript ecosystem had just adopted CPAN 15:55:22 poor JSAN 15:56:53 ok, it sounds like we've hit the end... (just in time for sandbergja to join us!) 15:56:58 so, thanks, folks! 15:57:00 #endmeeting