15:01:13 <JBoyer> #startmeeting 2022-11-15 - Developer Meeting
15:01:13 <pinesol> Meeting started Tue Nov 15 15:01:13 2022 US/Eastern.  The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:13 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:13 <pinesol> The meeting name has been set to '2022_11_15___developer_meeting'
15:01:20 <JBoyer> #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2022-11-15
15:01:27 <JBoyer> #topic Introductions
15:01:38 <phasefx> #info phasefx = Jason Etheridge, EOLI
15:01:44 <gmcharlt> #info gmcharlt = Galen Charlton, Equinox
15:01:45 <JBoyer> #info JBoyer = Jason Boyer, Equinox
15:01:50 <berick> #info berick Bill Erickson, KCLS
15:01:53 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:01:59 <jeffdavis> #info jeffdavis = Jeff Davis, BC Libraries Cooperative (Sitka)
15:02:58 <dmoore> #info dmoore = Dan Moore, KCLS
15:03:29 <miker> #info miker = Mike Rylander, EOLI
15:04:07 <shulabear> #info shulabear = Shula Link, GCHRL in PINES
15:04:53 <JBoyer> Ok, others should feel free to #info-in as they arrive.
15:04:55 <JBoyer> #topic Action Items from Last Meeting
15:05:00 <JBoyer> #info sandbegja and others are looking into AngularJS node module security updates
15:05:06 <JBoyer> #link https://bugs.launchpad.net/evergreen/+bug/1992529
15:05:06 <pinesol> Launchpad bug 1992529 in Evergreen "Upgrade insecure npm dependencies for angularjs staff client" [Medium,New]
15:06:00 <JBoyer> It looks like things are going alright, terranm was able to successfully do some testing but no one involved seems to be here to expand on it.
15:06:46 <JBoyer> There is a branch available that anyone comfortable poking at Angular should take a look at, if it made it in before 3.10 that would be great.
15:07:14 <JBoyer> #topic Evergreen Release Updates
15:07:27 <JBoyer> Any updates from the 3.10 relteam?
15:07:33 <gmcharlt> yes -
15:07:54 <scottangel> Well Hello Evergreen! New Dev here looking for new dev info.
15:07:56 <gmcharlt> I will be cutting 3.10.0 today; it will be identiical to the release candidate with the exception of some release notes updates
15:08:22 <gmcharlt> scottangel: welcome; we've started a development meeting; please stay and watch!
15:08:28 <gmcharlt> and any strings
15:08:38 <gmcharlt> I will also branch rel_3_10 today
15:08:51 <gmcharlt> note that pushes to master since the RC was cut will be retargeted to 3.10.1
15:09:05 <gmcharlt> I'll also cut an OpenSRF release towards end of the week
15:09:35 <gmcharlt> also, I want to particularly acknowledge the efforts of sandbergja, mmorgan, terranm during this release cycle
15:09:55 <JBoyer> gmcharlt++
15:10:00 <JBoyer> sandbergja++
15:10:03 <JBoyer> mmorgan++
15:10:07 <JBoyer> terranm++
15:10:17 <shulabear> gmcharlt++ sandbergja++ mmorgan++ terranm++
15:10:36 <berick> sandbergja++ mmorgan++ terranm++ gmcharlt++
15:10:44 <mmorgan> gmcharlt++
15:10:50 <mmorgan> sandbergja++
15:10:58 <mmorgan> terranm++
15:11:08 <JBoyer> Thanks gmcharlt! Anything else before moving on to LP stats? (Feel free to keep the karma coming as well)
15:11:31 <gmcharlt> no, that's it, other than suggesting that shooting for a 3.10.1 in short order might be good
15:12:32 <JBoyer> +1 I had pushed a few things this morning thinking that they'd make it into 3.10.0, so that sounds good to me.
15:12:36 <JBoyer> #topic Launchpad Status
15:12:39 * JBoyer #info Snapshot
15:12:47 <JBoyer> #info Snapshot
15:12:48 <JBoyer> #info Open Bugs - 2795
15:12:52 <JBoyer> #info Pullrequests - 72
15:12:55 <JBoyer> #info Signedoff - 43
15:13:00 <JBoyer> #info Updates Since Last Meeting
15:13:04 <JBoyer> #info Bugs Added - 56
15:13:07 <JBoyer> #info Pullrequest tag Added - 29
15:13:11 <JBoyer> #info Signedoff tag Added - 25
15:13:17 <JBoyer> #info Fix Committed - 67
15:13:28 <JBoyer> mmorgan++
15:13:36 <JBoyer> #topic New Business
15:13:52 <JBoyer> #topic Improving QA - there are some issues that commonly recur with new patches, e.g. selectors not being scoped. Should there be a checklist to help devs/committers check for these problems? Other processes?
15:14:29 <jeffdavis> This was brought up by support folks here at Sitka.
15:14:57 <JBoyer> jeffdavis++ I was trying to find out who brought this up in the Wiki history and was coming up short. :)
15:15:20 <mmorgan> jeffdavis++
15:15:28 <JBoyer> (we've also reached the end of my pre-prepared copy/paste script which will be obvious soon enough.)
15:16:03 <JBoyer> To your question, there are a couple things I've been thinking about but haven't been able to research as thoroughly as I'd hoped.
15:16:12 <jeffdavis> Some other common problems I've heard about are settings being made obsolete but not removed, new features being committed without documentation, or existing features being overlooked when a UI is rewritten.
15:17:10 <jeffdavis> I don't know if devs/committers would find a checklist useful or if that's even a good way to capture this kind of stuff?
15:17:49 <gmcharlt> checklists can be good as a statement of expectations, but the more than can be automated, the better
15:17:59 <JBoyer> It seems like a checklist would be tricky for issues as broad as those. (documentation, perhaps, wouldn't be too bad)
15:18:28 <gmcharlt> e.g., I can imagine ways to provide more support for documentation, at least at the release notes level.
15:19:08 <gmcharlt> for example, if we devised as scheme where for the small enhancements that are briefly descibed, that a relase notes entry could be tagged in the commit message for later extraction, maybe that would help
15:19:41 <Bmagic> #info Bmagic = Blake GH, MOBIUS
15:19:53 <gmcharlt> but in any event, I think the starting point is fleshing out the list of concerns so we know what we're dealing with
15:20:04 <gmcharlt> then implementing improvements where we can
15:20:19 <JBoyer> I've been meaning to look more into git hooks, especially a pre-push, to maybe run some QA scripts that are packaged in the repo to at least force some forethought, even if only to make you type "y" to ignore the advice.
15:20:53 <JBoyer> And a list of concerns like gmcharlt mentioned would help make that more useful.
15:20:54 <gmcharlt> also, I think there would be scope for some mini-projects. E.g., "go through the list of library setting looking for ones that are no longer reference"
15:21:09 <gmcharlt> or "go through all of the TODO and FIXME comments in the code"
15:21:22 <berick> agreed a list of common issues could be helpful
15:21:24 <gmcharlt> or "go through the release notes for the past few years and note any deprecation announcements"
15:24:39 <jeffdavis> Given our code, is it possible to automate something like testing that a shelving location selector can be scoped by org unit?
15:26:01 <gmcharlt> generally speaking, yes - more unit tests for the Angular components is certainly possible
15:26:19 <JBoyer> sandbergja demo'd some "e2e" testing during the hackaway that could potentially do things like that; they're Angular tests that drive the browser and verify its results.
15:26:23 <gmcharlt> but that's a very concrete way of answering the question
15:26:46 <gmcharlt> jeffdavis: is the question more about how to enumerate and document standing expectations for behavior?
15:27:21 <jeff> If we start with a list that is suitable for use as a checklist, then we could use the start with using the checklist and potentially craft some automated lint-like checks of common issues like unscoped selectors.
15:29:54 <gmcharlt> commit message templates embedding a (brief) checklist might also be a way - https://thoughtbot.com/blog/better-commit-messages-with-a-gitmessage-template
15:30:13 <jeffdavis> sorry, I keep typing and deleting responses :)
15:30:46 <jeffdavis> a checklist is one example of a way to improve the QA part of our test/commit process, I think we're interested in any kind of solution that improves QA to avoid these kind of recurring problems
15:31:07 <jeffdavis> (it is a very broad problem set for sure, and I agree that formulating a more specific list would be a great next step)
15:32:58 <jeffdavis> I can do some more work with our local support folks to gather more specific examples and flesh out a list for next meeting.
15:33:35 <JBoyer> jeffdavis++
15:33:44 <JBoyer> Care to #action that for the notes?
15:33:50 <shulabear> jeffdavis++
15:33:52 <jeffdavis> oh no, a commitment!
15:34:17 <jeffdavis> #action jeffdavis will gather more specific examples of recurring QA problems to present for discussion at the next dev meeting
15:35:08 <mmorgan> It would also be great if lp bugs that report things like features lost in rewrites could get more attention :)
15:36:42 <gmcharlt> while those are regressions, I wonder if an additional, more specific LP tag would be useful
15:37:19 <JBoyer> mmorgan++ We could potentially plan to discuss *blocker bugs at these meetings to put them in front of more eyes.
15:40:32 <mmorgan> Bug of the month!
15:40:53 <jeffdavis> ha, I like that idea :)
15:41:57 <JBoyer> "This month we highlight a bug that has it all! Undefined variable scoping, user data loss, and red herring log entries!"
15:42:58 <JBoyer> Anyway, jeffdavis++ for bringing this up, and if you feel like the checklist is ready to share before the next meeting feel free to share it on the dev lists.
15:43:18 <jeffdavis> will do
15:43:20 <JBoyer> #topic Community Calendar Access - Does every community calendar have at least 2 (active) admins? Do any of them need to have old accounts removed? Do any calendars need to be retired? (I'm aware of Communications, Community, Developers, and the Oversight board, though there may be others.)
15:43:27 <mmorgan> jeffdavis++
15:44:28 <JBoyer> This one is from me. We've slowly been working our way through the various services cleaning up old accounts and possibly adding new ones.
15:45:50 <JBoyer> In my opinion it would be ideal to have a shared @evergreen-ils.org account that's an admin/owner on all of the various calendars so there's always at least 1 active account that can always make changes if needed.
15:47:06 <gmcharlt> easy enough to set up a time-controller@evergreen-ils.org group
15:47:07 <JBoyer> Any thoughts? Anyone know that this or that calendar is abandoned or no longer needed?
15:47:43 <gmcharlt> and in general, I think keeping the Google Calendars up (or relaunching them) is probably the path of least resistance
15:48:42 <JBoyer> Yeah, I'm not suggesting discarding the existing ones, I may be attributing more advanced ownership / permission options to them than they actually possess.
15:49:16 <gmcharlt> yeah, though recreating them I think is an option we should consider
15:50:05 <JBoyer> I think only 2 are in active use and I'm not 100% certain of that.
15:52:12 <jeff> I'd recommend creating a group on the evergreen-ils.org domain. As long as that group still exists and has the "manage permissions" permission on each calendar, the calendars will persist across the original owner being no longer a Google user, etc... regardless of the original domain/workspace that the calendar was created in.
15:52:21 <jeff> And the calendar then remains the same ID, etc.
15:52:29 <shulabear54> jeff++
15:53:01 <JBoyer> jeff++
15:53:26 <Bmagic> jeff++
15:53:43 <jeff> We do this internally with a purpose-specific "calendar admin" group, after at least one instance of "only user with 'manage permissions' on a shared calendar was deleted, calendar was deleted also" event. :-)
15:54:00 <JBoyer> I wasn't sure if sharing was smart enough to allow a group to be assigned to a calendar, but if so I'm fine with that over a shared Google account (which they understandably try to make very difficult to do.)
15:54:07 <gmcharlt> yep
15:54:45 <JBoyer> gmcharlt++ jeff++
15:54:52 <jeff> I think only very old resource calendars have domain-specific calendar IDs, most these days (including the handful of Evergreen community calendars I checked) end in @group.calendar.google.com
15:54:52 <JBoyer> Sounds like a plan then.
15:55:28 <Bmagic> execute!
15:56:09 <jeff> I think the specific permission is spelled "Make changes and manage sharing"
15:59:42 <JBoyer> I have access to create the group, I'll coordinate with the lists to see who has access to the various calendars so we can handle this out of band.
15:59:48 <JBoyer> Thanks for the feedback everyone!
15:59:53 <JBoyer> jeff++ gmcharlt++
16:00:26 <JBoyer> One more (important!) topic coming up
16:00:30 <jeff> This is the closest "official" documentation of the "this prevents the calendar from being deleted when the owner is deleted" bit: https://support.google.com/calendar/answer/78739#zippy=%2Ctransfer-a-calendar-you-created
16:00:40 <JBoyer> #topic Looking ahead to Angular 14 / Bootstrap 5 for EG 3.11
16:00:48 <JBoyer> #link https://bugs.launchpad.net/evergreen/+bug/1948693
16:00:48 <pinesol> Launchpad bug 1948693 in Evergreen "Migrate from NgbTabset to NgbNav (from ng-bootstrap)" [Medium,Confirmed] - Assigned to Stephanie Leary (stephanieleary)
16:01:30 <JBoyer> berick, sorry for the lateness, but if there's anything you'd like to add it's all yours
16:01:43 <berick> thanks
16:01:51 <berick> a couple quick things
16:01:56 <berick> I'm planning to start down the path of updating to Angular 14, Bootstrap 5, etc.
16:02:12 <berick> first part is review/test/merge of bug 1948693, which now has a patch
16:02:12 <pinesol> Launchpad bug 1948693 in Evergreen "Migrate from NgbTabset to NgbNav (from ng-bootstrap)" [Medium,Confirmed] https://launchpad.net/bugs/1948693 - Assigned to Stephanie Leary (stephanieleary)
16:02:48 <berick> it touches lot of UI's, so my question is if I post it on a public VM somewhere can someone help me bounce through and test the UIs?
16:02:55 <berick> basically making sure they load OK and tabs work OK
16:03:04 <berick> i'll post a link to the LP when it's testable
16:03:14 <berick> i don't need a committment, just putting that out there.
16:03:42 <sleary> I would appreciate a lot of eyes on this one. Obviously I ran through them before committing, but there are a few areas where I didn't have adequate test data
16:03:42 <JBoyer> I'm sure pinging the dev lists would help get some people to poke at it too.
16:04:09 <berick> more generally, the Angular etc update is going to affect probably every angular dependency.
16:04:32 <berick> it's not something we'll want to let linger once it's ready
16:04:54 <berick> so just a heads up that i'm heading in that direction
16:05:05 <berick> this is for 3.11, not 3.10
16:05:16 <berick> after 3_10 is branched, etc.
16:05:26 <berick> sleary++
16:05:50 <shulabear> sleary++
16:06:08 <JBoyer> sleary++ berick++
16:06:12 <berick> that's it from me.  i'll carry on in LP
16:06:12 <Bmagic> I can put that patch on bugsquash
16:06:19 <Bmagic> berick++ sleary++
16:06:23 <berick> Bmagic: i won't stop you!
16:06:28 <Bmagic> :)
16:06:56 <sleary> One thing to keep an eye out for: keyboard navigation should work, but if there are any tab panels that don't contain a focusable element (input, link, etc.) we will need to manually set the tabindex on something; otherwise you won't be able to tab your way into the panel
16:07:21 <sleary> this is a... feature, let's call it... of Bootstrap tabs
16:07:44 <gmcharlt> heh
16:08:29 <sleary> Also, we need to look at one tab (I've lost it, but I'll go find it) that has a dropdown in the tab title. That's a no-go for accessibility and we'll need to think of some other way to present that
16:09:08 <sleary> that can be a separate bug/patch though
16:10:00 <JBoyer> Sounds good!
16:10:11 <JBoyer> Any last minute new business before the meeting ends?
16:10:37 <JBoyer> #topic Announcements
16:10:38 <JBoyer> #info Next Meeting is December 13th, 2022 at noon Pacific / 3 pm Eastern
16:10:44 <JBoyer> #endmeeting