14:09:04 <gmcharlt> #startmeeting Evergreen development meeting, 13 January 2014^W2015
14:09:04 <pinesol_green> Meeting started Tue Jan 13 14:09:04 2015 US/Eastern.  The chair is gmcharlt. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:09:04 <pinesol_green> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:09:04 <pinesol_green> The meeting name has been set to 'evergreen_development_meeting__13_january_2014_w2015'
14:09:11 <gmcharlt> #info Agenda is http://wiki.evergreen-ils.org/doku.php?id=dev:meetings:2015-01-13
14:09:22 <gmcharlt> #topic Introductions
14:09:30 <gmcharlt> #info gmcharlt = Galen Charlton, ESI
14:09:34 <bshum> #info bshum = Ben Shum, Bibliomation
14:09:44 <dbs> #info dbs = Dan Scott, Laurentian University
14:09:53 <dbwells> #info dbwells = Dan Wells, Hekman Library (Calvin College)
14:09:55 <berick> #info berick = Bill Erickson, KCLS
14:10:00 <RoganH> #info RoganH = Rogan Hamby, SCLENDS
14:10:09 <phasefx> #info phasefx = Jason Etheridge, ESI
14:10:14 <jeffdavis> #info jeffdavis = Jeff Davis, Sitka
14:10:21 <eeevil> #info eeevil = Mike Rylander, ESI
14:10:40 <kmlussier> #info kmlussier = Kathy Lussier, MassLNC
14:10:43 <remingtron> #info remingtron = Remington Steed, Hekman Library (Calvin College)
14:10:48 <jeff> #info jeff = Jeff Godin, Traverse Area District Library (TADL)
14:12:04 <gmcharlt> ok
14:12:11 <gmcharlt> #topic Updates - OpenSRF
14:12:18 <gmcharlt> #info OpenSRF 2.4.0 released
14:12:20 <gmcharlt> bshum++
14:12:59 <gmcharlt> #info current main target for OpenSRF 2.4.1 is adding a configuration option for using ports 80/443 for WS/WSS
14:13:27 <eeevil> gmcharlt: is there a timeline that you know of?
14:13:28 <gmcharlt> via a proxy put in front of the two Apache instances
14:13:47 <eeevil> for the release, I mean
14:13:51 <bshum> gmcharlt++
14:13:59 <gmcharlt> post-ALA and before 2.8 gets a beta
14:14:07 <eeevil> k, thanks
14:14:48 <gmcharlt> any other OpenSRF business?
14:15:19 <gmcharlt> ok
14:15:29 <gmcharlt> #topic Evergreen 2.8 updates
14:15:33 <gmcharlt> berick?
14:15:54 <berick> if you have any big features planned for 2.8, please get them into LP as soon as possible
14:16:24 <berick> tomorrow is the official deadline, but.. just get them in ;)
14:16:54 <berick> target 2.8-beta unless you are unsure it's actually going to happen
14:17:21 <berick> and remember the beta merge freeze is Feb 20th.
14:17:29 <berick> so we have just over a month for feature development
14:17:53 <berick> and that's about it unless anyone has questions
14:18:38 <gmcharlt> #info 14 January 2015 is the deadline for targeting new features slated for 2.8; use the 2.8-beta milestone
14:19:35 <gmcharlt> ok, hearing no questions, moving on
14:19:44 <gmcharlt> #topic New business - quality assurance
14:19:46 <gmcharlt> kmlussier?
14:20:17 <kmlussier> Sure. The folks at MassLNC were revisiting the QA report done a little over a year ago.
14:21:04 <kmlussier> Since the report was issued, the community has come together to agree to do PGTap tests. But there are other recommendations that haven't been implemented yet.
14:21:32 <kmlussier> So I thought it would be good to start a discussion among all of you to get a sense of what you think is needed to implement some of those other recommendations.
14:22:33 <jeff> especially relevant since we're looking at a soon-to-be era where xulrunner is no more for Evergreen: ``there may be areas where improvements will be limited until Evergreen moves away from XULRunner''
14:23:16 <kmlussier> jeff: Are you thinking testing will become easier when we are off XULRunner?
14:24:32 <dbs> Even on the PGTap side of things, we haven't really kept up with our commitment to add tests as we change the SQL
14:24:33 <jeff> I was just quoting the part of the report that asserted (now I'm paraphrasing) that a move away from xulrunner would open the door for more improvements to QA and testing.
14:25:50 <bshum> So, I admittedly haven't read the full report in awhile, but I'm not seeing any specific approaches being suggested.  So the question on the floor is whether we would like to plan on finding some specifics and applying them towards say, the web client (as it's being created)
14:25:57 <kmlussier> Is part of the issue the fact that we don't have people with the expertise and/or time to take charge of QA?
14:26:36 <eeevil> kmlussier: I think that's The(tm) perpetual challenge ;)
14:26:43 <gmcharlt> time in particular
14:26:56 <dbs> But we kind of don't have the time to not do QA either
14:27:25 <gmcharlt> also true
14:27:28 <kmlussier> I also think testing goes beyond the client. For example, there were recommendations for a test suite to test for performance, for example.
14:27:37 <dbs> Lacking at least one person with expertise + time, though, yeah, it's a problem.
14:28:30 <kmlussier> So, I know there are people in the community who would be willing to put resources into bringing on a person to manage that process if it were needed.
14:29:01 <kmlussier> First, I think it would be good to know if that is, indeed, what is needed.
14:29:43 <kmlussier> Also, I didn't know if it would be worthwhile to look at other projects to see how QA is done. And, then, maybe pull the best from those projects to see what would work best for Evergreen.
14:30:29 <jeffdavis> What would "bringing on a person" entail?
14:30:48 <berick> well, there are some things we already have a good handle on (e.g. pgtap tests, perl unit tests, perl live tests).  for those types of things, i think we just have to make ourselves do it.
14:31:22 <berick> there's a lot we could do we're just not doing.
14:31:30 <dbs> amen
14:31:32 <kmlussier> berick: Does everyone contributing code have a good handle on that?
14:31:50 <berick> having someone whose job it is to think about it for big picture stuff would be great, but we shouldn't let that slow us down
14:32:11 <jeff> berick: during sprint 1 of the web client, you had some unit tests in place (correct me if i'm wrong) -- could you hazard a guess as to what percentage of interfaces have unit tests?
14:32:12 <berick> kmlussier: well, no, because we don't do it regularly enough for everyone of have templates to work from
14:32:34 <gmcharlt> a somewhat stricter attitude about requiring pgTap tests and Perl unit tests to accompany patches would be a step forward for the 2.8 cycle
14:32:49 <berick> jeff: those unit tests were almost entirely focused on the services (i.e. the stuff under the interfaces)
14:33:30 <berick> jeff: so, very little UI coverage
14:33:40 <berick> gmcharlt: agreed
14:34:58 <jeff> berick: got it. thanks.
14:35:01 <phasefx> jfyi, one notion I encountered was to not focus on testing "services" through the UI, but the test the UI itself (widgets, etc.) if testing the UI, and test the services more closely to where they live if testing the services
14:35:19 <kmlussier> I think my group would be in favor of stricter requirements for tests and whatever else you can do now.
14:35:44 <gmcharlt> as far as I'm concerned personally, providing pgTap + perl tests for the stuff I'm slated to do for 2.8 is easy enough
14:36:25 <kmlussier> But if the developers, as a group, told me, "we really need somebody to manage this process," I would do what I could to make that happen.
14:37:37 <dbs> I imagine the developers are trying to imagine how such a person dropped into our midst could actually manage the process.
14:37:38 <kmlussier> I'm mostly concerned that there is still more testing beyond pgTap and perl tests that we need to be doing.
14:37:42 <dbs> Buy-in would be tough.
14:38:20 <jeff> I consider myself a novice with regard to Perl tests, and moreso with regard to pgTap tests. I'd be willing to extract knowledge and experience from others and formulate something of a reference / set of guidelines for contributors in the hope that it would help myself and others include appropriate tests in contributions.
14:38:34 <gmcharlt> on the other hand -- somebody who had an explicit committment to review patches (and who could come up the speed) might be an easier dose of medicine, as it were
14:38:39 <kmlussier> Yes, well, that's why I'm raising the questions here.
14:39:30 * dbs would like to automatically test the TPAC for basic accessibility compliance, ensuring RDFa comes out right, ensuring data is displayed as expected (which would be hella useful if we move misc_util.tt2 into Perl module land)
14:39:44 <jeff> dbs++ good job putting words to what I was thinking ("dropped into our midst" comment above)
14:40:22 <kmlussier> Well, any new developer is essentially "dropped into our midst," right?
14:40:37 <berick> jeff: i'd be happy to help review/edit any such guidlines
14:40:40 <dbs> Unfortunately most of those tests would require python for RDFLib and I'm not keen on introducing more dependencies
14:40:43 <gmcharlt> dbs: does that translate to "you are willing to help set up such testing"?  I'd be happy to collaborate with you on that
14:41:18 <jeff> berick++ sounds good.
14:41:36 <dbs> kmlussier: yes, but the mindset is often such that a new developer == "yay they're helping build this thing" vs "this person is getting in the way"
14:41:54 <gmcharlt> vs "this stranger is TELLING US WHAT TO DO. OH NOES!"
14:42:11 <dbs> / "where do they get off..."
14:42:19 <kmlussier> Yes, I understand.
14:42:33 <kmlussier> At the same time, I haven't seen any current developers say they want to take charge of QA, and I think it's more from lack of time than lack of desire.
14:42:36 <dbs> gmcharlt: yeah, I guess basically it's a glorified curl / string processing thing, so yeah
14:42:44 <kmlussier> Overall, I think that's what's needed. Somebody who is willing to take charge.
14:43:05 <berick> i would welcome someone whose job it was to research and present ideas, proofs-of-concept, etc. on QA stuff.
14:43:18 <berick> "manage" and "take charge" may not be the right words
14:43:22 <berick> "drive" maybe
14:43:39 <jeff> berick: as 2.8 RM how do you feel about gmcharlt's proposal of "a somewhat stricter attitude about requiring" tests?
14:43:42 <dbs> "Hey, look at what you can do with a few lines of additional code"
14:43:58 <kmlussier> Yes, "drive" is a good word. :) As gmcharlt said, somebody with an explicit commitment.
14:44:21 <gmcharlt> berick: and "review patches"... I really think it does need to be grounded
14:44:24 <berick> jeff: +1 from me for bumping to strictness level 2
14:44:34 <berick> gmcharlt: ah, yes, that would ideal
14:45:47 <jeff> gmcharlt: am i correct in thinking that koha has an explicit "QA" signoff? Is that a mostly automatic (tests passed!) signoff, or is that a human signing off with a specific eye toward QA?
14:46:02 <jeff> (deja vu -- i may have asked this question before)
14:46:13 <gmcharlt> jeff: the Koha process seeks two signoffs
14:46:29 <gmcharlt> 1st signoff is from essentially anybody who can install the patch and run it through its paces
14:47:06 <dbs> #link One accessibility checking API: http://wave.webaim.org/api/ (costs $$$ but it's an option)
14:47:12 <gmcharlt> the 2nd, QA signoff is based on an inspection by a human member of the QA team + the patches passing a set of extra, mostly static source-code level tests
14:47:32 <berick> as far as 2.8 goes, we'll need some guidelines for building tests, what the minimal requirements are.  I can build/collaborate on that.  i'll obviously need input, though.
14:47:55 <berick> and since it's late in the game, we'll have to be pretty forgiving
14:48:46 <jeff> sure. nobody's proposing FESTIVITY^WSTRICTNESS LEVEL 4.
14:49:13 <gmcharlt> so we have, to sum up, the following concrete suggestions at th emoment
14:49:18 <gmcharlt> 1. incrementing the strictness level
14:49:32 <gmcharlt> 2. berick et al writing up some guidelines and templates for pgTAP and perl unit tests
14:49:51 <gmcharlt> 3. dbs and galen putting together some automatic testing of TPAC and RDFa output
14:50:13 <gmcharlt> and less concretely, some fuzzy input on desiderata for a "QA person"
14:50:20 <dbs> #link another accessibility checking API: https://github.com/inclusive-design/AChecker (GPL v2)
14:50:43 * gmcharlt has used AChecker in the past, FWIW
14:51:11 <kmlussier> gmcharlt: Would it be helpful if someone (I can volunteer) do an environmental scan of other projects and who they handle these issues?
14:51:56 <gmcharlt> kmlussier: yes - in particular, if such a scan also looks for people with track records in doing this sort of work
14:52:08 <gmcharlt> not just the QA, but the introducdtion of process improvement
14:52:34 <kmlussier> OK, I can do that, but I welcome any help if anyone wants to work with me on it. :)
14:52:46 <jeff> kmlussier: to clarify-- did you mean "how they handle these issues", or were you focused on a "who"?
14:52:58 <gmcharlt> kmlussier: I haz thoughts on the matter and would be interested in working with you on it
14:53:47 <kmlussier> jeff: The who is part of it, but the overall process too.
14:53:52 <kmlussier> gmcharlt: Thanks!
14:55:12 <gmcharlt> so, just to double-check -- are folks (particularly committers) OK with stricter enforcement of providing pgTAP & perl unit tests for the 2.8 cycle?
14:55:24 <eeevil> may I as that followups happen on the -dev list? (rather than -general, not to exclude folks, but to avoid pulling in -dev help)
14:55:57 <eeevil> the kmlussier + gmcharlt + dbs + berick + others followups, I mean
14:56:17 <kmlussier> eeevil: That's fine with me
14:56:54 <gmcharlt> agreed
14:56:58 <jeff> It will make some things harder, but those things may well be the things that would most benefit from unit tests.
14:57:11 <jeff> (or pgTAP tests)
14:57:12 <eeevil> gmcharlt: for my part (re agreement), yes, where applicable and reasonable (that is, not useless for lack of context), stricter enforcement of tests
14:57:50 * eeevil does not plan to write tests that require a mock env that emulates all of Evergreen ... fwiw ;)
14:57:59 <gmcharlt> eeevil: indeed - I can point to some examples in recent memory of cases where some testing-for-the-sake-of-following-the-rules was in play
14:58:10 <jeff> eeevil: I don't think that any of our employers have enough time that tests for the sole sake of tests will be a common thing. :-)
14:58:11 <phasefx> are we excluding or including integration tests here against live test systems?
14:58:14 <gmcharlt> but I will emphasize that at the moment, Evergreen is in no danger of that!
14:58:29 <eeevil> gmcharlt: fair ;)
14:58:55 <berick> phasefx:  I was hoping to encourage the use of live tests for changes that can't be tested in a vacuum, if that's what you're asking
14:58:59 <gmcharlt> OK, I'm going to summarize, then move on to the next agenda item
14:59:24 <phasefx> berick: sounds good to me, and I just saw eeevil's desire not to build  huge mock environments :)
14:59:27 <gmcharlt> #item There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests
14:59:43 <gmcharlt> #info There is general agreement that for the 2.8 cycle, we'll be stricter about requiring relevant pgTAP & perl unit tests
14:59:55 <gmcharlt> #info berick will write some guidelines on writing Perl and pgTAP tests
15:00:13 <gmcharlt> #info dbs and gmcharlt will work on automating accessibility and RDFa tests of TPAC
15:00:39 <jeff> berick: see what i did there, how that turned from you reviewing/editing to writing those from scratch? ;-)
15:00:43 <gmcharlt> #info kmlussier will do an environement scan of QA practices and experts in other project, with help from gmcharlt and others
15:00:48 * jeff ducks
15:01:11 * gmcharlt creates a LP project for filing bug reports against the meeting minutes ;)
15:01:26 <gmcharlt> #topic Overdrive circulation API code
15:01:34 <gmcharlt> #link http://markmail.org/message/cgcrmqdz4nrm5erv
15:01:36 <berick> jeff: you must teach me this power
15:02:25 <jeff> sitka++
15:02:49 <jeffdavis> As that linked email says, we have working code to make use of Overdrive's API in the Evergreen OPAC.
15:03:59 <jeffdavis> We'd like this to be adopted by the EG community, so I'm interested in how to help make that happen.
15:04:27 <gmcharlt> well, there are various levels
15:04:55 <gmcharlt> one approach that woudl require very little work on your part is to set it up as a contrib whose home repository lives on git.evergreen-ils.org
15:05:01 <gmcharlt> and supply some documentation
15:05:22 <gmcharlt> folding it into Evergreen core would, at minimum, require more work
15:05:45 <jeff> I can see this starting as a contrib and potentially becoming core or inspiring core.
15:06:15 <kmlussier> Would it only be acceptable if there were no new dependencies required?
15:06:27 <dbs> Adding CoffeeScript + Node + jQuery knowledge requirements (for bug-fixing/enhancements) & install/config/maintenance (for just using) is certainly not enticing
15:06:33 <jeff> I don't think we have a strong rule about "no new dependencies".
15:06:36 <dbs> (not to em, anyway)
15:06:44 <jeffdavis> (not to me either, fwiw)
15:06:45 <dbs> s/em/me/
15:07:01 <dbs> The last new dependency was Ruby for EDI, no?
15:07:05 <jeff> But there are approaches that can be taken to services like OverDrive and OneClickdigital that don't involve as many additional dependencies.
15:08:01 <jeff> jeffdavis: do you know if the code as it exists supports libraries with different "OverDrive Advantage" subscriptions within an (OverDrive) consortium, or supports more than one specific method of patron authentication?
15:08:14 <berick> dbs: yeah, but i'm actively fighting to kill the ruby stuff.
15:08:22 <dbs> berick: that's what I mean :)
15:08:35 <jeff> Those would be the first things that came to mind when looking over the code in terms of "would be nice to have before consideration of incorportating it into Evergreen"
15:08:47 <dbs> And trading XUL for AngularJS
15:09:03 <jeff> (please don't take either of those as criticism, by the way)
15:09:19 <gmcharlt> berick++ # although to be clear to any Rubyists watching, Ruby per se isn't necessarily a problem; the problem is more "a tiny bit of one language does not mix well in a code base that is predominantly written in another"
15:09:35 <jeffdavis> jeff: It can be made to support multiple OD accounts - that is actually my next task vis-a-vis the project. I think making it support multiple methods of patron auth would take more work.
15:09:38 <dbs> Is the Overgreen code (I love that neologism) GPL v2 compliant, too?
15:09:46 <csharp> overgreen++
15:09:57 <jeffdavis> I've been calling it OD API, but Overgreen works :)
15:09:58 <eeevil> jeffdavis: 2 questions (since I haven't looked at the code yet) 1) is the coffeescript yours or overdrive's? and if the latter, could the coffeescript be compiled down to a blob we could include in the release, instead of requiring new deps?
15:10:08 <jeff> dbs: the repo claims MIT license, and there is no OverDrive code to license, just an API.
15:10:35 <berick> gmcharlt: yes, of course.  i'm fighting the added dependency, not the language.
15:10:35 <jeff> s/repo/sitka repo/
15:10:37 <eeevil> (a la dojo)
15:11:00 <jeff> eeevil: the coffeescript is sitka's, and requires nodejs at build time.
15:11:35 <dbs> jeff: yeah, I saw the MIT license, but also saw it came after the bulk of the work was done; wanted to ensure it was applied cleanly
15:11:52 <jeff> eeevil: so no, it couldn't be reduced to a blob in the repo, but it could live externally as contrib and evergreen could contain hooks that would tie into the blob built from contrib if present.
15:11:56 <eeevil> jeffdavis: could post-build code be pulled in to get something in for 2.8?
15:11:59 <eeevil> oh, ok
15:12:21 <jeffdavis> Either of those approaches could work really.
15:12:39 <jeffdavis> I think jeff's suggestion is probably a bit better for now, though.
15:13:35 <gmcharlt> one thing that does bother me about the implementation is that it seems a bit delicate with respect to changes to the TPAC templates
15:13:38 <jeffdavis> dbs: The MIT license was added to the source relatively late, but it was originally marked as MIT-licensed when our developer published it on Google Code.
15:13:51 <jeff> jeffdavis: with regard to "Steven Chan making 32 commits and then Jeff Davis adding a LICENSE.txt and Copyright statement"... can you clarify for purposes of copyright/license what the  status of the code is? I don't even know enough about Canadian copyright law to ask the right question there.
15:14:19 <gmcharlt> e.g., bits like this: http://paste.lisp.org/display/145214
15:14:36 <jeffdavis> Steven Chan wrote almost all of the code on contract for Sitka. As mentioned, he had licensed it under MIT but the license wasn't included in his source. I added it once I inherited ownership of the project a few months ago.
15:14:54 <jeffdavis> s/added it/added an explicit MIT license in the source/
15:15:01 <gmcharlt> jeffdavis: do you know if it was a work-for-hire for Sitka?
15:15:25 <RoganH> jeffdavis: was it licensed as MIT as per contract with SITKA?
15:15:37 <jeffdavis> gmcharlt: yes, my understanding is that it was work-for-hire for Sitka.
15:15:51 <dbs> In Canada, work for hire doesn't apply, IIRC
15:16:16 <jeffdavis> dbs: Steven's contract would have assigned copyright in his work for Sitka to Sitka, though.
15:16:23 <RoganH> dbs: you are correct
15:16:39 <jeffdavis> At least, that was my understanding when I asked about it before adding the license.
15:17:04 <jeffdavis> I'm happy to seek any required clarification.
15:17:16 <jeff> would having Steven Chan post confirmation of that to open-ils-dev be sufficient to clear things up for everyone?
15:17:49 <gmcharlt> let's draw the licensing discusison to a close -- I thnk Sitka should clarify the copyright and license status, but it is reasonable to assume that any loose ends can be tied up
15:18:12 * dbs agrees with gmcharlt
15:19:02 <jeff> Include in 2.8 with some light work, and known missing aspects, or Not included in 2.8, but an exciting/promising optional contrib/add-on for those interested?
15:19:17 <jeff> or are we not looking for a decision on that at this point, and just taking a moment to discuss without action?
15:19:56 <gmcharlt> I don't think we need to finalize a decision now -- I think it would suffice for jeffdavis to file a 2.8-beta LP for now
15:20:08 <jeff> (and knowing that features don't go in/out based on developer meeting discussion alone)
15:20:11 <jeffdavis> I'll do that, and set up this project as a contrib on git.evergreen-ils.org as well.
15:20:22 <dbs> jeffdavis++
15:20:26 <dbs> sitka++
15:20:31 <bshum> jeffdavis++ sitka++
15:20:47 <kmlussier> jeffdavis++ sitka++
15:20:49 <gmcharlt> and finally
15:20:56 <jeffdavis> I should explicitly say that Sitka would prefer not to own this project long-term, so hopefully either the community can take it on or make use of it to develop API integration that works better.
15:21:06 <gmcharlt> #topic Negative blances / billing improvements
15:21:17 <gmcharlt> #link https://bugs.launchpad.net/evergreen/+bug/1198465
15:21:17 <pinesol_green> Launchpad bug 1198465 in Evergreen "Support for Conditional Negative Balances" (affected: 14, heat: 66) [Wishlist,Confirmed]
15:21:24 <dbwells> I'm already late for another meeting, so I'll make this quick.
15:21:41 <dbwells> Basically, I'm just fishing for help in testing some or all of the billing changes which have grown on that bug.
15:22:07 <dbwells> As I stated in the agenda, I think separating out the root-level stuff and getting that tested/committed first would be a good strategy.  Any takers for testing?
15:22:13 <berick> dbwells: +1 to the idea of breaking out cstore billing to its own LP.  I would help poke at that.
15:22:18 <jeff> I'm interested in testing.
15:22:23 <berick> it's much more digestable...
15:22:30 <kmlussier> I'm interested in testing too.
15:22:45 <dbwells> sweet, thanks all
15:22:53 <jeff> I hate to ask, but... are there tests in the root-level stuff at this point in time?
15:23:15 <dbwells> I've been working this morning on getting the cstore stuff separated, it wasn't too bad.
15:23:52 <dbwells> jeff: Only in that it doesn't (or mightn't) break the existing billing tests.
15:24:28 <dbwells> At least that portion isn't meant to do anything new.  Not that we couldn't always use more tests, of course.
15:24:32 <jeff> In some ways, that's enough! Always nice when there are existing relevant tests. :-)
15:24:58 <gmcharlt> #action dbwells will separate the cstore billing code into a separate bug; jeff and berick will help with testing
15:25:16 <gmcharlt> and I suggest follow-up to open-ils-dev
15:25:39 <dbwells> I am out for now.  Thanks again to those who volunteered; expect to be bugged by me soon.
15:25:44 <jeff> dbwells++
15:26:05 <kmlussier> dbwells++
15:26:05 <gmcharlt> so, since we're at nearly 1:20 - I will give folks 2.5 seconds to suggest last-minute topics
15:26:19 * gmcharlt drops the portcullis
15:26:19 <bshum> dbwells++
15:26:25 <gmcharlt> #endmeeting