15:01:12 <JBoyer> #startmeeting 2022-07-12 - Developer Meeting
15:01:12 <pinesol> Meeting started Tue Jul 12 15:01:12 2022 US/Eastern.  The chair is JBoyer. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:12 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:12 <pinesol> The meeting name has been set to '2022_07_12___developer_meeting'
15:01:18 <JBoyer> #info Agenda at https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2022-07-12
15:01:28 <JBoyer> #topic Introductions
15:01:35 <JBoyer> Old joke, who dis?
15:01:37 <Dyrcona> #info Dyrcona = Jason Stephenson, CWMARS
15:01:39 <phasefx> #info phasefx = Jason Etheridge, EOLI
15:01:44 <gmcharlt_> #info gmcharlt = Galen Charlotn, EOLI
15:01:47 <phasefx> calla wha?
15:01:47 <terranm> #info terranm = Terran McCanna, PINES
15:01:50 <shulabear> #info Shulabear = Shula Link, GCHR in PINES
15:01:58 <collum> #info collum = Garry Collum, KCPL
15:02:05 <JBoyer> #info JBoyer = Jason Boyer, EOLI
15:03:11 <JBoyer> And anyone coming in later can feel free to throw an #info down
15:03:19 <JBoyer> #topic Action Items from Last Meeting
15:03:23 <JBoyer> #info Dyrcona will build 3.7.4 point release
15:03:27 <JBoyer> #info Dyrcona will investigate improvements to make_release and upgrade scripts
15:03:42 <mmorgan> #info mmorgan = Michele Morgan, NOBLE
15:03:57 <gmcharlt_> I've updated the agend under the Evergreen section
15:04:01 <JBoyer> I didn't expect these to both be done yet, but any luck on either of them to date Dyrcona?
15:04:10 <JBoyer> gmcharlt_++ I'll grab it
15:04:10 <Dyrcona> Well, I plan to do the 3.7.4 release either this week or next.
15:04:14 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:04:38 <JBoyer> Dyrcona, well, how does 7/20 look? :)
15:05:22 <JBoyer> Well, given where things are on the agenda,
15:05:29 <JBoyer> #topic Evergreen Release Updates
15:05:29 <Dyrcona> It looks fine to me. I might want to get a jump start on the branch, so I did send an email to the development list that I was closing rel_3_7 and 3.7.4 on Lp.
15:05:46 <JBoyer> #topic Evergreen maintenance releases
15:05:50 <JBoyer> #info Galen targeting 20 July; seeking volunteers to help
15:06:15 <JBoyer> Dyrcona++
15:06:29 <terranm> Dyrcona++
15:06:43 <JBoyer> I don't think there will be much resistance to wrapping up 3.7
15:06:43 <phasefx> I'm willing to help with releases, but need to be given tasks to be useful
15:07:34 <Dyrcona> #info There's a signup spreadsheet here: https://docs.google.com/spreadsheets/d/1gZayHfF7qK0zwLMEAXt-PbKBMiAM_F6EZguqzIYceBY/edit#gid=0\
15:07:35 <JBoyer> gmcharlt_, anything you'd like to add to your call to keyboards?
15:07:42 <JBoyer> Dyrcona++
15:07:58 <JBoyer> That's one of the things I was thinking of.
15:08:11 <phasefx> I've never seen that before :D :D
15:08:12 <gmcharlt_> yes, please sign up on the spreadsheet; I'll start bugging people by Thursday
15:08:53 <shulabear> gmcharlt++ Dyrcona++
15:09:04 <JBoyer> I know a few people may be in late or may not make the meeting, I can send something to the dev list unless you're planning to.
15:09:06 <gmcharlt_> and I think otherwise, given the spurt of activity the past couple days, that help testing pending Angular holdings and item editor bugs would be Good Thing
15:09:14 <gmcharlt_> JBoyer: I'll coordinate it
15:09:18 <JBoyer> gmcharlt_++
15:09:35 <terranm> gmcharlt_++
15:10:37 <JBoyer> It sounds like point releases are on their way, any discussion before moving on to LP stats updates?
15:10:38 <shulabear> gmcharlt_++
15:11:01 <mmorgan> gmcharlt_++
15:11:23 <JBoyer> ok
15:11:25 <JBoyer> #topic Launchpad Status
15:11:28 * JBoyer #info Snapshot
15:11:37 <JBoyer> #info Snapshot
15:11:38 <JBoyer> #info Open Bugs - 2765
15:11:42 <JBoyer> #info Pullrequests - 108
15:11:45 <JBoyer> #info Signedoff - 27
15:11:48 <JBoyer> #info Updates Since Last Meeting
15:11:52 <JBoyer> #info Bugs Added - 47
15:11:55 <JBoyer> #info Pullrequest tag Added - 27
15:11:58 <JBoyer> #info Signedoff tag Added - 6
15:12:01 <JBoyer> #info Fix Committed - 20
15:12:24 <JBoyer> Fresh business incoming
15:12:26 <JBoyer> #topic New Business
15:12:32 <JBoyer> #topic Schedule next Bug Squashing Week - late July? (terranm)
15:12:57 <terranm> oops, sorry
15:13:03 <berick> #info berick Bill Erickson, KCLS
15:13:12 <terranm> Yes, I was thinking it is time.
15:13:32 <terranm> Maybe the week of July 25?
15:13:53 <terranm> In addition, I'd like to start spacing out BSWs from FFs better. Since FFs tend to be in Feb and Aug, I was thinking BSWs would be good around early November and late May. Thoughts?
15:14:18 <gmcharlt_> makes sense to me
15:14:19 <berick> +1 to spacing
15:14:20 <JBoyer> That week works for me.
15:14:30 <shulabear> +1 to the week and to spacing
15:14:35 <Dyrcona> Someone who usually hosts servers for bug squashing is going to be out the week of the 25th, but I'll let them chime in if they feel the need.
15:14:36 <mmorgan> +1 to both
15:15:35 <Dyrcona> I may also be out that week and/or the next.
15:15:38 <JBoyer> And +1 to spacing also. Were they forced together for some reason or has experience suggested that they need more space than before?
15:15:53 <terranm> I think it just happened sort of randomly
15:16:52 <JBoyer> Dyrcona, perhaps worth checking, is the person you're thinking of here?
15:17:03 <terranm> I think we get more testing participation if they are spaced out rather than in two months back to back
15:17:25 <Dyrcona> JBoyer: They
15:17:37 <berick> i should be able to host a bug squashing VM this time around
15:17:45 <terranm> berick++
15:17:47 <JBoyer> terranm, makes sense.
15:17:48 <Dyrcona> Yes, listed in the room, and I had a personal chat with them earlier today.
15:17:54 <mmorgan> berick++
15:18:00 <shulabear> berick++
15:18:07 <JBoyer> terranm++
15:18:09 <JBoyer> berick++
15:18:42 <terranm> Tiffany and I should both be able to host, so with ours and berick's, we should be okay
15:18:58 <terranm> Any more are welcome of course
15:18:59 <mmorgan> terranm++
15:19:01 <Dyrcona> I think spacing the events out would be better.
15:19:45 <terranm> Okay, I will schedule this one for the week of July 25, then move to November & May for the regular rotation
15:20:02 <JBoyer> I'll have our two updated also.
15:20:06 <JBoyer> terranm++
15:20:07 <terranm> JBoyer++
15:20:18 <mmorgan> :)
15:20:53 <shulabear> terranm++
15:20:55 <JBoyer> And Nov / May also looks good.
15:21:33 <JBoyer> Anything else for terranm ?
15:21:55 <terranm> Thanks all!
15:22:11 <JBoyer> up next is berick:
15:22:14 <JBoyer> #topic Consider merging bug 1904036? (berick)
15:22:14 <pinesol> Launchpad bug 1904036 in Evergreen "Port patron interfaces to Angular (search, checkout, etc.)" [Wishlist,New] https://launchpad.net/bugs/1904036
15:22:17 <JBoyer> #info If UI components are not ready for prime time, they can remain hidden (unless you know where to find them).
15:22:21 <JBoyer> #info There's lots of good Angular stuff in here and we're collecting other pullrequests that rely on them.
15:22:51 <berick> pretty much says it.  if we don't show the UI bits, we still get a lot of new code that is usable as more stuff is ported to Angular
15:23:20 <berick> new SCKO and item status UI depend on it, and several others I'm sure
15:23:53 <gmcharlt_> are the compoent changes fully separated out in the current branch?
15:24:01 <berick> i'm also leaning toward removing the partial UI integration where there is an extra menu, but that's a secondary part of the discussion
15:24:28 <berick> gmcharlt_: not sure I understand the question..
15:24:53 <gmcharlt_> are changes to core Angular components in separate commits, or are they mixed in with the patron interface commits?
15:25:20 <berick> gmcharlt_: a bit of everything, i imagine.  i can do some cleanup, though
15:25:54 <gmcharlt_> also, I am concerned about the potential for a reprise of the Angular holdings and item editor situation, but even bigger
15:26:22 <berick> gmcharlt_: you mean regressions?
15:26:27 <gmcharlt_> yes
15:26:56 <gmcharlt_> but there's going to be a balancing act
15:27:03 <berick> i get that and it's why I thought merging sans UI bits for starters would buy time to find more bugs
15:27:14 <berick> sans menu entry changes, I should say
15:27:20 <gmcharlt_> the branch is realistically far too large for detailed patch-level scrutiny
15:27:45 <berick> yeah, it's a beast
15:28:20 <gmcharlt_> but if we merge soon (and I do see reasons for doing that), I think we're going to need to organize community testing on a large scale; possibly larger than previoulsy attempted
15:28:42 <berick> my thinking is if the UI is not yet exposed, a minimal amount of the new code will actually be used.
15:29:12 <berick> once we do expose the new UI's, which may come after 3.10, then loads of testing would be needed
15:29:25 <gmcharlt_> yeah, but that just kicks the can down the road, since of course the point is eventually to switch to it
15:29:40 <Dyrcona> gmcharlt_++
15:29:54 <Dyrcona> +1, too.... I think if it goes in, turn it on.
15:30:03 <berick> sort of.  if we can expose less ambitious interfaces that use the underlying code, then we get the chance to test parts of it without flipping a giant switch
15:30:09 <gmcharlt_> so I think what I'm saying is that organizing broad testing needs to happen on the heals of a merge
15:30:13 <gmcharlt_> *heels
15:31:55 <berick> gmcharlt_: so you're thinking flip the big switch on day one too?
15:32:08 <terranm> I could work up a list of tasks that need to be tested for each of the new interfaces as a starting point. It might be easier to get people to test if it's broken into bite-sized pieces.
15:32:14 <mmorgan> Just to clarify, right now, the new uis are under an org unit setting?
15:32:18 <gmcharlt_> more like stand up test systems that have the switch flipped
15:32:34 <berick> mmorgan: sort of.  it's kind of a mess what we have.
15:32:39 <berick> that we were going to test with
15:32:58 <berick> i'm of the opinion that when we do flip the switch, it has to be fully flipped or it's going to get really confusing real fast
15:33:13 <berick> hopping between the same UI's depending on how you got there
15:33:35 <gmcharlt_> (also noting that soon there will be a dump of the Angular acquisitions sprint 4 stuff, though that's more self-contained than the patron/circ stuff)
15:34:10 <JBoyer> terranm++ I do think having a reminder of what all needs to be tested helps. I wonder if some of the staff interfaces have the 1-2 things users do *most* and then say "yeah, didn't fall over" by end users. A guide would help them test things they maybe do quarterly or less.
15:34:26 <mmorgan> terranm++
15:34:43 <mmorgan> +1 to broad community testing
15:35:18 <shulabear> terranm++
15:35:46 <gmcharlt_> also, I think the more that the branch can be cleaned up to have new and changed shared component live in self-contained patches, the better
15:36:18 <gmcharlt_> as individually, those should be much more amenable to piecemeal testing by devs and committers
15:38:04 <berick> yeah, i can clean up the shared/core changes.  that's a small portion of it.
15:39:08 <gmcharlt_> and I think the other thing that would help is ensuring that there's one big ol' switch (or maybe a small set of them) to reliably switch between old and new interfaces
15:39:43 <berick> it gets a little complicated with the patron UI, since it's basically one big application.  it kind has to be added as a whole.
15:39:57 <mmorgan> +1 to reliable switch(es)
15:40:10 <berick> a few things link out, but it's a single tabbed interface
15:40:13 <berick> w/ loads of sub-interfaces
15:41:05 <JBoyer> berick, I think 1 big switch for the patron app is ok, so long as there's no way to accidentally get dropped in the "other" one unexpectedly.
15:41:19 <gmcharlt_> if I'm understanding correctly, that seems like it would mean that most of the work of the switch lines in toggling (a) nav menu entries and (b) links originating outside of the patron/circ apps to point to either AngularJS or Angular
15:41:27 <gmcharlt_> *lies in
15:42:04 <berick> yeah, every link that loads a patron, gets pointed to Angular.  that part's easy
15:42:37 <jeff> another option is to have no switch, and "don't upgrade" is your only switch. combined with potentially a longer support life for the previous release, that might make sunsetting the old interfaces more of a sure thing.
15:42:56 <berick> jeff: that would be my pref.
15:43:06 <berick> running them side by side will get messy no matter what, imo
15:43:32 <gmcharlt_> that still presupposes actively organized and broad testing
15:43:38 <berick> absolutely
15:43:57 * Bmagic scrolls up
15:44:07 * phasefx still remembers having three or so pull lists
15:44:37 <gmcharlt_> but I mislike the notion of potenially have 3.10.0 end up being intentionally full of regressions
15:44:44 <berick> but going back to my original proposal, if we merge the code without any menu/link updates, then we have a body of code we can start building on, which will have the affect of testing said code.  Eg. it's a lot easier to test a new Item Status UI then overhauling the whole patron UI.
15:44:49 <mmorgan> gmcharlt_++
15:44:57 <gmcharlt_> I wonder if we should consider an extended timeframe for 3.10, balanced with a brief 3.11
15:45:48 <berick> i wasn't trying to flip the switch for 3.10.  a full switch flip should happen basically the day after a major release is made
15:45:57 <berick> not halfway into the release cycle
15:46:46 <berick> if going all in is the consensus, then'd i'd say we do that the day after 3.10 is released or thereabouts
15:47:11 * mmorgan still favors reliable switch(es)
15:47:29 <berick> mmorgan: how do you mean?
15:47:36 <JBoyer> If I take gmcharlt_ 's point that is the suggestion. 3.10 doesn't have the branch and is supported a longer time, with 3.11 having a shorter cycle so there's only 1 huge change, am I following correctly gmcharlt_ ?
15:47:37 <mmorgan> These are probably the most used interfaces in many systems
15:48:03 <mmorgan> berick: Meaning not going all in and the "switch" being don't upgrade.
15:48:08 <gmcharlt_> JBoyer: one huge change and a largish change (acq)
15:48:50 <Dyrcona> Why not add it after 3.10, go all in, and 3.11 becomes 4.0 if the changes are that big?
15:49:32 <gmcharlt_> because anything that isn't turned until 3.11 will largely not get significant testing untikl 3.11 starts (is my fear)
15:50:04 <Dyrcona> Anyone testing leading up to the 3.11 release would be using the new interfaces.
15:50:29 <gmcharlt_> berick: let me ask you this - assuming a longer 3.10 cycle, is your branch essentially feature complete now? (barring the inevitable obscure YAOUS implementations and so forth)?
15:50:55 <phasefx> this is probably crazy, but how about we hold releases hostage until we get significant testing?  super long rc-1 for whatever holds the new stuff
15:51:16 <gmcharlt_> or are there significant known bits of the overall AngularJS circ app that aren't yet implemented in Angular?
15:51:20 <berick> gmcharlt_: we're using in production, w/ some patches I have not yet backported.  I think the patron messages stuff might need some tweaking as well
15:51:34 <berick> since it was concurrently developed
15:51:58 <berick> oh and the triggered events UI needs updating to match the new stuff
15:52:27 <gmcharlt_> what about circulation settings and options that KCLS doesn't use? anything not implemented?
15:52:55 <berick> gmcharlt_: it was built on the AngJS code, so in theory, it's all there.  but, i'm sure there's something
15:53:33 <gmcharlt_> well, yeah, there's always going to be something, but at the moment I'm just querying what are the known gaps
15:54:20 <gmcharlt_> and it sounds like - other than catching up with trigger events interfaces and notes/messages changes - there aren't significant ones?
15:54:41 <berick> no, those are the 2 menu items that are disabled in the UI right now
15:54:52 <berick> should be the only big things
15:55:27 <gmcharlt_> in that case, here's a thought
15:55:40 <gmcharlt_> 1. ensure that there's a Big Red Switch for insurance purposes
15:55:53 <gmcharlt_> 2. merge sooner rather than later, hopefully with some cleanup of the branch
15:56:16 <gmcharlt_> 3. target this for 3.10, then aim for broad testing
15:56:48 <berick> what if the Big Red Switch is a patch/commit?  making all the links/buttons have optional destinations is non-trivial
15:56:49 <gmcharlt_> 3a  including nudges, test systems, etc.
15:57:20 <gmcharlt_> 4. we agree to prepare to extend 3.10 into November, possibly early December
15:58:04 <gmcharlt_> 5. and by mid-November, review the state of the bugs against the Angular interfaces and make a go/no-go decision
15:58:36 <gmcharlt_> 5a. (which is potentially when the decision to apply the BRS as a commit, if that's what it has to be, gets made)
15:58:44 <gmcharlt_> (end of my list)
15:59:54 <gmcharlt_> but basically, combine (a) a quick merge so that the code doesn't age or diverge too much with (b) a much more intentional testing stance for a big change like this than may have been the case in the past
16:00:42 <gmcharlt_> without kicking the can to 3.11, since the testing needs to happen eventually and it would be good not to block the potentiall for normal enhancements to patrons/circ
16:00:54 <berick> gmcharlt_: ok, that makes sense.  and the BRS will be a commit that just reverses all the link/button/menu changes?
16:01:08 <berick> or a revert, basically
16:02:00 <gmcharlt_> if need be; a global setting / YAOUS would make it easier for ongoing testing if we're not confident enough to release 3.10 with $NewCirc, but if it's not feasible, it's not feasible
16:03:45 <berick> k.  do-able, was just hoping to avoid that, but I understand the desire.
16:03:54 <berick> a bold plan and I like it
16:03:56 <berick> gmcharlt_++
16:04:10 <mmorgan> gmcharlt_++
16:04:13 <JBoyer> berick++ gmcharlt_++
16:04:23 <mmorgan> berick++
16:04:25 <terranm> berick++ gmcharlt_++
16:04:32 <shulabear> berick++ gmcharlt_++
16:04:35 <mmorgan> BRS++ :)
16:05:35 * berick just created a lot of work for himself
16:05:55 <phasefx> the debt is never paid
16:06:19 <JBoyer> My attention is lightly split, but going on, we've got just 2 more topics; I expect they'll be relatively quick.
16:06:25 <JBoyer> #topic Consider merging bug 1979357? (phasefx)
16:06:25 <pinesol> Launchpad bug 1979357 in Evergreen "fixes for qatester failures" [Undecided,New] https://launchpad.net/bugs/1979357
16:06:30 <phasefx> yeah, someone push this
16:06:31 <JBoyer> #info Need this so we can get the QA tester going again; changes some pre-reqs for stretch and buster, and fixes a live test
16:06:41 <phasefx> also fixes a bug with cover image uploader for stretch
16:07:37 <Dyrcona> So, stretch is like EOL and we should drop it from our prerequisites.
16:07:44 <phasefx> sure
16:08:12 <JBoyer> Which is probably fine for 3.10
16:08:28 <Bmagic> berick++ gmcharlt_++
16:08:40 <JBoyer> but it is still listed for 3.9, even if not what you *should* do.
16:09:09 <Dyrcona> Right. I agree. I think I made a Lp for this some months ago.
16:10:15 <JBoyer> Dyrcona++ that you did. lp1947728
16:10:29 <phasefx> related to this, if anyone wants to provide qa servers with different supported distros, such that they start off pristine, can be installed on, and then made pristine again.. I'd be willing to get qatester running against all of them concurrently
16:11:11 <Dyrcona> I'll take a look at Lp 1979357. It sounds like we may need some of that for Ubuntu 22.04.
16:11:11 <pinesol> Launchpad bug 1979357 in Evergreen "fixes for qatester failures" [Undecided,New] https://launchpad.net/bugs/1979357
16:11:23 <phasefx> Dyrcona++
16:11:26 <mmorgan> Dyrcona++
16:11:42 <JBoyer> Dyrcona++ phasefx++
16:11:58 <mmorgan> phasefx++
16:12:18 <JBoyer> Ok, the next is something I may just drop here as a reminder that those of us with Powers(tm) on LP should check out
16:12:20 <JBoyer> #topic Review list of Bug Wranglers (terranm)
16:12:25 <JBoyer> terranm++
16:12:45 <terranm> https://launchpad.net/~evergreen-bugs/+members
16:12:51 <terranm> Andrea and I noticed at some point during the EG Conf that the bug wrangler list hadn't been cleaned up in a long time. There are 10 or so names I don't even recognize, and several more for people that are no longer actively involved.
16:12:57 <terranm> It seems like the list is overdue for an update, but I don't have the permissions to do that, nor would I feel comfortable making the decisions to downgrade people.
16:14:14 <terranm> I don't have a specific agenda, just thought I'd throw it out there.
16:14:46 <mmorgan> What are the powers of wranglers vs. drivers?
16:15:20 <mmorgan> Also doesn't need to be answered at this meeting :)
16:16:21 <Dyrcona> Drivers can modify releases, etc. Wranglers can modify bugs and target them to releases.
16:16:53 <JBoyer> I'll take this one on and can coordinate with other LP types on the lists or directly and clean things up. Worst case people can be added back to a group if they're removed unexpectedly.
16:17:05 <JBoyer> I do have to disappear though.
16:17:05 <terranm> JBoyer++
16:17:14 <JBoyer> #topic Announcements
16:17:17 <mmorgan> JBoyer++
16:17:18 <JBoyer> #info Next Meeting is August 9, 2022
16:17:24 <JBoyer> #endmeeting