15:01:58 <gmcharlt> #startmeeting Evergreen Development Meeting, 2018-12-12
15:01:58 <pinesol> Meeting started Wed Dec 12 15:01:58 2018 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:58 <pinesol> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:58 <pinesol> The meeting name has been set to 'evergreen_development_meeting__2018_12_12'
15:02:04 <gmcharlt> #info Agenda is https://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2018-12-12
15:02:08 <gmcharlt> #topic Introductions
15:02:16 <gmcharlt> #info gmcharlt = Galen Charlton, EOLI
15:02:19 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:02:26 <JBoyer> #info JBoyer = Jason Boyer, ISL
15:02:26 <berick> #info berick Bill Erickson, KCLS
15:02:29 <agoben> #info agoben = Anna Goben, Evergreen Indiana
15:02:33 <remingtron> #info remingtron is Remington Steed, Hekman Library (Calvin College)
15:02:35 <Dyrcona> #info Dyrcona = Jason Stephenson, CW MARS
15:02:43 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:02:47 <stephengwills> #info stephengwills at Maine Balsam Libraries
15:03:17 <Bmagic> #info Bmagic  = Blake GH, MOBIUS
15:04:41 <gmcharlt> #topic Action items from last meeting
15:04:49 <gmcharlt> #info JBoyer and csharp will work on a new Hatch release during the hack-a-way
15:04:53 <gmcharlt> JBoyer: how did that go?
15:05:16 <JBoyer> I believe it's ready to go, but it hasn't yet been committed.
15:05:50 <gmcharlt> OK
15:05:59 <berick> JBoyer: got the bug # handy?
15:06:05 <JBoyer> Once that's done and a new version number selected (berick and I talked about 0.2.0) the final installer can be built and put on the site, and the extensions updated in their respective browsers.
15:06:14 <JBoyer> will soon
15:06:34 <JBoyer> bug 1731922
15:06:36 <pinesol> Launchpad bug 1731922 in Evergreen "Firefox add-on for Hatch" [Wishlist,Confirmed] https://launchpad.net/bugs/1731922
15:06:50 <Bmagic> I have some more Hatch code related to the Dymo Printer, wonder if they can be combined for the release versioning number?
15:07:39 <berick> JBoyer: i can make sure nothing broke for chrome, but would prefer if someone else could sign off on the windows+firefox bits
15:07:50 <JBoyer> ++
15:08:02 * berick wonders if csharp is in the house
15:08:20 <berick> in any event, I'll note that in the LP
15:08:21 * Dyrcona was thinking we could assign testing with Firefox to csharp. :)
15:08:26 <JBoyer> The thing that's primarily being tested is the Windows installer. The extension can function without changes so long as the windows bits are updated.
15:08:45 <gmcharlt> ok
15:08:49 <gmcharlt> so I'll take this as
15:09:03 <gmcharlt> #info Next Hatch release is close
15:09:15 <JBoyer> +1
15:09:22 <gmcharlt> #action berick, JBoyer, csharp, et. al. will collaborate on final testing
15:09:43 <gmcharlt> Bmagic: we can discuss the Dymo stuff later in the agenda
15:09:51 <Bmagic> sure
15:10:50 <gmcharlt> but I note that since there's a direct Evergreen dependency with the "compatiblity mode", we may not want to couple that issue with the other stuff that's being worked on for the Hatch release
15:11:02 <gmcharlt> so, moving on
15:11:07 <gmcharlt> #topic OpenSRF release
15:11:19 <gmcharlt> #info OpenSRF 3.0.2 released during the hack-a-way
15:11:30 <gmcharlt> #info OpenSRF 3.1-beta now down to two bugs
15:11:34 <gmcharlt> bug 1803182
15:11:35 <pinesol> Launchpad bug 1803182 in OpenSRF "Websocketd graceful shutdown support" [Undecided,New] https://launchpad.net/bugs/1803182
15:11:56 <gmcharlt> ^ that one looks straightforward; I'll run it through its paces and will merge today
15:12:03 <gmcharlt> the other is bug 1729610
15:12:04 <pinesol> Launchpad bug 1729610 in OpenSRF "allow requests to be queued if max_children limit is hit" [Wishlist,New] https://launchpad.net/bugs/1729610
15:12:15 <gmcharlt> which I know miker will test, but it would be nice to have additional eyes on it
15:12:22 <gmcharlt> I'll write up draft release notes as well
15:12:42 <gmcharlt> request chunking will /not/ make it into 3.1-beta for lack of code
15:12:52 <gmcharlt> any questions?
15:12:58 * miker hangs head in shame
15:13:43 <JBoyer> Looks good, since I'm hoping to use websocketd in production soon I'll try to test those two branches too.
15:14:13 * Dyrcona is using websocketd in production and it is very reliable.
15:14:38 <berick> just noticed I need a better commit message on the websocketd patch...
15:14:50 <berick> will do that today
15:15:26 <gmcharlt> berick++
15:15:32 <jeff> berick++
15:15:47 <jeff> also using websocketd in production here. no complaints yet.
15:16:25 <gmcharlt> great
15:16:27 <gmcharlt> so moving on
15:16:32 <gmcharlt> #topic Evergreen release
15:16:42 <gmcharlt> dbwells
15:16:43 <gmcharlt> ?
15:17:01 <dbwells> A few small updates...
15:17:45 <dbwells> First, there is now a roadmap page available here:  https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.3  So far it just has berick's Angular staff catalog bug, so feel free to fill it in/out some more.
15:18:11 <dbwells> I did not carry over anything from 3.2 (which was actually mostly accomplished; good job all!)
15:19:31 <Dyrcona> We should probably info the roadmap.
15:19:37 <dbwells> Also, concerning monthly releases, I am suggesting that we do not do a December release.  I don't think activity warrants it, and I will be doing our 3.2 upgrade during the release window, so may not be able to swing it.  Here are the unreleased changes: https://launchpad.net/evergreen/+milestone/3.2.3
15:19:52 <dbwells> #info https://wiki.evergreen-ils.org/doku.php?id=faqs:evergreen_roadmap:3.3
15:20:01 <berick> +1 to skipping Dec. release
15:21:02 <dbwells> To be clear, just the (4) "Fix Committed" would get in, not that giant list :)
15:21:20 <Dyrcona> I'm OK with skipping the December release, too.
15:21:33 <gmcharlt> ... action: dbwells will close 40 bugs in the next 7 days... ;)
15:21:41 <Dyrcona> :)
15:21:51 <gmcharlt> seriously, I'm also OK with punting the next maintenance releases to January
15:22:15 <dbwells> Okay, that is all from me.  Any questions pertaining to 3.3?
15:23:11 <gmcharlt> none frmo me
15:23:24 <JBoyer> none here
15:23:57 <gmcharlt> #agreed no Evergreen maintenance releases will be made in December; they will be deferred to January
15:24:19 <Dyrcona> Looks good so far. I'll see if any of my recent bugs warrant being added to the road map.
15:25:19 <gmcharlt> ok, moving on
15:25:23 <gmcharlt> #topic Hatch
15:26:48 <berick> I am planning to help w/ the Dymo LP, at minimum code reivew and non-Dymo testing.
15:26:58 <gmcharlt> berick++
15:26:59 <berick> I don't have a Dymoe printer, alas
15:27:26 <berick> so kind of like the other Hatch issue, more help testing would be appreciated
15:27:37 <gmcharlt> I have one comment so far ... I dislike calling it "compatibility mode" as a printing setting
15:27:51 <dbwells> We've got a million Dymos and can help with testing.
15:27:59 <Bmagic> I solicited my libraries and was able to borrow one more long term.
15:28:01 <gmcharlt> as ultimately that's meaningless to the user
15:28:18 <Bmagic> I'm not married to the term either.
15:28:45 <berick> thanks dbwells
15:28:53 <Dyrcona> "broken mode?" :)
15:29:17 <gmcharlt> maybe instead (on the Evergreen side) have the interface present a list of potential "special" printer models
15:29:30 <berick> you can never go wrong with "Turbo"
15:29:40 <gmcharlt> along the lines of "[] Dymo [] Everything else" (or something along those lines)
15:29:49 <berick> gmcharlt: makes sense... other printers may need other tweaks
15:29:52 <Dyrcona> I think the release note could use a little more detail. I didn't have any idea what I changes would be required until I saw the example.
15:29:58 <JBoyer> We do kind of have a precedent in the way we do EDI worksrounds.
15:30:13 <gmcharlt> JBoyer: hopefully it won't need to get that involved
15:30:15 <JBoyer> This would just be the Dymo workaround.
15:30:15 <gmcharlt> wait
15:30:19 <gmcharlt> we're talking about printing
15:30:25 <berick> heh
15:30:38 <gmcharlt> Narrator: it will get that involved, and more
15:30:39 <JBoyer> gmcharlt++
15:31:05 <Bmagic> In the Hatch code, it's a fork based upon a boolean as to which way to render the HTML. It's first incarnation was a string match against the word "Dymo" but now is in the hands of the staff via the Evergreen setting
15:31:49 <gmcharlt> yeah, I can understand not wanting to do string matching there
15:32:08 <dbwells> berick: Looking at my "Dymo Labelwriter 400 Turbo" right now, it's not a bad name for the option ;)
15:32:10 <Dyrcona> I'm not too fussed about what it is called as long as the documentation is clear about what it does and what other changes it will require.
15:32:15 <Bmagic> In the end, it's true/false which fits nicely with the checkbox UI
15:32:23 <gmcharlt> but having the Evergreen end keep track of a set of special printer (dis)capabilities and send appropriate flags to Hatch could work
15:32:35 <berick> dbwells: oh yeah, I forgot they were called that...
15:33:23 <gmcharlt> anything else to say about Hatch?
15:33:53 <gmcharlt> #action Bmagic, berick, et al will poke more on the Dymo branch per feedback at this meeting
15:34:03 <gmcharlt> moving on
15:34:08 <gmcharlt> #topic Date of next meeting
15:34:27 <gmcharlt> so... shall we try 1/9?
15:34:42 <JBoyer> that
15:34:45 <Dyrcona> +1 # I've already got 2 other meetings on 1/2, now.
15:34:45 <JBoyer> s good for me.
15:34:53 <Bmagic> works for me
15:35:01 <berick> +1
15:35:26 <dbwells> +1
15:35:33 <gmcharlt> #agreed Next development meeting will be held on 2019-01-09
15:35:48 <gmcharlt> #topic Evergreen 2019 Hack-A-Way
15:35:54 <agoben> In the survey I sent out, Nov 4-6 took the most top votes. Oct 21-23 took second place. Halloween week got a lot of meh.
15:35:54 <agoben> Are you ok with election week again after all?
15:36:31 <Dyrcona> The dates were all the same to me at this point, tbh.
15:37:28 <JBoyer> What was the spread between 1st and 2nd ?
15:37:30 <rhamby> I'd rather not do election week personally.  We had some complaints at the hack-a-way this year for that reason.
15:37:53 <agoben> 8 ppl responded.  5 chose election week as their number 1 choice
15:37:58 <rhamby> (complaints might be too strong a word ....)
15:38:03 <JBoyer> Oh.
15:38:11 <agoben> No one went for halloween week as a first choice and 3 picked the week before that
15:38:43 <gmcharlt> we are all clearly committed to feeding trick-or-treaters...
15:39:06 <agoben> Be a shame to miss out on the candy and costumes, indeed.
15:39:10 * Dyrcona changes his vote to make it a tie. :)
15:39:12 <JBoyer> Or being trick-or-treaters, no judging here. ;)
15:39:35 <agoben> But Halloween week was the winner of the #2 choice (again 5 participants)
15:39:42 <gmcharlt> agoben: how long do you want to keep the survey open?
15:39:44 <berick> Hackfest Spooktacular!
15:40:07 <agoben> I would like to lock in the contracts next week so we're not holding 3 weeks hostage.
15:40:29 * JBoyer puts flashlight under chin, "This behavior only happens when debug logging is turned off!"
15:41:00 <dbwells> JBoyer: I got chills
15:41:00 <berick> we just work on EDI all week
15:41:17 <remingtron> JBoyer++
15:41:18 <JBoyer> berick wins, I'm not going
15:41:39 <gmcharlt> I have a mild preferance against not doing it during election week, but only mild
15:41:54 <gmcharlt> (it would be /much/ stronger if we were talking about 2020)
15:42:22 <agoben> I can leave it open until Monday if you want to just leave it in the hands of the stats at that point?
15:42:38 <gmcharlt> that makes sense to me
15:42:58 <agoben> Since fewer than half of the expected participants responded, it might be best to get a reminder out to vote now ;)
15:43:02 <berick> agoben: maybe send a reminder to the lists, including a note about election day
15:43:05 <berick> :)
15:43:09 <Dyrcona> I was going to suggest Friday evening with an email sent explicitly with the topic of vote now or don't complain.
15:43:34 <agoben> I'm out on Friday, but I can send out a reminder tomorrow to that effect.
15:43:54 <agoben> Thanks for the input; the decision will be posted next week!
15:43:57 <berick> agoben++
15:44:10 <gmcharlt> agoben++
15:44:10 <Dyrcona> I meant send a reminder now, and close the poll on Friday evening. Sorry that I wasn't clear.
15:44:14 <remingtron> agoben++
15:44:19 <Dyrcona> agoben++
15:44:48 <agoben> I'll send it out first thing tomorrow.  Have to buzz now.  Thanks everyone!
15:45:07 <gmcharlt> #topic Angular Staff Catalog
15:45:32 <berick> ok, questions about that...
15:45:48 <berick> i am continuing work on it as noted in the LP.
15:45:52 <berick> and i've done a bit more since my last update
15:46:09 <berick> I strongly suspect it will not be in a state to replace the existing catalog by 3.3
15:46:28 <gmcharlt> I'm generally in favor of making it available in 3.3 on a beta basis (and making it easy to switch via a workstation pref?)
15:46:42 <berick> gmcharlt: that's exactly my question
15:46:48 <berick> and what I was imagining -- workstation pref
15:47:00 <berick> and when it's enabled it will be clearly /other/
15:47:03 <berick> and not a replacement
15:47:04 <gmcharlt> but I'm wondering if we can go so far as to also deprecate the old embedded OPAC at the same time, with a stated goal of removing it in 3.4
15:47:12 <JBoyer> +1 to having the code in core, possibly just have 2 entries in the cat menu "Search Catalog" and "Testing Catalog" or similar.
15:47:14 <Dyrcona> I'd be inclined to leave it out.
15:47:28 <berick> Dyrcona: well, it's already in there
15:47:37 <berick> or do you mean the menu entry?
15:47:43 <JBoyer> Oops, I forgot that was the case
15:47:53 <miker> gmcharlt: I don't know that I'd be comfortable with that
15:48:23 * Dyrcona rephrases: I'd be inclined to not expose it easily.
15:48:28 <berick> Dyrcona: gotcha
15:48:35 <miker> is it Decided(tm) that the embedded catalog must die? (sorry if that's been made clear or is obvious)
15:48:38 <JBoyer> Does seem a little early to deprecate embedded tpac in 3.3, though
15:48:47 <berick> it could still be easily tested even if it weren't listed in the menu, of course
15:49:09 <berick> miker: that is certainly my hope, but no decisions on that have really been made.  also why I wanted to raise the topic
15:49:21 <JBoyer> miker, if it went up to a vote among circ staff they wouldn't think twice, as the iframe eats the shortcut keys.
15:49:23 <gmcharlt> miker: in the long run, I don't think it does us much good to support two different staff OPACs (although obviously there will need to be a way to quickly open a bib in the OPAC)
15:49:31 <berick> make sure I'm tilting at the correctly shaped windmills
15:50:44 <dbwells> Perhaps we could state a goal of having the new catalog be the default in 3.4 rather than deprecate the TT2 right away, then see how that unfolds.
15:51:10 <berick> to give some idea of scope, removing tpac means implementing a /lot/ of Angular code
15:51:21 <Dyrcona> This new catalog is only for the web staff client, correct? TPAC is still there for patrons.
15:51:22 <miker> well, the tenticals that are reaching into the OPAC from ng today are really pretty well constrained ... so a goal of just not breaking it seems doable. and, what dbwells said. let's just see
15:51:39 <berick> Dyrcona: correct, just staff
15:51:53 <Dyrcona> Thanks, just making sure I was on the same page.
15:52:53 <miker> tpac is only going to get more features, too, so is parity in the staff pac something we should (can?) commit to?
15:53:25 <berick> miker: i don't think parity should necessarily be a goal.  to me, they are 2 different things entirely
15:54:05 <Dyrcona> what berick said with the addition that I can imagine there being features useful for patrons and not staff and vice versa.
15:54:14 <jeffdavis> there is an awful lot of functional overlap though
15:54:33 <miker> berick: thanks.  that's something we may have to sell, since that's a touted benefit, but we shall see. maybe opinions have evolved :)
15:54:36 <berick> jeffdavis: agreed, and if we move to an Ang public catlog, much code will be shared
15:55:27 <jeffdavis> Is that the community's overall goal? (not against it fwiw)
15:55:39 <berick> miker: agreed, I don't mean to take it for granted.  I strongly suspect the benefits will far outweigh any lost functionality, though.
15:56:33 <miker> jeffdavis: I mean ... I'm for a web app, but then, I was for it the first time, too ;)
15:58:01 <jeffdavis> I've been worried about having to support separate parallel public and staff OPACs. If we do plan to make the angular staff OPAC the basis for a new public OPAC in future, that eases some concern there (although it raises other concerns re existing customizations etc for the current TPAC).
15:59:00 <miker> jeffdavis: yeah, that has to be solved for sure. one shouldn't need a compiler to change some css ;)
16:00:01 * gmcharlt leans more towards (a) staff catalog as an entity that can be optimized for staff workflows and (b) avoids the jankiness and speed issues of the embedded TPAC
16:00:02 <berick> i guess, stepping back, is my assumption that we want to chip away at the iframes and generally move toward Angular for the staff UI not fully agreed upon?
16:00:46 <JBoyer> Can everyone get behind "keep working on it aiming for 3.4, don't deprecate the embed in 3.3, and expose it locally if you like by editing navbar.tt2?"
16:01:00 <miker> anyway, I've pulled us off into the weeds enough. to the original point, I'm not for calling the embedded tpac deprecated and set for removal as 3.4
16:01:32 <gmcharlt> I realize that deprecating it in 3.3 is aggresive, and arguably too agressive
16:01:52 <gmcharlt> but I am very concerned in the long run about this turning into "catalog" and "alt. catalog" a la the XUL serials interfaces
16:02:17 <berick> i'm fine seeing how it goes.  i suspect we'll get more direction from users after more public discussion as well.
16:02:18 <gmcharlt> so I think berick's latest question is kinda an existential one
16:02:39 <miker> berick: that's agreed upon generally, yes. it can continue to work in Ang, right? it's just shoving data and functions into the iframe's window, which I assume Ang can do as well as AngJS?
16:03:23 <berick> miker: well, you skipped the part of my question about chipping away at the iframes
16:03:36 <miker> berick: heh, well, there are lots of them
16:04:02 <miker> I mean, obv removing the dojo iframes is a goal and underway
16:04:31 <gmcharlt> and IMO the TPAC iframes really should go as well. the current embedded TPAC is slow
16:05:43 <berick> that's my take as well.
16:05:45 <miker> gmcharlt: that's totally fair
16:05:47 <jeffdavis> I think deprecating in 3.3 is too aggressive, but a soft goal of defaulting to angular OPAC in 3.4 (+ deprecating TPAC in client) is ok with me.
16:06:24 <gmcharlt> I also think that it should be a bit easier than editing navbar.tt2 (or the equivalent) to make it avaialble in 3.3 for testing purposes
16:06:28 <gmcharlt> YAOUS, perhaps?
16:07:30 <JBoyer> A reasonable compromise; that way Library A can get their staff started early even if Library B isn't sure how this whole "online" thing is going to shake out.
16:07:59 <miker> I'm mainly curious as to whether we can, or should, write an Ang egFrame component so we can make use of what's there, or will the whole catalog in the client continue to be AngJS until we switch?
16:08:43 <berick> miker: as it stands, I'm making the Ang catalog jump to AngJS for anything it's not prepared to deal with
16:08:51 <berick> to ease integration / testing
16:09:05 <berick> e.g. it jumps to AngJS for holdings maintenance, holds lists, and a few others
16:09:38 <berick> but AngJS stays within its own sphere for now
16:09:48 <berick> it never jumps back to Ang (unless you use the back button)
16:10:16 <berick> which as it stands would be confusing for most staff, but certainly usable / testable
16:10:37 <miker> sure, that makes sense
16:11:05 <berick> but to answer your questoin, I think yes, there has to be a single catalog that's the main one
16:11:11 <berick> which will be angjs until it's not
16:11:47 <miker> ok, thanks
16:12:27 <miker> berick: one last thing on Ang catalog...
16:13:27 <miker> do you think there will need to be some new services (or at least API calls) to do some of what the mod_perl code does now, like interfacing with memcache for various things (recent staff searches, etc)
16:13:44 <miker> or, I guess /a/ new services to contain some APIs
16:14:18 <miker> (asking because that might be our chance to move some of the private-service code out of tpac, improving that along the way)
16:14:19 <berick> miker: yes, definitely.  i've already created some and copied-ish some TPAC code into public APIs for my working branch
16:14:38 * miker should really just look a the code
16:14:45 <miker> thanks for bearing with me
16:14:59 * miker places the mic gently on the edge of the stage and steps back
16:15:26 <berick> i've added a bit to return some tidy holds info (so that UI doens't have to repeat all of that) and copied the browse bits
16:15:27 * JBoyer can't wait for the hip-hop remix of the discussion.
16:15:29 <berick> i think that's it so far
16:15:41 <berick> miker: :)
16:16:02 <gmcharlt> ok, so I think to sum up, it sounds like we have
16:16:28 <gmcharlt> (a) general willingness that the Ang staff OPAC be made available in 3.3 in some fashion for testing
16:17:04 <gmcharlt> (b) a new shared sense of what the issues will be around when (or if) to make a full transiition to it at some point
16:17:09 <gmcharlt> accurate?
16:17:29 <miker> +1
16:17:35 <JBoyer> +1
16:17:39 <berick> +1
16:17:52 <jeff> +1
16:18:28 <jeffdavis> +1
16:18:49 <gmcharlt> ok, we're 18 minutes over, so I'm going to call this meeting done and dusted
16:18:53 <gmcharlt> #endmeeting