18:06:07 <gundalow> #startmeeting AnsibleFest Austin: Contributors Summit - Core update
18:06:07 <zodbot> Meeting started Thu Oct  4 18:06:07 2018 UTC.
18:06:07 <zodbot> This meeting is logged and archived in a public location.
18:06:07 <zodbot> The chair is gundalow. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:06:07 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:06:07 <zodbot> The meeting name has been set to 'ansiblefest_austin:_contributors_summit_-_core_update'
18:06:16 <gundalow> #chair abadger1999 alikins bcoca jtanner mattclay maxamillion mordred nitzmahone Qalthos sdoran shepdelacreme sivel thaumos trishnag
18:06:16 <zodbot> Current chairs: Qalthos abadger1999 alikins bcoca gundalow jtanner mattclay maxamillion mordred nitzmahone sdoran shepdelacreme sivel thaumos trishnag
18:06:48 <felixfontein> where's the bluejeans for this meeting?
18:07:01 <nirik> https://redhat.bluejeans.com/4339046286/webrtc
18:07:22 * bcoca waves at gundalow
18:07:32 <felixfontein> now I see gundalow, but with another link
18:07:43 * nirik has to do a quick reboot, be on in a min.
18:08:13 <gundalow> This is https://bluejeans.com/7480904391/ Core
18:08:29 <gundalow> Linux System Roles is in #ansible-meeting-2
18:10:22 <felixfontein> yes
18:10:25 <felixfontein> I can hear you
18:10:26 <bcoca> i can hear you
18:11:01 <bcoca> i unmuted, spoke, remuted
18:11:11 <bcoca> again
18:11:32 <bcoca> use someone else, today Bj has been very unstable with me
18:13:16 <dag> o/
18:13:37 <dag> Maybe next time we should start 30 minutes later by default ;-)
18:13:47 <felixfontein> lol
18:14:34 <dag> if you want involvement, we need e bikeshedding topic ;-)
18:15:21 <gundalow> #topic Challenges Beyond Batteries Included
18:16:13 <gundalow> Question: What's the transition to move modules?
18:16:34 <bcoca> its chicken/egg issue
18:16:56 <bcoca> it would be nice to 'spin off aws' to it's own repo and modify ansible packaging to install directly and/or optionally
18:17:04 <bcoca> kind of ansible-minmal was supposed to be
18:17:57 <bcoca> toaster modules?
18:18:08 <gundalow> bcoca: fictional module :)
18:18:20 <bcoca> ah, i would start with 'new module  line'
18:18:35 <bcoca> or look at tower modules, since we mostly 'control' both sides there
18:20:01 <bcoca> modules are 'independant' of each other so there is really little to gain by moving them all out, it gets a lot trickier with module_utils/action plugins/etc
18:22:10 <bcoca> not even communicated, that is basic assumption with every package
18:22:18 <bcoca> source of package supports contents
18:23:17 <bcoca> mattclay: the way galaxy content is designed, they would need to live in their own repos
18:23:50 <mattclay> bcoca: We should consider how to support them living in one repo.
18:24:07 <bcoca> <= choir, but that is something they currently want to avoid
18:24:14 <bcoca> they want to equate collection == repo
18:25:03 <mattclay> So make ansible/ansible a collection.
18:26:36 <alikins> https://github.com/alikins/ansible-roles-modules   was kind of an old experiment on this idea (using roles, pre collections)
18:27:55 <bcoca> since currently you can 'drop in ' a module and it already can do anything the core ones do, im unsure what gaps there would be with collections
18:29:12 <bcoca> namespacing does not require collections, collections just provide them by default
18:29:19 <bcoca> namespacing is something we need to support in core
18:29:49 <bcoca> ansible. instead of core.
18:29:53 <bcoca> bikeshed ^
18:30:50 <felixfontein> why not std? :P
18:31:02 <bcoca> you'll need shots for that
18:31:52 <bcoca> ansible.callback
18:32:09 <bcoca> even modules when module_utils changes
18:32:18 <bcoca> though we can ship 'updated module_utils'
18:33:39 <felixfontein> yay, dependency hell
18:33:50 * bcoca waves at can of worms
18:35:53 <bcoca> think '
18:35:56 <bcoca> modules-extras
18:37:33 <bcoca> mattclay: yes
18:37:34 <felixfontein> I hear you too
18:38:27 <felixfontein> https://github.com/ansible/ansible-modules-core https://github.com/ansible/ansible-modules-extras :)
18:38:43 <bcoca> modules separate had 2 problems, mainly dual commits
18:38:55 <bcoca> but with 'module_utils' being a plugin most of those issues are gone
18:39:21 <bcoca> the other issue is 'split ticketing'
18:41:40 <felixfontein> ...or the modules they have installed don't work with the new ansible version...
18:41:55 <bcoca> one thing this could do 'better' is including dependant libs
18:42:03 <bcoca> i.e we include aws_modules/plugins but not boto
18:42:17 <bcoca> also we have option of 2 packages
18:42:21 <felixfontein> but then, boto is required on the target machines, not on the host?
18:42:26 <bcoca> ansible (batteries) and ansible-minimal (core)
18:42:36 <bcoca> felixfontein: it gets fun that way
18:42:48 <felixfontein> bcoca: indeed! :)
18:43:14 <felixfontein> maybe some extension of the package manager modules which allow to mention a list of modules, and they install the required libraries for these modules? ;)
18:45:30 <bcoca> 'latest stable release' of those modules
18:46:04 <bcoca> doesnt mean we dont own the other repo
18:49:18 <bcoca> its deprecated
18:50:02 <bcoca> misleadingly 'core'
18:52:10 <dag> Guys, I need to go... indoor soccer
18:52:25 <bcoca> futbito?
18:52:26 <felixfontein> have fun, dag!
18:52:54 <dag> My biggest concern to move modules out of this repo into individual repositories (for Galaxy) is that there's no incentive for people to cooperate
18:53:16 <dag> and you'll find people dumping their own (modified) modules over the wall
18:53:30 <dag> and it will become unclear which module is still maintained and authoritative
18:53:56 <bcoca> that is why galaxy is looking at scoring and 'badges'
18:54:04 <dag> bcoca: that doesn't really help
18:54:11 <bcoca> it helps, does not solve
18:54:25 <dag> no, it may be counterproductive
18:54:45 <dag> because a much better module may never get the same exposure because an old module is still being used by the majority
18:55:13 <bcoca> well, the scoring goes to 'quality' mainly, quantity score will also be there, but not same thing
18:55:13 <dag> there will be a land-grab in the beginning, but over time it's a lost cause IMO
18:55:30 <dag> and things may still get unmaintained, but still popular
18:55:31 <bcoca> possibly, but there are ways to mitigate that
18:55:58 <bcoca> consider that many modules are currently 'unmaintained' though still in ansible/ansible
18:55:58 <dag> no, if one popular module becomes unmaintained, people will basically be told to change their repo's for another one
18:56:01 <dag> which will not happen
18:56:07 <dag> (or will be very inconvenient)
18:56:25 <bcoca> i dont see that as a new problem
18:56:25 <dag> bcoca: at least if someone has an interest *that* module will become maintained again
18:56:37 <dag> not some other module, that people may never find
18:56:40 <bcoca> possibly, but it also makes us a gateway to it
18:56:45 <dag> so there's no incentive to cooperate
18:57:07 <dag> in fact, people do not need to collaborate, upstreaming would mean doing your own, public thing
18:57:08 <bcoca> unless we look at '# of authors' as part of the scoring
18:57:27 <dag> that's why I think we're fixing the wrong thing here, but hey, I have been repeating myself over and over
18:57:32 <dag> indoor soccer time now :)
18:57:35 <dag> bye !
18:57:46 <felixfontein> *wave*
18:57:49 <bcoca> dag: not really, moving the modules out, does not mean ansible team is not handling those repos
18:58:30 <bcoca> *cough* docker *cough*
18:58:32 <dag> well, for most it will
18:58:45 <digigrate_> Is there a roadmap doc for module migration?
18:58:51 <felixfontein> some of the docker modules are not really maintained
18:58:58 <bcoca> no, we just started brainstorming on it
18:59:06 <bcoca> felixfontein: my point exactly
18:59:36 <bcoca> abadger1999: but part of discussing it is so we can also influence mazer design
18:59:41 <felixfontein> I did the "mistake" of subscribing to docker_* notifications. there are *a lot* :)
19:01:45 <bcoca> mattclay: if we eject but still run those tests on the 'module repo' they can be more distributed and still have the coverage
19:02:04 <abadger1999> bcoca: the things we're talking about are strictly social problems... not technical problems.
19:02:26 <abadger1999> maybe the galaxy server could get stuff but I'm not sure...
19:02:39 <abadger1999> (stuff == features to support this)
19:02:41 <alikins> I don't think ejecting is the first goal, but getting it into a modular 'packaged' structure and 'bundle' it
19:02:45 <bcoca> part of the plan there is adding testing for the content
19:03:25 <bcoca> alikins: ejecting from package and ejecting from repo dont need to be related nor coincide in time
19:03:51 <bcoca> also dont think we remove all
19:04:11 <bcoca> removing community makes sense, 'all' does not, imo
19:04:31 <sdoran> Agreed.
19:04:44 <sdoran> we should keep "core" stuff and focus on removing community bits.
19:04:53 <digigrate_> i’m interested in structure/bundle AND testing
19:05:00 <sdoran> That we don't truly support ourselves.
19:05:08 <bcoca> i do think dag has a point and that removing it from repo might break community engagement
19:05:22 <sdoran> That is my biggest concern.
19:05:33 <sdoran> I don't think I'm communicating it well, though.
19:05:46 <sdoran> If we fragment the community, it could hurt engagement.
19:05:57 <sdoran> Folks could get lost figuring out where and how to contribute.
19:06:08 <bcoca> i would argue its already fragmented in that most just want/look at a small subset
19:06:30 <sdoran> Right, but all the PRs go do one repo.
19:06:42 <sdoran> It'd be a change (in the Ansible community) to move to multiple repos.
19:06:57 <bcoca> mattclay: we dont need to move any code/issues if we could support mulitple collections per repo
19:06:58 <sdoran> Ooo backporting would be painful... I didn't think about that.
19:07:18 <bcoca> no, once you kick out you dont backport, we deprecate the module in ansible/ansible
19:07:34 <bcoca> it should be possible for users to download new module version directly
19:08:00 <sdoran> Ok. Just needs communication, but doable for sure.
19:09:39 <bearrito> might've been discussed already, but this sounds like it'll complicate locked down envs without easy access to galaxy or non-satellite hosted rpms
19:09:51 <felixfontein> anyone knows how the relation module_utils <--> modules is? is it possible to split up the whole of support:community into small chunks so that every community-supported file in module_utils belongs to at most one of these chunks?
19:10:10 <abadger1999> bearrito: sdoran has brought that up as "how will downstreams package us in the new world?"
19:10:19 <abadger1999> I think the question remains open
19:10:59 <jhawkesworth_> I'm concerned can't just treat our current groupings of modules i.e. windows as a single thing.  some of the modules will probably allways be core, others community.  so no easy translation to a windows namespace.
19:11:06 <bcoca> we can still build the current tarball even if modules are elsewhere
19:11:40 <bcoca> jhawkesworth_: only if we have mutiple levels
19:11:42 <jtanner> package specs aren't limited to one source tar
19:11:47 <bcoca> windows.iis windows.registry etc
19:12:27 <bcoca> nitzmahone: that was mainly what i proposed with those separations
19:12:43 <bcoca> 'the community' reffered to current maintainers/working groups, many of which are now in core
19:17:45 <bcoca> mattclay: but we do that now, just that they check into core a lot of stuff we cannot test
19:19:55 <bcoca> ^ already said above repo and packaging splits are not tied to each other
19:20:55 * jtanner has purposefully avoided the "kick out" talk
19:21:07 <sdoran> The repo split is more about community, testing, and perception. It's not about packaging and delivery (as I understand it).
19:21:08 <bcoca> we used 'eject'
19:21:33 <geerlingguy> (just adding 2¢) I really hated when we had more than one repo for modules-extras vs ansible core, it added cognitive burden to experience of contribution, searching, etc.
19:21:37 <sdoran> How about "migrate" or "rehome".  (Trying to find buzzword with positive spin :) )
19:21:40 <abadger1999> sdoran: I think those go hand in hand
19:22:03 <geerlingguy> the batteries included is one of the weird things that architecturally I hate, but as an end user it's incredibly awesome
19:22:16 <geerlingguy> Drupal community has had this exact same debate for _years_
19:22:16 <jtanner> unless of course you use a bad battery
19:22:17 <bcoca> mattclay: then we cannot use 'collections' as they currently stand
19:22:20 <geerlingguy> the 'smallcore' initiative
19:22:31 <geerlingguy> basically 'let's rip out all the harder to maintain modules so core maintainers have easier lives'
19:22:44 <jtanner> and "unmaintained"
19:22:46 <geerlingguy> what ended up happening was count of modules in core doubled every release for 6-7, 7-8 :D
19:22:48 <bcoca> its not easier lives, its 'dont give false expectations of support'
19:23:10 <geerlingguy> well that's just a communication issue imo
19:23:20 <geerlingguy> and in docs at least there are flags
19:23:27 <geerlingguy> like "this module has a stable api" or whatever
19:23:37 <bcoca> which we can piont at but then people say 'but it is in your package'!
19:24:06 <jtanner> redhat has a motto of "we ship it, we support it" which is driving a lot of this discussion
19:24:12 <bcoca> he, i got him off 'core.'
19:24:15 <jborean93> I think the docs right now are a bit unclear as to what is core and what isn't
19:24:23 <jhawkesworth_> renamespacing at packaging time sounds like it could cause testing problems
19:24:25 <jtanner> they're clear, but people don't read it
19:24:41 <jborean93> jtanner: I disagree, they may not ready it but it isn't really clear
19:24:54 <bcoca> its not just RH motto, that is what most people expect when you 'ship it'
19:25:08 <jtanner> first result for "ansible core supported modules": https://docs.ansible.com/ansible/2.6/user_guide/modules_support.html
19:25:26 <jborean93> understand that, but the module pages themselves don't show if it core or not
19:25:35 <bcoca> jborean93: yes they do
19:25:41 <jborean93> bcoca: where?
19:26:00 <jborean93> I see a Support section for core ones but nothing that explicitly says they are core, the support is just a generic read this KB
19:26:05 <bcoca> https://docs.ansible.com/ansible/latest/modules/copy_module.html?highlight=copy#support
19:26:19 <bcoca> well, then lets clarify that
19:26:25 <jborean93> yes we should
19:26:27 <bcoca> it used to be a lot more explicit when core/extras
19:26:40 <jborean93> non core don't even have the support, so unless you know that means core or not it's confusing
19:27:01 <jborean93> Having an extra in the status section would help, in my opinion
19:27:05 <felixfontein> other modules have no information about support in the docs
19:27:06 <sdoran> Yeah, that note is absent on community module. We could improve the visibility of that in the docs pages.
19:27:11 <sdoran> Maybe a new color! ;)
19:27:29 <bcoca> jborean93: that is a bug, they used to have 'community' and other metadata status
19:27:41 <bearrito> yeah, that support section should have the classification stated there
19:27:46 <sdoran> `ansible-doc` shows the METADATA
19:27:47 <jborean93> bcoca: it shows the interface status but that's it
19:27:54 <jborean93> been like that for a long time now
19:27:55 <bcoca> that is a doc bug
19:28:01 <jborean93> cool
19:28:05 <bcoca> i dont normally read the html but that is clearly a bug
19:28:15 <bcoca> we had 'all support states' with a blurb there
19:28:27 <jborean93> I think since the redesign it dissapeared
19:28:36 <bcoca> i say BUG!
19:28:36 <jtanner> if "fixing" it, would also be nice for the support description to link back to the other page of categories
19:29:46 <jborean93> jtanner: to show other modules that are in that category?
19:29:48 <abadger1999> I think that dylan and I finally arrived at that version.
19:29:54 <jtanner> jborean93: yes
19:30:11 <abadger1999> Looking at the template, what it lacks is a "non-core, non-network" section.
19:30:11 <bcoca> jtanner: per module page? that will be expensive generating and 'reading'
19:30:29 <bcoca> seems like those were removed
19:30:45 * mattclay steps away for a few minutes
19:30:47 <jtanner> in the module page where it will say "this is core supported", the word core could be a hyperlink to the other page
19:30:48 <jborean93> is it expensive to generate it with a link?
19:31:02 <abadger1999> current =>   if supported_by: core, network:  Red Hat supports this module.   Need to add an else: This module is not supported by red hat.
19:31:05 <bcoca> a link no, the list of all modules that match, yes
19:31:16 <jtanner> didn't ask for list
19:31:37 <bcoca> sorry misinterpeted" to show other modules that are in that categoy"
19:31:47 <abadger1999> It should not be expensive to link back.
19:31:50 <felixfontein> the only interesting list is probably a list of modules supported by Red Hat
19:31:55 <jborean93> I think we should always have the Support section, maybe even put it at the top
19:32:11 <jborean93> and have that list back to the module index per type like jtanner says
19:32:11 <jtanner> felixfontein: that's core and network and eventually certified
19:32:25 <bcoca> import q/q() or embeded print()
19:32:51 <bcoca> 'what we use for debug'
19:32:51 * jborean93 sorry for derailing the packaging talk
19:33:03 <bcoca> jborean93: no, that is a bug we need to fix
19:33:16 <bcoca> about making it more visible, i would make a 2nd issue as 'feature request'
19:33:35 <bcoca> and i think we already have a list of 'supported' modules somewhere, we were required to build it
19:34:05 <jborean93> yep jtanner posted the link https://docs.ansible.com/ansible/2.6/user_guide/modules_support.html, each section then has a link to a list of modules per category
19:34:36 <jtanner> https://github.com/jctanner/ansible-tools
19:34:38 <jborean93> I can create a PR to fix the bug, did we just want to make sure the Support section is always returned and link to the module index?
19:34:43 <bcoca> keep remote files + strace ...
19:35:06 <bcoca> nitzmahone: iirc there is way to do remote pdb with vim
19:35:25 <acozine> jborean: link to PR?
19:35:49 <acozine> oh, nm, I misread "can create" vs "have created"
19:35:50 <gundalow> #action gundalow to turn debug stuff into a blog post
19:36:12 <jborean93> acozine: I will send you one, when I create it unless you wish to do the work?
19:36:48 <acozine> jborean93: thanks, if you did it, I'd be happy and grateful
19:36:56 <jborean93> no worries
19:36:58 <bcoca> one problem with import q, does not work with Mock
19:37:45 <bcoca> but that is almost a 'safety' so i dont leave 'import q' inline when checking in
19:37:51 <abadger1999> jborean93: https://github.com/ansible/ansible/blob/devel/docs/templates/plugin.rst.j2#L399 <==== you just need an else for this clause (and to add the links that jctanner requested)
19:38:06 <abadger1999> import q works with mock.
19:38:07 <jtanner> https://tannerjc.net/wiki/index.php?title=Ansible_Developer_Filament
19:38:15 <abadger1999> git hook!
19:38:34 <bcoca> PR 'remove spurious print()'
19:38:45 <sdoran> Yup. I wrote something to "clean my debugging" .
19:39:03 <gundalow> #action add `ansible-test sanity` check for `q`
19:39:16 <bcoca> our tests, mock protests about import q
19:39:45 <abadger1999> You;ll have to show me because I don't know what that would be.
19:39:56 <bcoca> k
19:41:13 <bcoca> yes, but BEFORE we do the work
19:41:43 <bcoca> proposal is for discussion
19:43:29 <mattclay> I'm back.
19:43:44 <jborean93> having the meeting at the current time is hard for people in my time zone
19:43:49 <jborean93> so proposals are quite difficult
19:44:21 <bcoca> opinoins have diverged on the subject
19:46:35 <bcoca> beer?
19:46:57 <bcoca> workshops also
19:47:10 <abadger1999> pair programming could really be nice
19:47:21 <sdoran> +1
19:47:44 <sdoran> AnsibleFest Sprints!
19:48:04 <bcoca> but that requires well defined and narrowly scoped projects
19:48:23 <sdoran> Just "work on Ansible" 😉
19:48:28 <bcoca> not 'implement platform'
19:48:30 <jtanner> fix ALL the bugs
19:48:33 <felixfontein> lol
19:48:34 <bcoca> or my 'vars proposal'
19:48:43 <felixfontein> jtanner: 12389 hours hackathon?
19:48:46 <bcoca> role spec might have been 'right size'
19:50:18 <jtanner> tear down the walls
19:50:42 <bcoca> openstack needed core to discuss update_json and module/plugin blacklisting
19:50:52 <felixfontein> would that work well with remote attendance (bluejeans)?
19:51:01 <bcoca> galaxy and documentation were both talking about arg_spec refactor at same time
19:51:25 <sdoran> Themed groups work well: Windows, AWS, Networking, System, Core, etc.
19:51:35 <bcoca> yeah, but the overlap kills us
19:51:43 <gundalow> https://etherpad.openstack.org/p/ansible-summit-october-2018 line 151 for feedback please
19:51:52 <bcoca> dag was in 2 meetings every session
19:52:07 <bcoca> I CAN BE QUIET, REALLY
19:52:15 <jtanner> a quiet chipmunk
19:52:43 <felixfontein> if people are saying something, it isn't understandable on bluejeans
19:52:54 <jtanner> nah, was unrelatd
19:52:56 <bcoca> that has been issue with 1/2 the sessions
19:52:57 <felixfontein> ok
19:53:18 <felixfontein> from remote it is hard to judge what is unrelated and what was important if you can't hear it :)
19:54:40 <shertel> audio has been pretty clear for me felixfontein
19:55:16 <bcoca> some sessions were fine, others either you only heard speaker or it just went out all the time
19:55:39 <felixfontein> yep. this one was very good I think.
19:56:07 <jtanner> everyone sits in a room and solves the oldest bug in ansible
19:57:34 <bcoca> https://github.com/ansible/ansible/issues/10121
19:57:43 <abadger1999> jtanner: That could be neat.  Have a laptop, a big screen, and pairs of people go up to work on identifying and then implementing a fix for the bug ;-)
19:57:53 <bcoca> https://github.com/ansible/ansible/issues/10374 < 2nd oldest
19:58:09 <jtanner> reproducing bug could be 80% of the time consumed
19:58:23 <bcoca> https://github.com/ansible/ansible/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc
19:59:41 <jtanner> https://github.com/ansible/ansible/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+sort%3Acreated-asc+label%3Abug+-label%3Asupport%3Acommunity
20:01:36 <jtanner> reproducing a bug is a great intro to git/scm + github + ansible + etc
20:02:27 <geerlingguy> AnsibleFest Sprints+1
20:02:40 <geerlingguy> That is practically the only reason I still go to DrupalCons. Best part for me
20:03:06 <bcoca> AnsibleFest Strolls+1 .. some of us are not as spry as we used to and sprinting is asking too much
20:03:15 <geerlingguy> lol
20:03:26 <jtanner> Ansible Hobble
20:03:35 <bcoca> im not THAT old!
20:04:36 <bcoca> we had that in previous fests 'the expert' and 'the subject matter'
20:05:21 <bcoca> robyn: and offer discount?
20:07:59 <bcoca> 'ask a vendor'
20:08:32 <bcoca> the proposal sounds good, but your sanity is diff issue
20:09:00 <bcoca> 'napfest'
20:10:41 <chouseknecht> +1 for sprints
20:10:55 <chouseknecht> or hobbles
20:19:13 <sdoran> Well, meeting a badger in person can be dangerous, especially if it's a wild badger.
20:20:13 <bcoca> i want a bcoca rubber duck
20:20:37 <abadger1999> This one is an Anonymous Badger
20:20:44 <bcoca> lol
20:20:56 <abadger1999> A.Badger
20:21:00 <sdoran> Anonymous no more!
20:21:02 <sdoran> ;)
20:21:09 <bcoca> i know carrie ann has chased more than one of us for pictures for 'ask an expert' fliers
20:21:37 <bcoca> robeeeeyn
20:23:10 <abadger1999> And if you call him f13 he'll get really confused ;-)
20:23:31 <jtanner> there's no f13 on my keyboard, so i can't
20:23:45 <abadger1999> If you had one, we'd have to call you f13 ;-)
20:24:37 <bcoca> also you are 'old python version killer'
20:24:50 <jtanner> snake charmer
20:25:14 <bcoca> unicode magician?
20:25:22 <bcoca> unimancer?
20:25:39 <jtanner> bytebasher
20:26:06 <bcoca> botmaster
20:26:10 <bcoca> ^ u now
20:26:56 <bcoca> spoilers!
20:28:03 <abadger1999> you're both samdoran and sdoran!
20:28:22 * abadger1999 keeps cc'ing the wrong guy on github
20:28:41 <sdoran> Yeah, that's an unfortunate collision.
20:29:15 <gundalow> #endmeeting