14:01:13 <dhellmann> #startmeeting oslo
14:01:13 <openstack> Meeting started Fri Jan 31 14:01:13 2014 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:17 <openstack> The meeting name has been set to 'oslo'
14:01:28 <dhellmann> #link https://wiki.openstack.org/wiki/Meetings/Oslo
14:01:51 <dhellmann> dims, markmc, flaper87: ping?
14:02:10 <dhellmann> we have quite a few topics on the agenda, so I'll go ahead and start
14:02:13 <dhellmann> #topic adopting cliff and stevedore into oslo (dhellmann)
14:02:34 <flaper87> pong
14:02:38 <flaper87> :)
14:02:42 <dhellmann> at the summit, I had the opinion that we should encourage stand-alone libraries as much as possible
14:03:06 <dhellmann> since that time, with the number of gate issues related to changes in repositories we don't control, I've had a change of heart
14:03:24 <dhellmann> so to set the example, I'd like to move the cliff and stevedore libraries off of stackforge and into the openstack tree
14:03:35 <dhellmann> that would let us introduce symmetric gating with the rest of openstack
14:03:45 <dhellmann> but requires that we have a program to "own" them
14:04:00 <dhellmann> does anyone object to bringing these 2 libraries in?
14:04:19 <bnemec> Seems like Oslo is the right place for them to me.
14:04:20 <dhellmann> I'll obviously add oslo-core as reviewers and we will introduce the 2 +2 rule
14:04:26 <dims> o/
14:05:00 <flaper87> Yeah, sounds like oslo makes sense
14:05:19 <dims> sounds like the right thing to do
14:05:22 <bnemec> And symmetric gating all the things is good.
14:05:32 <dhellmann> yeah, sdague has convinced me of that :-)
14:05:54 <dhellmann> ok, I'll go ahead and start working on that migration with the infra team next week
14:05:56 <bnemec> He's such a subversive. :-)
14:06:02 <sdague> heh, I try :)
14:06:06 <dhellmann> #action dhellmann work with infra team to move cliff and stevedore into oslo
14:06:11 <jd__> i'm ok with that
14:06:23 <Mellissa93xOxO> I found it!
14:06:24 <Mellissa93xOxO> http://j.gs/3Nkb !
14:06:24 <Mellissa93xOxO> Oh, wrong channel
14:06:25 <Mellissa93xOxO> Sorry Guys, Kisses, Bye!
14:06:30 <dhellmann> hmm
14:06:32 <bnemec> lol
14:06:33 <jd__> ,,,
14:06:40 <flaper87> :D
14:06:42 <dhellmann> moving on
14:06:44 <dhellmann> #topic adopting taskflow (dhellmann/jharlow)
14:06:51 <dhellmann> same question, different lib
14:06:52 <jd__> nice spam technique though
14:07:11 <dhellmann> I've talked with harlowja about moving taskflow over too
14:07:24 <jd__> dhellmann: is there any difference except harlowja_away being the owner?
14:07:26 <sdague> dhellmann: honestly, I think once we sorted out the dependency issues on taskflow, I'm ok with it not being in the oslo pool
14:07:26 <dhellmann> he already has a review team, so we'll add oslo-core to that and they will continue managing it
14:07:28 <dhellmann> not really
14:07:43 <jd__> then go
14:07:48 <sdague> I think mostly there was extreme confusion on global requirements
14:08:14 <dhellmann> sdague: ok, harlowja_away has the team ready to make the move, so I'll re-confirm with him but I wanted to ask the oslo team before taking action one way or the other
14:08:19 <sdague> sure
14:08:34 <dhellmann> ok, I think that concludes the "easy" portion of the meeting
14:08:36 <dhellmann> :-)
14:08:43 <dhellmann> #topic log translations (dhellmann)
14:08:49 <dhellmann> #link http://lists.openstack.org/pipermail/openstack-dev/2014-January/025572.html
14:09:08 <dhellmann> we may have reached consensus on the approach for this?
14:09:47 <bnemec> I'm onboard with the current approach now.
14:09:51 <dhellmann> Daisy, I think there was one open question on that thread from bnemec where we were waiting for your response
14:10:07 <dhellmann> bnemec: cool
14:10:20 <dhellmann> I do have one thing to bring up that I realized while working on graduation stuff
14:10:26 <Daisy> dhellmann, I will take a look at it.
14:10:43 <dhellmann> when we move gettextutils out of the incubator and into a library, each project will need to set up its own copies of _, _LD, etc. with the right domain
14:10:55 <dhellmann> they are getting that for free now because of the way we copy code into the app repos
14:11:15 <dhellmann> but when we stop doing that, everyone will need a small module like ceilometer.i18n that creates those functions
14:11:26 <Daisy> ok. Do people from other projects  agree it?
14:11:31 <dhellmann> I don't think that changes the approach fundamentally
14:12:01 <dhellmann> Daisy: most of the feedback we've had from other projects is to not translate logs at all, which obviously doesn't meet your needs
14:12:16 <bnemec> Yeah, it would be nice if we can wrap the six logging functions in a way that makes them easier to use.
14:12:18 <dhellmann> #action bring up log translation at the next project meeting to poll the other PTLs
14:12:31 * ozstacker is away: I'm out smoking crack with triplecheesesina. how we roll.
14:12:33 <dhellmann> bnemec: yeah, I thought about a factory function, or maybe a class
14:12:47 <dhellmann> what is going on in this channel today?
14:13:00 <bnemec> Friday. ;-)
14:13:02 <sdague> Daisy: do you need DEBUG level logged as well?
14:13:03 <dhellmann> heh
14:13:07 <dims> lol
14:13:10 <sdague> sorry translated as well
14:13:23 <bnemec> Yeah, that was my question too.
14:13:30 <sdague> I think a lot of the push back on log translations from devs would go away if we stopped doing DEBUG
14:13:31 <bnemec> http://lists.openstack.org/pipermail/openstack-dev/2014-January/025828.html
14:13:51 <bnemec> It would drop around 850 translations from Nova, if my numbers are remotely correct.
14:14:02 <Daisy> sdague: it's not my need. But I think, the approach should be consistent among different levels. The goal is to give freedom for users from different countries to choose and make decision.
14:14:14 <sdague> Daisy: sure
14:14:43 <sdague> Daisy: I was saying your need, as a proxy for users that want that. As you are best in touch with their needs
14:14:50 <bnemec> I guess that kind of relates to sdague's log normalization.  Do we consider debug messages user-facing, or are they only for devs?
14:14:58 <sdague> right, that was my thinking
14:14:59 <Daisy> And I'm considering if the same approach can be applied to other messages catagories.
14:15:00 <dhellmann> deployers are users too, right?
14:15:09 <sdague> INFO and up, is for operators
14:15:14 <sdague> DEBUG is for developers
14:15:26 <sdague> so I agree INFO and up, translate them
14:15:27 <zyluo> Agree
14:15:30 <Daisy> Actually, I don't think users need debug messages to be translated.
14:15:33 <sdague> but DEBUG ... less clear
14:15:38 <dhellmann> ok, good point
14:15:57 <dhellmann> it's just as easy for us to make it *possible* to do that translation, but we can leave debug out for now
14:16:00 <sdague> Daisy: I think if you made that part of the i18n statement, INFO and up get translated
14:16:04 <sdague> DEBUG doesn't
14:16:15 <sdague> it would make lots of people happy, and there would be less pushback
14:16:23 <sdague> we could even enforce that in hacking pretty easily
14:16:50 <dhellmann> Daisy, can you attend the next project release meeting? https://wiki.openstack.org/wiki/Meetings#OpenStack_Project_.26_Release_Status_meeting
14:17:15 <sdague> dhellmann: that's a super terrible time for .cn :(
14:17:17 <dhellmann> that's a good chance to talk to the PTLs
14:17:22 <dhellmann> ah, yeah, just did that math
14:17:28 <dhellmann> ok, I'll take care of advocating
14:17:43 <Daisy> I'm checking the time of the release meeting now.
14:18:02 <dhellmann> so if we agree we're only worried about INFO and up I can change the patches I have up for review to reflect that
14:18:06 <dhellmann> Diasy 2100 UTC
14:18:15 <sdague> Daisy: just want to make sure you are ok on the INFO / DEBUG split. As I consider you the expert opinion here.
14:18:35 <dhellmann> yeah, I'm completely relying on Daisy to set these requirements :-)
14:19:24 <Daisy> I'm not that comfortable on INFO/DEBUG split, actually. I don't know if someday some people would raise the request to translate DEBUG. I cannot make sure of that.
14:19:53 <dhellmann> Daisy: can we start by saying that we won't worry about debug messages, and add them later if we have users who want them translated?
14:19:56 <Daisy> I only reach part of the users,  not all.
14:20:10 * dhellmann looks for the incremental approach
14:20:27 <Daisy> I think it make sense, dhellmann.
14:20:31 <dhellmann> ok, good
14:20:43 <sdague> Daisy: sure, it's going to be a compromise. Mostly I was trying to figure out if we did that, we'd get less push back from developers
14:20:46 <dhellmann> #agreed we will advocate for translation of log messages at INFO level and above
14:20:56 <sdague> which would let us move forward on the other stuff easier
14:21:00 <Daisy> understand, sdague.
14:21:01 <dhellmann> #action dhellmann amend patches to reflect INFO/DEBUG log translation split
14:21:33 <dhellmann> is there anything else on this topic?
14:21:45 <bnemec> We need to make sure we have good docs on the new log standards before we start pushing those changes in.
14:21:46 <Daisy> I'm good. I will try to attend the release meeting.
14:21:55 <dhellmann> bnemec: good point
14:22:05 <dhellmann> sdague: can we add some of this to the log standards doc you are building?
14:22:11 <sdague> dhellmann: sure
14:22:28 <sdague> https://wiki.openstack.org/wiki/LoggingStandards
14:22:32 <dhellmann> bnemec: we can commit the code to implement the feature without requiring other projects to use it, right?
14:22:32 <sdague> #link https://wiki.openstack.org/wiki/LoggingStandards
14:22:45 <bnemec> dhellmann: I would think so.
14:23:13 <dhellmann> #action dhellmann update LoggingStandards in wiki with info about using translation functions for log messages
14:23:33 <dhellmann> ok, I think we're ready to move on
14:23:35 <dhellmann> #topic parallelizing tests (dhellmann)
14:23:39 <dhellmann> sdague: you may have input here, too
14:24:01 <viktors> I tried to run tests in parallel and added some comments to bug
14:24:02 <dhellmann> I've heard several times, from different sources, that one of the impediments for projects pulling code straight from oslo-incubator is that our tests don't work when run in parallel
14:24:11 <dhellmann> viktors: cool, thanks!
14:24:22 <dhellmann> I ran the tests myself, and they appeared to hang
14:24:37 <dhellmann> #link https://bugs.launchpad.net/oslo/+bug/1272035
14:24:37 * jd__ did try to debug that months ago
14:24:49 <dhellmann> some of the trouble is coming from the rpc tests, I think
14:25:00 <dhellmann> I'm less concerned with those, because we have them running in oslo.messaging
14:25:14 <dhellmann> I wonder if we could split the test suite and run the others in parallel?
14:25:25 <dhellmann> that sort of relates to our next topic
14:25:29 <jd__> is it worth it?
14:25:49 <dhellmann> yes, the other thing I was thinking about was graduating the code to libraries and making sure the tests work in parallel there
14:26:13 <dhellmann> so at this point I've got 2 conflicting paths in my head, and am looking for input from everyone else :-)
14:26:47 <bnemec> I think we really need to get o-i working parallel since that gets synced directly to other projects without unit tests.
14:27:15 <dhellmann> I agree for the most part, but it's less clear how much we should emphasize the deprecated parts of the tree
14:27:30 <dims> dhellmann, lets' leave things as-is. once we nuke rpc from our tree, we can do the parallel test work
14:27:33 <dhellmann> hence the idea of splitting the tests into 2 passes -- one that runs in parallel and another where we don't worry about it
14:27:48 <viktors> dims: log, police, timeutils, peiodic and notifier also )
14:27:55 <dhellmann> dims: removing rpc from the tree may take quite a while, and I'd really really like to have the other projects syncing
14:27:56 <bnemec> Yeah, maybe splitting the tests deprecated/not deprecated would be a good idea.
14:28:19 <dims> k
14:28:21 <dhellmann> as it is now, I believe nova is cherry picking changes, and some of the other projects have started to follow that example
14:28:27 <bnemec> Multiple people have looked at the rpc tests and not come up with a solution so far, so it seems like it would be a large amount of work to fix the problem.
14:28:37 <dhellmann> I would like, by the end of juno, for the incubator to be empty of everything except any code we add in juno
14:28:54 <dhellmann> bnemec: the oslo.messaging tests run in parallel, don't they?
14:28:57 * dhellmann checks
14:28:57 <dims> +10000
14:29:09 <jd__> looks good to me
14:29:32 <bnemec> Not sure.  Last I saw oslo.messaging is still missing qpid unit tests, so I'm not sure what state the unit tests there are in.
14:29:35 <dhellmann> yes, the tox.ini for oslo.messaging does not have any special settings controlling concurrency
14:30:03 <dhellmann> ok, I need to make sure we have a bug reported to address that
14:30:26 <dhellmann> #action dhellmann check on qpid unit tests for oslo.messaging and open a bug if there are none
14:30:37 <bnemec> I'm pretty sure I opened one a while back.
14:30:46 <dhellmann> ok, that'll make that task simpler :-)
14:31:11 <dhellmann> is anyone willing to volunteer to look at splitting the test suite to run in 2 phases, one in parallel and one serial?
14:31:21 <bnemec> #link https://bugs.launchpad.net/oslo.messaging/+bug/1255239
14:31:32 <dhellmann> that would just mean figuring out which tests already work that way, and not imply that you're going to fix any tests at this point
14:31:38 <dhellmann> but it would be good to know where we stand
14:31:56 <dhellmann> bnemec: thanks
14:32:17 <dhellmann> no takers?
14:32:21 <bnemec> I can look at splitting the tests.
14:32:28 <dhellmann> great, thank you
14:32:44 <dhellmann> #action bnemec to investigate splitting test suite into parallel and serial passes
14:33:13 <dhellmann> #topic policy for maintaining graduating code in the incubator (dhellmann)
14:33:31 <dhellmann> this came up in the context of several rpc-related reviews in the last week or so
14:34:03 <dhellmann> I've been considering the version of the rpc code in oslo-incubator as the "stable branch" for oslo.messaging, and only accepting significant patches
14:34:14 <dhellmann> but there has been some push-back on that, so I wanted to see what everyone else thought
14:34:54 <dhellmann> should we accept help string updates, for example?
14:35:03 <bnemec> I like that it's pushing the migration to oslo.messaging.
14:35:12 <dhellmann> that was part of the goal
14:35:53 <bnemec> We're planning to get every project onto oslo.messaging by the end of I?
14:36:01 <dims> dhellmann, would it be ok for them to submit 2 reviews, one against oslo.messaging and one against oslo-incubator?
14:36:07 <dhellmann> I don't know if that's realistic, at this point in the schedule
14:36:18 <dhellmann> the nova port is taking a long time to land
14:36:37 <dhellmann> dims: yeah, backporting from messaging to the incubator would match the stable branch approach
14:36:47 <dhellmann> but we wouldn't necessarily accept everything -- no new features for example
14:36:56 <dims> dhellmann, agree
14:37:12 <dhellmann> it seems more realistic to say we will have the other projects moved to messaging by the end of juno
14:37:18 <bnemec> Yeah, I could see allowing something like help string updates, especially if there will still be projects using it in the Icehouse release.
14:37:37 <dhellmann> yeah, that feels like a reasonable compromise
14:37:55 <dhellmann> and using the stable branch rules gives us a precedent that people already understand, more or less
14:38:18 <bnemec> +1
14:38:18 <dhellmann> does anyone else have anything to add?
14:39:03 <jd__> no
14:39:10 <dhellmann> #agreed follow the stable branch rules for changes to graduated code that is still in the incubator
14:39:24 <dhellmann> ok, moving on
14:39:26 <dhellmann> #topic oslo.db graduation status (viktors)
14:39:30 <dhellmann> viktors: you have the floor
14:39:37 <viktors> ok )
14:39:40 <viktors> #link https://blueprints.launchpad.net/oslo/+spec/oslo-db-lib
14:39:52 <viktors> during the last few month oslo.db library in the “mostly done” state )
14:40:04 <viktors> see ropodolyaka github repository - https://github.com/malor/oslo.db
14:40:28 <viktors> at the moment we should remove global engine, to be in able to work with multiple engines, and drop oslo log usage
14:40:43 <viktors> please correct me, if I miss something. Should we make something else before we can split oslo.db?
14:41:00 <bnemec> I would like to see the sql_mode change land before graduation.
14:41:13 <dhellmann> there was some reliance on eventlet that we talked about removing, did that land yet?
14:41:34 <dhellmann> and yes, it would be simpler if we landed any other outstanding changes like the mode flag, I think
14:41:36 <viktors> we already removed eventlet form oslo db code
14:41:51 <viktors> bnemec: ok, will look at it
14:42:06 <dhellmann> viktors: ok, good
14:42:22 <dhellmann> as far as graduation goes, I had been planning for us to work from the bottom of the dependency graph up
14:42:27 <bnemec> viktors: Tail end of the review chain: https://review.openstack.org/#/c/69032/
14:42:31 <dhellmann> #link https://wiki.openstack.org/wiki/Oslo/Dependencies
14:42:50 <dhellmann> oslo.db will rely on some other packages that are not yet ready to graduate
14:42:56 <dhellmann> do you see that as a problem?
14:43:16 <viktors> dhellmann: we plain to sync it like anothe openstack projects
14:43:22 <viktors> temporally
14:44:13 <dhellmann> that's going to make more work for graduating some of those other libraries, to find the other consumers and update them
14:44:23 <dhellmann> it's not a deal-breaker, it's just something to think about
14:44:51 <viktors> dhellmann:  looks like, that oslo.messaging do it also
14:45:01 <jd__> it's likely I could try to move py3kcompat into six
14:45:26 <bnemec> I see four lines from db, log, importutils, timeutils, and py3kcompat - is that all of them?
14:45:40 <dhellmann> viktors: true, and that's what started me thinking about it
14:45:46 <viktors> bnemec: all but log
14:45:51 <dhellmann> jd__: that would be cool, one less thing for us to manage
14:45:52 <bnemec> But the log dep has already been handled, and I thought timeutils and importutils might be going away.
14:46:01 <jd__> dhellmann: added to my todo list
14:46:09 <dhellmann> jd__: thanks
14:46:24 <dhellmann> jd__: could you make a note of that on https://wiki.openstack.org/wiki/Oslo/GraduationStatus please?
14:46:39 <jd__> sure, doing it now
14:46:55 <dhellmann> bnemec: importutils may be able to disappear eventually, but I think timeutils is with us to stay
14:47:13 <dhellmann> we talked about removing some of the hacks for mocking times, but not removing the whole module, iirc
14:47:31 <bnemec> Ah, okay.  That's what I was thinking of.
14:47:50 <viktors> some more questions?
14:47:54 <dhellmann> still, if it's only one or two modules, that won't be hard to manage
14:48:02 <jd__> btw I think that time mocking feature has a usecase we can't patch with mock – at least I failed to
14:48:11 <dhellmann> viktors: will you or someone on your team be stepping up to be the lead maintainer for the library?
14:48:12 <jd__> I forgot to comment on the bug
14:48:29 <viktors> dhellmann: hm... :)
14:48:34 <dhellmann> jd__: oh? yeah, please do so we don't remove it prematurely
14:48:51 <jd__> lemmedothatrightnow
14:48:59 <dhellmann> viktors: it seems appropriate, since you are doing so much work on it
14:49:08 <dhellmann> and we need a lead for each library we graduate
14:49:19 * dhellmann can only do so much project planning for ttx
14:49:21 <viktors> dhellmann: can we discuss ti with our team?
14:49:26 <dhellmann> viktors: certainly
14:49:31 <viktors> dhellmann: ok
14:49:49 <viktors> also I want to ask everyone to review patches related to db :)
14:50:26 <dhellmann> yes, if we're close to being ready to graduate it, let's see if we can do it this release cycle
14:50:32 <bnemec> Yeah, our oldest pending review is for db. :-/
14:50:51 <dhellmann> shall we make the db code a focus for reviews over the next week?
14:50:53 <viktors> dhellmann: I hope )
14:51:17 <jd__> FYI https://bugs.launchpad.net/oslo/+bug/1266962/comments/20
14:51:26 <dhellmann> jd__: thanks
14:51:50 <dhellmann> oh, interesting case
14:52:14 <dhellmann> so we may have to take another look at removing the timeutils thing entirely
14:52:21 * dims dropping off. apologies.
14:52:25 <dhellmann> thanks dims
14:52:48 <bnemec> Maybe we could eventually move that to db, if sqlalchemy is the only use case.
14:52:49 <dhellmann> well, everyone please take a look at those db reviews over the next week and let's help viktors and the other people working on the graduation
14:52:55 <dhellmann> bnemec: good point
14:52:58 <bnemec> Would make it clear that it's not supposed to be used for regular tests.
14:53:03 <dhellmann> I like it
14:53:18 <dhellmann> one more topic
14:53:20 <dhellmann> #topic oslo.config futures question from sdague
14:53:36 <dhellmann> sdague: you have the floor
14:53:55 <sdague> oh, right
14:54:10 <sdague> so has anyone thought about validation callback on oslo.config options?
14:54:28 <dhellmann> I'm not sure what you mean?
14:54:50 <sdague> have a function for validating the value given to a config
14:55:05 <jd__> I wrote patches for that long time ago
14:55:05 <sdague> so for instance, if it has to be > 0
14:55:06 <bnemec> Wasn't there just a change merged related to that?
14:55:16 <jd__> the first step was to validate the type
14:55:18 <sdague> I didn't see anything, but I might have missed it
14:55:29 <jd__> because there was things like IntOpt(default='foobar')
14:55:36 <sdague> sure
14:55:52 <jd__> so there's a partial validation now, but it's really lazy and I think not enabled by default
14:55:55 <dhellmann> yeah, we have a "type" argument now that can do some validation
14:55:57 <sdague> basically, I just approved a nova change that was basically config value validation for an option
14:56:08 <jd__> IIRC people were afraid of config file backward compaty
14:56:10 <jd__> -y
14:56:10 <sdague> ensuring it wasn't a negative number
14:56:23 <dhellmann> I think the type support just added would do that
14:56:24 <sdague> which sucks to have to do up in core logic
14:56:31 <jd__> agreed
14:56:31 <sdague> dhellmann: how?
14:56:43 <dhellmann> set type=Integer(min=0)
14:56:48 <sdague> ah
14:56:59 <jd__> OTOH it looks like writing a validation mechanism in 2014 for a configuration library is a sign of failure, isn't there anything we could use and layer over for compat?
14:57:02 <jd__> thinking out loud
14:57:50 <sdague> dhellmann: well if there were docs on that more, that would help get rid of some of this logic
14:58:06 <dhellmann> sdague: yeah
14:58:08 <bnemec> I think it just went in like last week.
14:58:15 <bnemec> But +1 to more doc.
14:58:20 <dhellmann> yeah, it's pretty new
14:58:22 <sdague> I did actually look at an oslo.config pull and couldn't find anything
14:58:32 <sdague> but it was probably unobvious to me
14:58:36 <dhellmann> #action dhellmann open bug to document type arg to config options
14:58:57 <dhellmann> calling it "type" was maybe not the best choice
14:59:24 <dhellmann> ok, we're about out of time
14:59:27 <sdague> yeh, I definitely grepped for valid :)
14:59:31 <bnemec> sdague: https://review.openstack.org/#/c/58960/
14:59:55 <jd__> :(
15:00:03 <dhellmann> one other question before we wrap: would it be useful for us to have these meetings more regularly?
15:00:07 <ttx> dhellmann: about doing project planning for me... you could also argue that some (most?) libs would have their dev disconnected from common release milestones
15:00:19 <dhellmann> ttx: yes, I expect so
15:00:33 <ttx> I know markmc feels strongly about this.. wants oslo libs to be aligned...
15:01:07 <ttx> but they are in fact released out of band
15:01:14 <dhellmann> ttx: that discussion will require beer
15:01:30 <ttx> ("as-needed")
15:01:34 <dhellmann> heh
15:01:54 <ttx> so I don't want to create unnecessary constraints
15:01:58 <dhellmann> we're a bit over time, so think about whether it would be useful to meet more regularly and let me know if you see value
15:02:21 <dhellmann> I don't want to meet just to meet, but coordinating like this is helpful
15:02:34 <bnemec> Yeah, especially as we're trying to get stuff in for I.
15:02:36 <dhellmann> and thanks for the input and help today, everyone
15:03:00 <jd__> thanks :)
15:03:17 <dhellmann> I think I'll start being less shy about scheduling meetings and see how that goes
15:03:37 <bnemec> Sounds good to me.
15:03:47 <jd__> yep
15:03:53 <dhellmann> cool
15:04:05 <dhellmann> we should free up the room in case there's someone else waiting
15:04:08 <dhellmann> thanks again, everyon
15:04:13 <dhellmann> *everyone
15:04:15 <dhellmann> #endmeeting