15:01:17 <langdon> #startmeeting modularity_wg
15:01:17 <zodbot> Meeting started Thu May 19 15:01:17 2016 UTC.  The chair is langdon. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:17 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:01:17 <zodbot> The meeting name has been set to 'modularity_wg'
15:01:27 <haraldh> o/
15:01:44 <langdon> #chair ausil, cydrobolt, harald, jkurik, langdon, mikedep333, sct, tflink
15:01:44 <zodbot> Current chairs: ausil cydrobolt harald jkurik langdon mikedep333 sct tflink
15:01:44 * threebean 
15:01:54 <langdon> #topic roll-call
15:01:59 <langdon> .hello langdon
15:02:00 <zodbot> langdon: langdon 'Langdon White' <langdon@fishjump.com>
15:02:06 <jkurik> .hello jkurik
15:02:07 <jkaluza_> .hello jkaluza
15:02:07 <zodbot> jkurik: jkurik 'Jan Kurik' <jkurik@redhat.com>
15:02:09 <tflink> .hello tflink
15:02:10 <zodbot> jkaluza_: jkaluza 'Jan Kaluža' <jkaluza@redhat.com>
15:02:10 <cpacheco> .hello cpacheco
15:02:12 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:02:15 <nils> .hello nphilipp
15:02:16 <zodbot> cpacheco: cpacheco 'Courtney Pacheco' <cpacheco@redhat.com>
15:02:19 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
15:02:19 <haraldh> .hello harald
15:02:22 <zodbot> haraldh: harald 'Harald Hoyer' <harald@redhat.com>
15:02:29 <geppetto> .hello james
15:02:30 <zodbot> geppetto: james 'James Antill' <james.antill@redhat.com>
15:02:35 <bollocks_k> .hello bollocks
15:02:36 <zodbot> bollocks_k: bollocks 'Keith Sands' <bollocks.k2@gmail.com>
15:02:37 <yselkowitz> .hello yselkowitz
15:02:39 <zodbot> yselkowitz: yselkowitz 'Yaakov Selkowitz' <yselkowi@redhat.com>
15:02:55 <langdon> #topic agenda
15:03:12 <langdon> #link http://piratepad.nl/modularity-wg-agendas < agenda
15:03:35 <langdon> #info the plan is demos, diagram update, and core-naming
15:03:50 <langdon> cpacheco, do you want to talk about demos?
15:04:06 <langdon> #topic demos: where, when, how update (lead by cpacheco)
15:04:10 <langdon> oops
15:04:12 <langdon> #undo
15:04:12 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x625919d0>
15:04:15 <langdon> before that
15:04:22 <langdon> any other agenda items to add?
15:04:42 <threebean> none here.
15:04:59 <langdon> ok.. we will probably have some open floor time any way
15:04:59 <threebean> I'm eager to talk about SLA/EOL stuff, but we should wait for next week when sct is available, I think.
15:05:19 <langdon> threebean, probably a good idea.. i think he wanted to write some stuff up about it..
15:05:20 <jkurik> no item atm
15:05:35 <tflink> has the meeting time issue been figured out?
15:06:05 <langdon> fyi for anyone who didn't see it.. basically, threebean is referring to "how do we incorporate EOL information in to a module version" and "how do we version in general"
15:06:14 <langdon> tflink, no.. arggh
15:06:36 * langdon has had a very complicated couple of weeks (personal stuff).. so is a bit behind on follow ups
15:06:53 <langdon> all right, moving on?
15:07:04 <threebean> +1
15:07:13 <langdon> #topic demos: where, when, how update (lead by cpacheco)
15:07:18 <langdon> #chair cpacheco
15:07:18 <zodbot> Current chairs: ausil cpacheco cydrobolt harald jkurik langdon mikedep333 sct tflink
15:07:22 <langdon> cpacheco, take it away
15:07:25 <cpacheco> Sure :)
15:07:33 <cpacheco> So... demo videos will be uploaded to this channel: https://www.youtube.com/channel/UC4O8G9SZwqtkIAuKcT8-JpQ
15:07:45 <cpacheco> This is the official Fedora Modularization YouTube channel
15:08:02 <cpacheco> Currently, cpachec, langdon, vkaras, and wchadwic have access to upload videos to the channel
15:08:07 <langdon> #link https://www.youtube.com/channel/UC4O8G9SZwqtkIAuKcT8-JpQ : official fedora modularization youtube channel, demos will be found there
15:08:30 <cpacheco> Videos uploaded to the channel are set as "private" until one of the channel "managers" approves it
15:08:55 <cpacheco> Not all videos uploaded to this channel will be public, as some of the demos we want to keep private
15:09:05 <cpacheco> but it is a good place to host all of our videos, nonetheless
15:09:39 <cpacheco> In general, we plan to keep our demos to 2-5 minutes long. We don't want them too long because we want to keep viewers' interest..
15:09:45 <jkurik> cpacheco: what means "private" ? Can at lest members of this WG see it ?
15:09:54 <cpacheco> No, not everyone
15:09:56 * langdon doesn't foresee "private videos"
15:10:18 <cpacheco> Some of our demos are a work in progress and not ready to be made public
15:10:36 <langdon> we do want to have a bit of a gate on "quality".. more than "private"
15:10:50 <cpacheco> Yeah, maybe that's a better way to put it
15:10:53 <yselkowitz> we're working on fedora, not rhel, there shouldn't be anything "private"
15:10:57 <nils> some of our demos are "I learnt this and researched that " and aren't of general interest
15:11:16 <yselkowitz> playlists
15:11:25 <threebean> yselkowitz++
15:11:41 <langdon> lets just say that "nothing will be private" as long as it isn't junk.. then it will just be deleted :)
15:12:13 <langdon> does that work for everyone?
15:12:16 <jkurik> langdon++ makes sense
15:12:16 <zodbot> jkurik: Karma for langdon changed to 11 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:12:35 <tflink> wfm
15:12:49 <langdon> ok
15:13:05 <langdon> and -1? i can't imagine.. but have to ask ;)
15:13:47 <threebean> cpacheco: so for the scheduled demo time tomorrow..
15:13:53 <langdon> #agreed all demos in yt channel will be made public as soon as possible by a yt manager
15:14:10 <threebean> we'll submit our invidividual videos to the fedorapeople space, ping you, and then they'll be uploaded.
15:14:18 <cpacheco> threebean: correct
15:14:18 <threebean> and we'll show them all at the same time tomorrow?
15:14:30 <cpacheco> yes
15:14:34 <threebean> cool, thanks.  :)
15:14:49 <jkaluza_> Is there any live demo following that, or we will just upload everything and we are done?
15:14:52 <nils> cpacheco++ thanks for fixing the ACL
15:14:52 <zodbot> nils: Karma for cpacheco changed to 1 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:14:57 <langdon> basically .. that scheduled time is to force some people (mostly in rh) to watch it.. not an "availability" thing.. more a "make sure people block out the time" thing
15:16:27 <langdon> jkaluza_, i think the plan, cpacheco correct me if i am wrong, is .. demo-maker ups to fp.o, cpacheco or someone puts it in yt, manager of yt approves, playlist is make called "sprint xyz" pointing at the videos, mail sent to @devel announcing playlist..
15:16:42 <langdon> *playlist is made
15:16:46 <cpacheco> yeah, that's correct
15:16:51 <jkaluza_> ok, thanks
15:16:54 <cpacheco> then everyone who wants to see it can see it
15:17:03 <jkaluza_> great, makes sense
15:17:06 <langdon> but.. we also want to force some people to see it ;)
15:17:39 <langdon> is that ^^ worth an #info?
15:18:19 <threebean> langdon: sure, yes.
15:18:30 <langdon> ok.. may need a re-write
15:18:58 <jkaluza_> The deadline for demos will be always friday after sprint?
15:19:05 <jkaluza_> could be in #info too, if that's true
15:19:16 <nils> jkaluza_: after stand-up you mean?
15:19:20 <langdon> jkaluza_, i would prefer it is the last day of sprint.. the work to make the demo should be in the sprint
15:19:36 <nils> absolutely, langdon++
15:19:36 <zodbot> nils: Karma for langdon changed to 12 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:19:37 <langdon> so .. if we are ending on tuesdays.. your monday should be making the demo (or something)
15:19:47 <jkaluza_> langdon: I agree, just put it to #info :)
15:20:00 <langdon> jkaluza_, working :)
15:20:07 <langdon> #chair jkaluza_
15:20:07 <zodbot> Current chairs: ausil cpacheco cydrobolt harald jkaluza_ jkurik langdon mikedep333 sct tflink
15:20:10 <langdon> you can type it :)
15:20:17 <jkaluza_> heh
15:20:20 <langdon> umm.. cpacheco link to fp.o space?
15:20:28 <cpacheco> yeah, let me get it
15:20:38 <cpacheco> https://fedorapeople.org/groups/modularity/
15:20:57 <jkaluza_> langdon: including the plan you've mentioned, right?
15:20:59 <cpacheco> It's basically a "repo" where we keep all of our videos
15:21:08 <langdon> jkaluza_, no.. not yet.. im writing that one
15:21:39 <cpacheco> videos from the fp.o will be uploaded to YouTube by one of the channel managers
15:21:48 <langdon> #info demo plan: demo-maker added to modularization fas, demo-maker ups to fedorapeople.org/groups/modularity/, yt-channel editor ups to youtube, manager of yt approves (basically 2-ack release process), playlist is made called "sprint xyz" pointing at the videos, mail sent to @devel announcing playlist
15:22:11 * langdon will do the other now
15:22:16 <jkaluza_> ok
15:22:34 <decause> .hello decause
15:22:35 <zodbot> decause: decause 'Remy DeCausemaker' <decause@redhat.com>
15:22:46 <langdon> #info demos are due on last day of sprint, currently every other tuesday, and email should be sent before next WG meeting
15:23:14 <nils> the path where to put demo videos is /srv/groups/modularity when logged into fp.o
15:23:34 <langdon> nils, ahh thnks.. that was what i meant to ask for.. i haven't tried it..
15:24:01 <langdon> #info path to put videos when ssh'd in to fp.o is /srv/groups/modularity
15:24:02 <cpacheco> everyone on the modularity team should have access to it. i encourage anyone on the team who can't access it to contact me
15:24:04 <nils> everybody in the modularity-wg unix group should be able to write there
15:24:30 <langdon> ok.. any other qs about demos?
15:24:46 <langdon> ok.. moving on then
15:25:07 * langdon looks for handy agenda window
15:25:12 <langdon> #topic diagram(s) update (lead by threebean)
15:25:15 <threebean> hi
15:25:19 <langdon> ok.. threebean updates?
15:25:24 <langdon> #chair threebean
15:25:24 <zodbot> Current chairs: ausil cpacheco cydrobolt harald jkaluza_ jkurik langdon mikedep333 sct tflink threebean
15:25:46 <threebean> so, recall that in previous weeks we did studies of the workflow and a subset of the infra for packages:
15:25:48 <threebean> http://threebean.org/img/modularity/life-of-a-package-update-current.png
15:26:13 <threebean> we then extended that to a hypothetical study of what it would take for a packager to maintain modules "by hand":
15:26:15 <threebean> http://threebean.org/img/modularity/life-of-a-package-update-future-no-automation.png
15:26:41 <threebean> at this point, we have together the beginnings of a proposal for what kinds of changes we'll need to make to the infra to support automation for module maintainers in infra:
15:26:43 <threebean> https://www.lucidchart.com/documents/view/506affde-d1d7-4031-9e01-32feabcc5632
15:27:08 <threebean> so - that's the update in a nutshell.  we've had some discussions about that in #fedora-modularization and have run it by fedora-releng at this point.
15:27:29 <langdon> well.. really it is build and automate.. right? like we couldn't really do even the manual version yet?
15:27:41 <threebean> next steps will be to draft an accompanying document, get it on a wiki page, and send it out to some more groups - fedora-infra in particular.
15:27:53 <threebean> langdon: hah, yes.  right.
15:28:09 <langdon> :(
15:28:14 <langdon> ok
15:28:24 <langdon> questions? want some time to peruse for a few?
15:28:43 <threebean> I'll point out that there are open questions that the diagram fumbles on or is missing...
15:28:56 <threebean> 1) there's this open question about how we'll model and maintain the SLA/EOL status of modules.
15:29:06 <tflink> threebean: are we purposely limiting testing/CI to the build phase?
15:29:21 <tflink> ie, why not enable checks/tests/whatever @ dist-git change time etc.
15:29:32 <threebean> currently, all packages in fedora just carry the same SLA/EOL status as the distro-release they're associated with, but we want modules to be somewhat decoupled from that.  there's a big policy question there, as well as an infra "how do we model and track that" question.
15:29:52 <threebean> tflink: that is not an unreasonable proposal.
15:30:07 <threebean> tflink: yeah, no reason not to do that.
15:30:08 <langdon> threebean, is that not what is modeled here?
15:30:08 <tflink> it's on our roadmap anyways
15:30:23 <tflink> er, on the taskotron roadmap
15:30:40 <threebean> langdon: in the diagram, taskotron is only explicitly listening to koji builds.  tflink's point is that it could also do useful things *before* the build happens, but after the dist-git commit is made.
15:31:10 <langdon> so a test before compiled? e.g. like a lint? or am i missing something?
15:31:20 <tflink> or at any point where a fedmsg is emitted
15:31:29 <jkaluza_> reading the "backporting the security patch", what do you mean by "applying patch to all of those (git hashes)"
15:31:51 <threebean> jkaluza_: there's some description of it further on in here:  piratepad.nl/backporting-with-modules
15:31:56 <jkaluza_> Some example of git workflow would definitely help in some future description
15:32:06 <threebean> yes.
15:32:07 <tflink> langdon: yeah, that's what I was thinking but I don't know if something like that would be useful
15:32:08 <threebean> however..
15:32:29 <threebean> the model that we're going to use for identifying unique models in dist-git is under debate.
15:32:35 <jkaluza_> threebean: I will read it in the evening, thanks
15:32:50 <threebean> some people (as is mentioned in that diagram) argue for using git hashes directly to uniquely identify a module.
15:32:58 <langdon> tflink, threebean ahh ok.. that makes sense.. definitely +1 to the idea
15:32:58 <jkaluza_> Otherwise the diagram makes sense to me
15:33:00 <threebean> and there are problems with that, like the piratepad and the diagram get in to, jkaluza_.
15:33:33 <threebean> there are other proposals in the works to instead use git branches or tags.  but there are also problems there.  sct I think is charged with working on the solution, but unfortunately he's out this week in other meetings.
15:33:36 <tflink> langdon: or if there are any other points in the process that would be useful to trigger checks, we're not just limited to koji build complete and dist-git receive messages
15:33:39 <langdon> i was confused because i thought tflink/threebean was implying there was some gate before tests happened on a commit
15:33:40 <threebean> jkaluza_: cool :)
15:34:15 <langdon> tflink, +1
15:34:18 <threebean> tflink: correct - for instance, post-compose.  right now we have openqa doing those image checks but we hope to pull that under taskotron's domain for future sanity.
15:34:32 <threebean> (right?)
15:34:35 <tflink> yeah
15:34:35 <jkaluza_> threebean: Does it mean that it should automatically apply the patch to various hashes (versions) of the package?
15:34:46 <langdon> threebean, sct has some pretty strong ideas on versioning-stuff.. so is writing up a strawman
15:35:06 <jkaluza_> hm, actually, I will just rtfm before asking, ignore me
15:35:13 <threebean> jkaluza_: in the use-git-hashes-to-uniquely-identify-stuff proposal, yes.  I'm not a fan of that.  using-git-branches-to-unmiquely-identify-stuff gets around that.
15:35:25 <langdon> jkaluza_, i want to add magic in there for backporting too :)
15:35:33 <jkaluza_> +1 for branches
15:35:45 <jkaluza_> note that the patch does not have to apply in all cases, which is what wories me a bit
15:35:56 <jkaluza_> for branch, you can apply manually
15:36:21 <jkaluza_> I cannot imagine how it would work without branches on git level currently
15:36:49 <langdon> jkaluza_, can you describe a scenario where a patch wouldn't apply?
15:37:04 <langdon> do you mean "not easily" or you don't want it?
15:39:18 <langdon> jkaluza_, ^^ ?
15:39:22 * threebean holds up a "rat hole" sign
15:39:25 <langdon> ha
15:39:27 <langdon> ok..
15:39:30 <langdon> threebean, are your docs in enough shape to send to the ML for discussion?
15:39:36 <threebean> for real, wait for sct's strawman on versioning.  then we can argue.
15:39:55 <threebean> langdon: not yet.  I'm going to try to finish them in tandem with my video for the demo tomorrow.
15:39:58 <threebean> so, tomorrow or bust.
15:40:01 <langdon> ok.. cool
15:40:04 <langdon> next topic?
15:40:07 <jkaluza_> Well, I have bad permissions set in spec file %files section, I fix one file in %files and commit, then fix another and commit. Now the last commit cannot be applied to original git state
15:40:17 <jkaluza_> that's just dumb example
15:40:32 <jkaluza_> but well, I will read the doc, not sure I understand it correctly
15:40:40 <langdon> jkaluza_, ok
15:40:57 <langdon> #topic core/"base runtime"/base naming and what it is
15:41:20 <langdon> so.. this has been coming up a bit.. and bconoboy was interested..
15:42:11 <langdon> basically.. we have this idea of separating user space from "other space".. and what do we call "other space" .. and how do we provide an api/abi to user space that is reliable
15:43:07 <langdon> which is kind of at the core of modularity (sorry for word collision) .. we need to have modules have a separate lifecycle from other things.. including hardware.. but.. sometimes.. that is "longer" not shorter..
15:43:42 <haraldh> not sure I can follow
15:43:42 <langdon> aka mariadb has ~5yr lifecycle.. so can it sit on the same "other space" while things like the kernel change underneath it?
15:43:53 <haraldh> ah
15:44:10 <haraldh> you mean API dependency or better non-dep
15:44:22 <langdon> so the kernel can update every ~6 months.. (or 13m which is fedora-eol now)
15:44:50 <langdon> right.. and what is "that thing".. we were calling it "base".. but that kinda implied something else.. core is not a great choice ..
15:45:04 <langdon> bconoboy proposed "base runtime" which i kinda like
15:45:52 <haraldh> "base runtime" , "gnome3 runtime"
15:46:15 <haraldh> https://blogs.gnome.org/alexl/2015/03/31/official-gnome-sdk-runtime-builds-are-out/
15:46:26 <langdon> haraldh, i would imaging g3-rt would sit on top of this base thingy right?
15:46:32 <haraldh> sure
15:46:41 <langdon> ohh.. are you saying it is "taken"?
15:46:53 <haraldh> no, the name "runtime" is fine
15:46:56 <langdon> i think i read that article a while back..
15:46:59 <haraldh> complements the others
15:47:11 <langdon> ahh ok.. cool..
15:47:13 <jkurik> I always expected the "core" will be something like Atomic - just a minimalistic set of packages. However "base runtime" looks to me like something wider
15:47:14 <jkaluza_> I also like base runtime
15:48:22 <jkurik> so it probably depends what you want to have in the "core"
15:48:23 <langdon> jkurik, right.. that was kinda my thinking too.. that it could change underneath.. but its "surface" might last for a 5yrs (making up a number, but "long") .. so that new hardware could come in.. but you wouldn't have to rebuild maria.. unless it used a kernel-mod (or something)
15:48:37 <haraldh> also "runtime" originates to http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html
15:48:57 <haraldh> "
15:48:57 <haraldh> runtime:<vendorid>:<architecture>:<version> -- This refers to a vendor runtime. A runtime here is supposed to be a set of libraries and other resources that are needed to run apps (for the concept of apps see below), all in a /usr tree. In this regard this is very similar to the usr sub-volumes explained above, however, while a usr sub-volume is a full OS and contains everything necessary to boot, a runtime is really only a set of libraries. You canno
15:48:57 <haraldh> t boot it, but you can run apps with it. An example sub-volume name is: runtime:org.gnome.GNOME3_20:x86_64:3.20.1
15:48:58 <haraldh> "
15:49:59 <langdon> haraldh, well.. "originates in this context" maybe ;)
15:50:06 <haraldh> yeah
15:50:08 <haraldh> of course
15:50:20 <haraldh> but that's how things started with the xdg-app thing
15:50:41 <langdon> yeah.. i like how some of that works..
15:51:13 <langdon> i also liked that post.. i just don't think we need to do it with overlay filesystems (maybe)
15:51:16 <haraldh> and we called that initially "core os"
15:51:24 <langdon> LOL.. really?
15:51:28 <haraldh> yep
15:51:38 <haraldh> and someone started a company then :)
15:51:43 <langdon> ha
15:51:57 <langdon> names are hard..
15:51:59 <haraldh> which is exactly what "base runtime" is
15:52:52 <haraldh> we can call it "core runtime"
15:52:56 * jkurik is googling for "base runtime" startup company
15:52:58 <haraldh> which I like more, though
15:53:06 <langdon> ooo.. i kinda like that too
15:53:06 <bconoboy> core is used too much- base runtime is nice because it's more descriptive
15:53:21 <haraldh> if you say so.. you are the native speakers
15:53:27 * langdon is kinda like a gadfly
15:53:43 * langdon technically is not a native english speaker ;)
15:53:45 <bconoboy> I'm good with either one- the important thing is we stop talking about "core" and start talking about what these thigns are
15:53:55 <bconoboy> adding runtime is really clarifying
15:54:07 <langdon> yeah.. i was typing that too.. when i got distracted -> SQUIRREL :)
15:54:10 <nils> langdon: ...go on :)
15:54:33 <bconoboy> you can also say things like "base kernel" or similar
15:54:55 <bconoboy> I don't really care if it's "base" or "core", but let's put a second descriptive word in there
15:55:03 <langdon> so.. the idea is .. it is more than "a set of packages that are core to the system" .. it is a "set of functions/services/some-cs-word that user space relies on"
15:55:06 <haraldh> yeah, "naming" .. one of the bigger problems in IT :)
15:55:21 <langdon> ok.. i vote "base runtime" ... and call it a day..
15:55:25 <haraldh> +1
15:55:33 <jkurik> +1
15:55:38 <bconoboy> (is this an official vote?)
15:55:44 <langdon> but .. can anyone else comment on "do you understand what we mean?" to make an informed decision?
15:55:59 <langdon> bconoboy, wasn't quite yet... i wanted to ask the above first
15:56:44 <langdon> haraldh, we are also trying to do versioning.. one of the others.. cause we like pain ;)
15:56:48 <jkurik> for me "base runtime" is what you have described as "set of functions/services/some-cs-word that user space relies on"
15:57:14 <langdon> any one else want to weigh in?
15:57:40 <langdon> ok.. official vote then.. /me hopes he isnt typing too fast
15:58:05 <bconoboy> langdon: can you restate what is to be voted on?
15:58:12 <tflink> +1 to base runtime
15:58:54 <langdon> "base runtime" == "set of functions/services/some-cs-word that user space relies on" which replaces the term "core" or "base" as used previously
15:58:54 <langdon> +1
15:58:54 <langdon> ^^ how's that /me was typing ;)
15:58:59 <haraldh> +1
15:59:24 <haraldh> "user space" == apps?
15:59:41 <jkurik> +1
15:59:43 <langdon> more like ~= ... but yeah
15:59:53 <langdon> ok.. so i have +1 from jkurik, haraldh, me, tflink and no -1s so i am call it "sold!"
16:00:31 <langdon> #agreed "base runtime" == "set of functions/services/some-cs-word that user space relies on" which replaces the term "core" or "base" as used previously
16:00:51 <langdon> woohoo.. and time is up.. i can hang out a bit for open floor though..
16:00:57 <langdon> else.. thanks all for coming!
16:01:03 <langdon> #topic open floor
16:01:14 <langdon> anyone?
16:01:27 <jkaluza_> ... and usa won over the czech republic in hockey
16:01:39 <langdon> jkaluza_, ha :)
16:02:05 <geppetto> jkaluza_: Is that ice hokey?
16:02:11 <langdon> #chair dgilmore
16:02:11 <zodbot> Current chairs: ausil cpacheco cydrobolt dgilmore harald jkaluza_ jkurik langdon mikedep333 sct tflink threebean
16:02:13 <dgilmore> is that even a thing :P
16:02:22 <langdon> ha
16:02:29 <langdon> ok.. well.. on that note..
16:02:36 <langdon> going once...
16:02:43 <langdon> going twice...
16:02:52 <langdon> going thrice...
16:02:54 <jkurik> thanks langdon for hosting
16:03:00 <langdon> #endmeeting