15:13:07 <dbwells> #startmeeting Development Meeting, 23 April 2015
15:13:07 <pinesol_green> Meeting started Thu Apr 23 15:13:07 2015 US/Eastern.  The chair is dbwells. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:13:07 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:13:07 <pinesol_green> The meeting name has been set to 'development_meeting__23_april_2015'
15:13:34 <berick> dbwells++
15:13:39 <dbwells> #info Agenda is http://evergreen-ils.org/dokuwiki/doku.php?id=dev:meetings:2015-04-23
15:13:46 <dbwells> #topic Introductions
15:14:06 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
15:14:14 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
15:14:19 <jeffdavis> #info jeffdavis = Jeff Davis, Sitka
15:14:23 <berick> #info berick Bill Erickson
15:14:28 <kmlussier> #info kmlussier is Kathy Lussier, MassLNC
15:14:36 <csharp> #info csharp = Chris Sharp, GPLS
15:14:39 <berick> oops, forgot to add KCLS
15:14:54 <csharp> #info berick is with KCLS, y'all
15:15:08 <dbs> #info dbs = Dan Scott, Laurentian University
15:15:12 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
15:15:16 <phasefx> #info phasefx = Jason Etheridge, Equinox
15:15:17 <berick> heh
15:15:27 <bshum> #info bshum = Ben Shum, Bibliomation
15:16:25 <dbwells> ok
15:16:36 <dbwells> #topic Action Items from Last Meeting
15:16:51 <dbwells> #info berick, gmcharlt, and eeevil will add a response to the chromium localhost ws bug
15:17:02 <berick> yeah, they shut everyone out
15:17:22 <eeevil> #info eeevil Mike Rylander, ESI
15:17:25 <gmcharlt> #info gmcharlt Galen Charlton, ESI
15:17:44 <dbwells> berick: What exactly does that mean for our concerns?
15:18:04 <dbwells> We're out of luck, or something else?
15:18:09 <berick> that we have limited (no?) ability to affect change
15:18:13 <jeff> https://code.google.com/p/chromium/issues/detail?id=378566#c77 is the best summary.
15:18:14 <eeevil> dbwells: honestly, not much, given https://news.ycombinator.com/item?id=9210484
15:18:22 <dbs> "Star the bug and maybe we'll think about it"
15:18:27 <eeevil> IMO, I should say
15:18:52 <jeff> > we will not be making action to block these loads until there is a viable, standards-track (although perhaps not necessarily yet standardized) solution that enhances security and preserves utility
15:18:58 <jeff> > If you currently rely on such communication, you MUST be prepared to update your products at a point in the future to whatever is developed to mitigate these issues. The current solution IS NOT viable long-term.
15:20:05 <jeff> The sentence before that is a bit annoying:
15:20:07 <jeff> > Discussion about what a viable long-term path means will happen in the W3C. The most likely place for this discussion is where it was first considered - public-webappsec@. However, public-webappsec@ is presently not chartered for this discussion.
15:20:29 <jeff> essentially, "the list where we think this discussion belongs is not currently charted for this discussion"
15:21:11 <dbwells> Does someone want to summarize an update with a #info tag?  I'm not qualified to comment on this at all, I think.
15:21:25 <berick> so when this discussion, which has no place to exist, happens, we can potentially contribute.
15:22:10 <dbwells> Ok, I'm starting to understand the situation now
15:22:16 <berick> jeff: where are you reading that?
15:22:17 <jeff> There were some alternate approaches brainstormed in Boston (useful for cases where you're not able to run Hatch but still want receipt printing) which could bear further brainstorming. For the most part, we're in a "wait and see, remain aware, star the issue and keep our ears/eyes open" mode.
15:22:31 <berick> right
15:22:50 <jeff> berick: mostly from comment 77 on the issue in question -- I linked above: https://code.google.com/p/chromium/issues/detail?id=378566#c77
15:23:04 <berick> jeff: oh, duh, thanks
15:24:05 <dbwells> ok, so
15:24:10 <dbwells> #info For the most part, we're in a "wait and see, remain aware, star the issue and keep our ears/eyes open" mode.
15:24:25 <dbwells> Any more on this before moving ahead?
15:24:31 <jeff> Not from me.
15:24:39 <berick> nor from me
15:24:49 <jeff> I'm interested in further discussions on the subject at the conference.
15:25:13 <eeevil> +1 to that
15:25:25 <dbwells> #topic OpenSRF Release Update
15:25:48 <dbwells> Nothing in the agenda, any update on that? (gmcharlt, or others)?
15:26:29 <gmcharlt> #info gmcharlt will cut an OpenSRF release by the EG conference - or AT the conference, if it comes to it
15:26:51 <dbwells> gmcharlt++ # thank you
15:27:14 <dbwells> moving on...
15:27:16 <dbwells> #topic Evergreen Release Updates
15:28:05 <dbwells> berick: please go ahead, even just to reiterate what's already in the agenda, if you don't mind.
15:28:13 <berick> sure thing
15:28:25 <berick> 2.8.0 was set loose upon the world
15:28:39 <berick> 2.8.1 probably after the EG conf, unlesss there's a need to do it sooner
15:29:38 <kmlussier> If there were no conference, what we typically be the point release date?
15:29:57 <bshum> So actually I was hoping to get a release out sooner for 2.7
15:30:03 <dbwells> berick: There was the bug I worked on with bshum affecting fine generation for catch-up fines on lost-returned items.  I'd hope to see that out sooner rather than later.
15:30:05 <bshum> Since there's some backlog of stuff
15:30:14 <jeff> kmlussier: calendar says April 15, May 20
15:30:15 <bshum> And yeah, some pretty critical fixes for 2.8
15:30:19 <kmlussier> IIRC, there has been a fine generator fix since the release, which seemed like it might be important to get out.
15:30:26 <bshum> That we probably don't want people upgrading into
15:30:35 <kmlussier> Oh, sorry. dbwells is too quick for me. :)
15:30:50 <eeevil> and there's the common-attribute search speed fix
15:30:52 <berick> kmlussier: 3rd Wed. of each month, I believe
15:30:58 <eeevil> which is running nicely in production
15:31:14 <kmlussier> eeevil: That's good news.
15:31:18 <bshum> We're a bit behind schedule, but maybe we can commit to getting a release cut this month anyways.
15:31:23 <berick> alright.. sounds like we may have a release to cut sooner than later
15:32:01 * jeff bookmarks the descripton on commit 749e63f
15:32:01 <pinesol_green> [evergreen|Dan Wells] LP#1443952 Move overdue restore above lost void/adjustment - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=749e63f>
15:32:03 <csharp> eeevil: were you able to assuage your concerns about the inverse use case with uncommon attributes still working quickly?
15:32:10 <kmlussier> Also, when I did the web site updates, I didn't put 2.6 in security release only mode because we hadn't reached a full year after its release. Should it get one more point release before we move it to security only?
15:32:21 <dbwells> We've got one more standard release for 2.6.  I'm game to cut it whenever bshum and berick are ready with theirs.
15:32:57 <berick> next week works for me
15:33:00 <eeevil> csharp: in a word: yep
15:33:08 <csharp> eeevil++ # awesome
15:33:20 <bshum> Next week sounds good to me too actually.  Wednesday?
15:33:42 <dbwells> Wednesday works for me.
15:33:45 <berick> same here
15:34:28 <dbwells> #info 2.8.0 was set loose upon the world
15:35:02 <dbwells> #agreed 2.8.1 and other maintenance releases will be cut on Wednesday, April 29
15:35:49 <dbwells> #topic QA Discussion
15:36:00 <berick> i added that...
15:36:05 <jeff> berick++
15:36:18 <berick> so, it didin't really take hold for 2.8 for various reasons.
15:36:32 <berick> i'd really like some input on the wiki doc before we start forcing anything
15:37:15 <berick> and if we're goign to start requiring QA contributions for 2.9, we need to solidify the plan now-ish
15:37:41 <jeff> short of boiling the ocean, what do you think our approach should be for "this changes the behavior of something large and complex which has no existing tests"?
15:37:57 <jeff> (not that this particular ocean doesn't deserve boiling...)
15:38:16 <berick> jeff: do you mean areas of the code where there is no test structure?
15:38:19 <jeff> case-by-case exception with a high bar, but discretion to the RM?
15:38:26 <jeff> berick: yes, exactly.
15:38:50 <berick> honestly, if we could people started on using the test structure we have, that would be a big win
15:38:58 <bshum> Speaking of RM, who'll that be for 2.9 :)
15:39:43 <berick> bshum: yeah, this conversation makes me think again about nominating RM's earlier in the process
15:40:02 <bshum> Yeah, I think we should start thinking like that.
15:40:16 <dbwells> If we want the RM to make calls on "tested enough"-ness, we'll more or less need the RM to approve everything.  That's pretty far from what we've done before, but certainly exists in other projects, from what I'm told.
15:40:40 <kmlussier> I don't feel qualified to comment on the wiki page, but if there is anything somebody like me can do to help with this, let me know.
15:41:18 <jeff> dbwells: I was thinking more along the lines of "has tests == good, anyone can merge", vs "no tests because REASONS, merge is at RM discretion"
15:41:38 <dbwells> jeff: makes sense, thanks for clarifying
15:41:48 <gmcharlt> dbwells: from somebody who has been RM in such a kind of project... that is a big burden to put on the RM
15:42:54 <dbs> Are tests in place for the web staff client, along the lines of https://docs.angularjs.org/guide/unit-testing ?
15:42:55 <dbwells> gmcharlt: I can imagine.
15:43:02 <berick> expanding on jeff's last comment.. "no tests because no framework exists to test this" would cover a lot things
15:43:26 <berick> that would leave a fairly limited number of cases where the RM would have to decide
15:43:37 <gmcharlt> now giving the RM more mental space to throw things back if not done enough -- and have those decisions not be nibbled to death by the Ducks of Merge It Now -- is something that would be a step forward
15:44:15 <dbwells> the endless nibbling!
15:44:34 <csharp> probably an obvious point, but it also raises the bar for a qualified RM
15:44:40 <jeffdavis> Is there a tag in LP meaning "has code, needs tests"?
15:44:57 <bshum> jeffdavis: needsignoff ?
15:45:55 <jeffdavis> Do we want something more specific?
15:46:12 * gmcharlt is inclined to think so - at least to try it out
15:46:15 <jeffdavis> Signoff to me implies "I've tried this, it works on my system."
15:46:16 <gmcharlt> "needstest"?
15:46:22 <jeff> needstests? needsqa?
15:46:22 <gmcharlt> er, needstests
15:46:33 <gmcharlt> (not One Test To Rule Them All)
15:46:35 * csharp is having deja vu
15:46:57 <jeff> csharp: that might be bad. is it bad?
15:47:10 <dbs> #qualityisjob1
15:47:22 <jeffdavis> heh
15:47:22 <kmlussier> dbs++
15:47:43 <csharp> jeff: I thought we'd had this same discussion, but it was probably for another LP tag :-)
15:48:25 <gmcharlt> csharp: different tag
15:48:31 <dbwells> Well, this topic could be a meeting unto itself, but we need to keep moving.   These are good thoughts, so feel free to add them as ideas to the wiki document, or keep chewing on them, and we can reconvene the conversation during the conference.  Does that sound alright?
15:48:34 <csharp> gmcharlt: thanks ;-)
15:49:00 <bshum> dbwells: +1 to discussing at the next dev meeting (which is likely at conference)
15:49:12 * gmcharlt tosses out a wild idea
15:49:25 <gmcharlt> do we want to make QA the Official Theme (TM) of the dev portion of hackfest/
15:49:28 <gmcharlt> ?
15:49:30 <jeff> dbs: there are some tests for the angular bits, using karma. commit 75e466e contains one example. i can't say what coverage is like.
15:49:30 <pinesol_green> [evergreen|Bill Erickson] LP#1402797 browser client interval parser - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=75e466e>
15:50:34 <jeff> gmcharlt: if nothing came out of the hackfest but every interested contributor was better equipped to write tests... i'm not sure i'd be disappointed.
15:51:01 * gmcharlt sources a troop of cats to give out at the conferences
15:51:06 <gmcharlt> very special cats
15:51:24 <gmcharlt> cats who hiss ... if one does a git push with adding something to t/
15:51:33 <gmcharlt> *without
15:51:47 <jeffdavis> "hiss" is, fortunately, gentler than I had anticipated
15:51:57 * eeevil dons his headphones of hiss avoidance
15:52:17 <dbwells> gmcharlt: I'd be up for QA time during the hackfest.
15:52:48 <csharp> #info gmcharlt's Cats of Doom: http://cat.evergreen-ils.org.meowbify.com/
15:52:54 <jeff> "QA time" might be easier to pull off. :-)
15:53:04 <jboyer-isl> I could certainly use an intro. I felt a little bad about how much went into the "delete acpl" commits without any tests but human ones.
15:53:27 * gmcharlt is more than happy to put together some starting material for a QA time
15:53:41 <dbwells> #action AllTheDevs will read and think about berick's QA page, and come to the conference ready to discuss and take action
15:53:57 <berick> you_all++
15:54:07 <kmlussier> you_all++
15:54:35 <jeff> too late for meetbot, but there is a thread on the localhost websockets thing that might be worth reading for those keeping tabs: https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0135.html
15:54:41 <dbwells> New Business
15:54:57 <dbwells> #topic berick proposes we vote on a set day / time for monthly meetings
15:55:04 <jeff> +1
15:55:30 <bshum> +1
15:55:35 <bshum> We used to do that though.
15:55:42 <bshum> It didn't always work out, but we can try again.
15:56:36 <jeffdavis> +1
15:56:46 <berick> i'm happy to post a poll
15:57:01 <gmcharlt> +1
15:57:03 <berick> to see if we can get a decent looking time
15:57:13 <bshum> berick++
15:57:18 <berick> if it's all over the place, maybe reconsider
15:57:34 <dbwells> They have all recently been at 3:00pm Eastern, but the day shifts around.  Can we agree on 3:00pm already?
15:57:44 <kmlussier> I'm in favor of it, but I think we should monitor it. If it looks like people forget about meetings (which is what previously happened), we may want to reconsider.
15:57:50 <csharp> dbwells: works for me
15:57:53 <kmlussier> However, meeting reminders should help with that issue.
15:58:29 <dbwells> I guess we can just wait for the poll, too.
15:59:01 <jeff> or possibly a single-option doodle poll to help determine if a given month's meeting will be lightly attended and thus should be re-scheduled. dunno. let's try a change and see.
15:59:12 <dbwells> #action berick will set up a poll for a set meeting day/time for dev meetings
15:59:32 <dbwells> #topic Release notes for point releases (kmlussier)
15:59:43 <berick> cool, thanks everyone
15:59:59 <kmlussier> I'll keep this quick. There has been some discussion here recently about adding point releases to the release notes.
16:00:32 <kmlussier> I wonder if there is general consensus that we should move in this direction.
16:01:01 <kmlussier> If so, I would be willing to work with berick on the 2.8 point releases to get the release notes added.
16:01:08 <csharp> +1
16:01:45 <jeff> +1
16:02:29 <berick> kmlussier: like, at the bottom of the 2.8 release notes, we would append the 2.8.1. notes, then 2.8.2, etc.?
16:02:39 <berick> instead of overwriting the 2.8 original notes
16:02:46 <dbwells> I was going to ask something similar.
16:03:11 <kmlussier> Yes, I think bshum had suggested that approach at one point. I like that idea.
16:03:13 <csharp> that's what I had in my mind
16:03:13 <bshum> Right, I started a new section concept for it in the rel's
16:03:22 <bshum> But we have to adopt it permanently, etc.
16:03:32 <dbwells> Looking at this page: http://docs.evergreen-ils.org/2.8/ , would they show up as addenda in section II?
16:03:34 * bshum could have named it better
16:03:37 <kmlussier> I dont' think we want to run a script every time we have a point release like we do for the major releases.
16:04:03 <bshum> Right, I just called it "Bug Fixes"
16:04:11 <bshum> But didn't name the exact number release of when they occur
16:04:33 <gmcharlt> well, if it's actually fully scripted...
16:04:35 <jeff> grouping by point release would probably be helpful.
16:04:58 <kmlussier> Yes, I was thinking having a 2.8.1 as a section under bug fixes, then 2.8.2, etc.
16:05:06 <dbs> top (most recent first) rather than bottom is more typical I think?
16:05:07 <csharp> this is what postgres does: http://www.postgresql.org/docs/9.4/static/release.html
16:05:09 <jeff> it's nice to have something other than launchpad/git logs confirm in which point release we think a specific bug was fixed.
16:05:27 <kmlussier> dbs: Ah, yes, right. That would make sense.
16:05:36 <dbs> but +1
16:06:01 <dbwells> Ok, it seems like we're generally all on the same page, and we can wait and see what kmlussier, et al come up with.
16:06:06 <berick> +1
16:06:20 <dbwells> kmlussier++
16:06:43 <dbwells> Moving on to Feedback for New Features Under Development
16:06:59 <dbwells> #topic Web client: Keyboard shortcut issues
16:07:38 <eeevil> That's mine
16:08:00 <eeevil> so, they exist. and work. except ... when an input form element is selected
16:08:31 <eeevil> I'd like to get more eyes on that problem
16:08:36 <jeff> since you've raised it as an issue, i'm guessing that's an inherent limitation and not just a bug?
16:09:10 <eeevil> jeff: right. it seems to be, at least, a limitation of the angular wrapper to mousetrap
16:09:57 <eeevil> as mousetrap itself supplies a way to make them work when form input elements (specifically, text, textarea, and select) are focused
16:10:16 <eeevil> but, because angular builds the interface in stages
16:10:49 <eeevil> inner-scope form elements don't get the appropriate event handlers injected
16:10:53 <eeevil> (AFAICT)
16:11:00 <jeff> do you have a branch or bug for those with interest?
16:11:34 <eeevil> it's just all of the code. it's existed since sprint1
16:11:38 <berick> eeevil: i'm curious if you've tried stock cfp.hotkeys stuff without the local eg-navbar-template stuff in navbar.js
16:11:52 <jeff> eeevil: ah, even easier
16:12:32 <dbwells> #info keyboard shortcuts are failing when an input form element is selected.  Suspected cause is the angular wrapper to mousetrap.  eeevil is asking for more eyes on the problem.
16:12:40 <eeevil> berick: since it's not creating an isolate-scope, I haven't
16:12:48 <berick> so, there's hotkeys, hotkeys within angular, then our local directive to make hotkeys look a little more like how they looked in the xul client.  if that last part is the problem, we could remove/modify that pretty easily, i imagine
16:12:52 <berick> eeevil: k
16:12:52 <jeff> Hrm. webby doesn't like F1/F2. I get a 404. Will poke further.
16:13:34 <kmlussier> F1 works for me
16:13:38 <eeevil> berick: right, I don't think it's your wrapper.
16:13:45 <berick> eeevil: ah, ok
16:13:47 <eeevil> WFM also... :)
16:14:16 <jeff> logging in at https://webby.evergreencatalog.com/eg/staff/ and hitting F1 takes me to https://webby.evergreencatalog.com/circ/patron/bcsearch/webby.evergreencatalog.com/eg/staff/
16:14:23 <jeff> (off topic for meeting)
16:14:25 * berick remapped F1 to 'switch to desktop 1' locally because I can't be bothered with modifier keys
16:15:14 <eeevil> my one idea so far is to use mousetrap directly and have hotkeys wire themselves up after the UI is fully rendered
16:15:53 <dbwells> Sounds like we have a couple parties interested in offering assistance here, but we should try to wrap up the meeting before we get too deep, I think.  Is that alright?
16:16:07 <berick> hm, it's an angular package
16:16:20 <berick> i mean, it's designed for angular.
16:16:32 <berick> i'm not sure how it would work w/o angular
16:16:36 <eeevil> dbwells: yep, that's fine
16:16:58 <dbwells> eeevil: thanks, moving along for now...
16:17:00 <dbwells> #topic ACQ blanket orders proposal
16:18:08 <dbwells> berick: It sounds interesting.  I don't think we do anything like that here.
16:18:45 <kmlussier> I think we might have some libraries that might be interested in using it.
16:19:03 <berick> so, yeah, just curious if anyone else does this kind of thing. i could swear i heard the concept from non-kcls people
16:19:06 <berick> but i could be crazy
16:19:18 <kmlussier> One question that was raised here was what happens at end of fiscal year if they are configured to roll over encumbrances. Will the direct charges roll over too?
16:19:44 <berick> kmlussier: yes, all fund debits (encumbrances in this case) are treated equally for rollover
16:20:11 <jeffdavis> I'll pass along the bug to our acq folks for comment.
16:20:16 <berick> thanks, jeffdavis
16:20:34 <kmlussier> berick: We do have libraries that do blanket invoices. I'm thinking they might like to add then to the PO so that the funds could be encumbered before the items are received.
16:20:40 <csharp> same here
16:20:43 <kmlussier> s/then/them
16:21:05 <berick> kmlussier: cool, that's the idea
16:21:17 * kmlussier plans to load it on a VM when she has time
16:22:32 <berick> kmlussier++
16:22:39 <berick> thanks everyone.
16:22:49 <dbwells> berick: I'll ask our acq people about it, too.  You never know what they might be doing to make things work :)
16:22:56 <berick> dbwells: :)
16:23:17 <dbwells> so, last but not least
16:23:20 <dbwells> #topic Overdrive API
16:23:38 <kmlussier> I added that one to the agenda. I'm still not clear as to what steps need to be taken to move it forward.
16:23:56 <kmlussier> We have a lot of interest here in seeing it merged to Evergreen.
16:24:17 <jeff> there were some missing parts last i looked, with regard to support in consortium and different auth methods
16:24:34 <jeff> i looked just enough to say "this won't work for us", but didn't go much further.
16:24:41 <jeff> have others reviewed it more?
16:25:05 <jeffdavis> jeff: Would you be willing to file a bug report about that? I've done a small amount of tweaking in that regard but not a lot.
16:25:06 <kmlussier> I suspect our auth methods would line up with what Sitka's using.
16:25:40 <jeffdavis> LP project page is https://launchpad.net/overdrive-eg-opac, bugs can be filed there
16:26:05 <jeffdavis> I can think of two pieces that might help to get more folks trying it out.
16:26:14 <jeffdavis> 1. Documentation. This has been on my todo list for a while.
16:26:27 <jeff> jeffdavis: can you summarize your environment with regard to auth methods, what patron identifier is used, and if you have just a single overdrive account for the entire consortium or if you have per-system, and if there's any use of "overdrive advantage" (where systems participate in a large collection but can then ALSO add items that only their patrons get)?
16:26:29 <jeffdavis> 2. Testing credentials that can be shared among EG developers.
16:26:35 <dbwells> #link https://launchpad.net/overdrive-eg-opac
16:28:10 <dbwells> jeffdavis: I think testing credentials would be great.  I'm not sure how many of us have access otherwise to OverDrive.
16:28:33 * csharp might be able to get credentials, but not sure if he could share them :-/
16:28:44 <jeffdavis> I can commit to contacting Overdrive about that.
16:29:01 <jeff> My experience with getting API access from them (prod and/or testing) has been... yeah.
16:29:44 <dbwells> #info jeffdavis suggests that any potential testers file bugs at the link given above
16:30:12 <jeffdavis> They do have a testing environment which in theory shold not be tied to anyone's "real" OverDrive accounts, so it's at least a theoretical possibility, IIUC.
16:30:17 <kmlussier> Thanks all!
16:30:27 * kmlussier needs to disappear
16:30:38 <dbwells> #action jeffdavis will pursue contacting OverDrive to ask about test credentials / a test environment
16:30:41 * csharp too
16:31:01 <dbwells> Ok, wrapping things up unless someone speaks up...
16:31:22 <jeffdavis> jeff: we have two OverDrive accounts, each used by a different chunk of our libraries
16:31:35 <jeffdavis> I should add that we have this code in production for all our OD subscriber libraries
16:32:00 <jeffdavis> auth is based on patron barcode, some libraries require PIN to be checked and others don't
16:32:27 <jeffdavis> happy to go into more detail, but dunno if we want to do that as part of this meeting?
16:32:42 <jeff> just after is fine. let's let dbwells #endmeeting :-)
16:33:11 <dbwells> jeffdavis: I'm interested in at least seeing this in action at some point.
16:33:35 <dbwells> Ok, thanks all.
16:33:36 <dbwells> #endmeeting