16:30:01 <bgilbert> #startmeeting fedora_coreos_meeting
16:30:01 <zodbot> Meeting started Wed Nov 28 16:30:01 2018 UTC.
16:30:01 <zodbot> This meeting is logged and archived in a public location.
16:30:01 <zodbot> The chair is bgilbert. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:30:01 <zodbot> The meeting name has been set to 'fedora_coreos_meeting'
16:30:05 <bgilbert> #topic roll call
16:30:05 <ajeddeloh> .helo2
16:30:09 <ajeddeloh> .hello2
16:30:11 <zodbot> ajeddeloh: ajeddeloh 'Andrew Jeddeloh' <andrew.jeddeloh@redhat.com>
16:30:16 <bgilbert> .hello2
16:30:17 <rfairley> .hello rfairleyredhat
16:30:17 <zodbot> bgilbert: bgilbert 'Benjamin Gilbert' <bgilbert@backtick.net>
16:30:20 <zodbot> rfairley: rfairleyredhat 'Robert Fairley' <rfairley@redhat.com>
16:30:20 <dustymabe> .hello2
16:30:22 <slowrie> .hello2
16:30:23 <mnguyen_> .hello mnguyen
16:30:23 <zodbot> dustymabe: dustymabe 'Dusty Mabe' <dusty@dustymabe.com>
16:30:25 <zodbot> slowrie: slowrie 'Stephen Lowrie' <slowrie@redhat.com>
16:30:28 <zodbot> mnguyen_: mnguyen 'Michael Nguyen' <mnguyen@redhat.com>
16:31:11 <ksinny> .hello sinnykumari
16:31:12 <zodbot> ksinny: sinnykumari 'Sinny Kumari' <ksinny@gmail.com>
16:31:25 <bgilbert> #chair ajeddeloh rfairley dustymabe slowrie mnguyen_ ksinny
16:31:25 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe ksinny mnguyen_ rfairley slowrie
16:34:01 <bgilbert> #topic Action items from last meeting
16:34:06 <bgilbert> - dustymabe to add questions on the ticket
16:34:14 <bgilbert> I believe that was https://github.com/coreos/fedora-coreos-tracker/issues/81
16:34:25 <jbrooks> .fas jasonbrooks
16:34:26 <zodbot> jbrooks: jasonbrooks 'Jason Brooks' <jbrooks@redhat.com>
16:34:32 <bgilbert> #chair jbrooks
16:34:32 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks ksinny mnguyen_ rfairley slowrie
16:34:50 <dustymabe> bgilbert: yeah I think that was the ticket.. /me adds note to add ticket number to action items :)
16:34:58 <bgilbert> dustymabe: does https://github.com/coreos/fedora-coreos-tracker/issues/81#issuecomment-442505102 cover it?
16:35:06 <dustymabe> #info dustymabe added questions about versioning/patch release to #81
16:35:23 <kaeso> .hello lucab
16:35:24 <zodbot> kaeso: lucab 'Luca Bruno' <lucab@redhat.com>
16:35:28 <bgilbert> cool
16:35:31 <bgilbert> #chair kaeso
16:35:31 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks kaeso ksinny mnguyen_ rfairley slowrie
16:35:37 <bgilbert> #topic Throttled update rollouts
16:35:44 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/83
16:36:06 <jligon> .hello2
16:36:07 <zodbot> jligon: jligon 'Jeff Ligon' <jligon@redhat.com>
16:36:15 <bgilbert> #chair jligon
16:36:15 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks jligon kaeso ksinny mnguyen_ rfairley slowrie
16:36:18 <dustymabe> welcome jligon :)
16:36:27 <jligon> o/
16:36:32 <sayan> .hello sayanchowdhury
16:36:33 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
16:36:42 <dustymabe> so for this one I just added some comments to the ticket.. thanks bgilbert for the really nice description
16:36:48 <bgilbert> #chair sayan
16:36:48 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks jligon kaeso ksinny mnguyen_ rfairley sayan slowrie
16:36:53 <dustymabe> the context for CL was not something I had before
16:37:01 <miabbott> .hello miabbott
16:37:02 <zodbot> miabbott: miabbott 'Micah Abbott' <miabbott@redhat.com>
16:37:02 <kaeso> (Berlin office is having both power and internet hiccups, I may suddenly disappear)
16:37:15 <bgilbert> ...perhaps I should have batched the chairs
16:37:18 <bgilbert> #chair miabbott
16:37:18 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks jligon kaeso ksinny miabbott mnguyen_ rfairley sayan slowrie
16:37:30 <jligon> kaeso perfectly balanced
16:37:59 <bgilbert> I have a ticket about release metadata mostly written up.  it should provide a starting point for where the graph builder gets its info
16:38:15 <kaeso> bgilbert: that's great
16:38:21 <dustymabe> bgilbert++
16:38:23 <zodbot> dustymabe: Karma for bgilbert changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:38:28 <kaeso> bgilbert: does it include content signing too?
16:38:47 <bgilbert> not really
16:38:50 <dustymabe> kaeso: define content signing ? i.e. integrity of the metadata itself?
16:38:56 <dustymabe> or integrity of any artifacts ?
16:39:16 <bgilbert> there's a mention of possibly signing the release metadata and possibly including content hashes of artifacts
16:39:39 <kaeso> dustymabe: both (as two separate topics though)
16:39:47 <bgilbert> kaeso: what about it?
16:40:15 <bgilbert> managing the signing process etc?
16:40:46 <kaeso> bgilbert: I think that topic is completely missing in current cincinnati design/implementation AND our flow is likely to end up looking different from openshift one
16:42:37 <bgilbert> dustymabe and anyone else who might know: how reasonable is the usual Fedora signing process?
16:42:52 <bgilbert> CL has a signing server now
16:42:54 <bgilbert> #link https://github.com/coreos/fero
16:43:14 <dustymabe> bgilbert: I have a high level knowledge of it
16:43:30 <bgilbert> which requires multiple people to personally sign an artifact, and then they can exchange those sigs for a sig by an official key
16:43:42 <bgilbert> s/multiple/multiple authorized/
16:43:57 <dustymabe> more or less trusted requests from trusted infrastructure come in to a signing server (running robosignatory software) and it signs them
16:44:12 <bgilbert> in CL, that's only for the update payload.  the install artifacts are signed by a different, online, key, which is not ideal
16:44:15 <dustymabe> #link https://pagure.io/robosignatory
16:44:47 <dustymabe> bgilbert: for those interested in the details I think we should set up some time to talk with patrick/kevin
16:44:52 <dustymabe> would you like me to try to set that up?
16:45:05 <bgilbert> dustymabe: sure.  we should probably have a ticket as well
16:45:07 <dustymabe> might be worth a ticket too
16:45:08 <ajeddeloh> +1, I would be interested too
16:45:17 <dustymabe> bgilbert: i'll write one up
16:45:28 <bgilbert> #action dustymabe to set up conversation with Patrick and Kevin about release signing
16:45:39 <bgilbert> #action dustymabe to write up a ticket on release signing
16:46:02 <ksinny> I am interested in knowing details too
16:46:02 <bgilbert> kaeso: thanks for pointing that out
16:46:04 <dustymabe> +1
16:46:51 <bgilbert> as for throttled update rollouts, there are a lot of open questions in the ticket
16:46:59 <bgilbert> I expect they'll take a while to answer
16:47:05 <bgilbert> anything else we want to cover here for now?
16:47:41 <x3mboy> Hi!
16:48:08 <x3mboy> As some of you guys know me, I'm Eduard Lucena, from Marketing
16:48:18 * ajeddeloh waves
16:48:43 <x3mboy> I would like go know if there is something you would like help to promote or publicize about Fedora Core OS
16:49:02 <x3mboy> s/go/to/g
16:49:14 <slowrie> Do we have an idea of when we'll have an implementation of Cincinnati we can play around with?
16:49:17 <bgilbert> x3mboy: that'd be a good question for open floor, later in the meeting
16:49:40 <bgilbert> slowrie: https://github.com/openshift/cincinnati exists
16:49:55 <bgilbert> I believe kaeso has played with it?
16:50:22 <slowrie> +1
16:50:38 <x3mboy> Ooopps. Sorry, I though you were on open floor
16:51:13 <bgilbert> x3mboy: :-)
16:52:04 <bgilbert> okay, moving on in 30 seconds unless someone has something else
16:52:08 <jlebon> .hello2
16:52:09 <zodbot> jlebon: jlebon 'None' <jonathan@jlebon.com>
16:52:13 <bgilbert> #chair jlebon
16:52:13 <zodbot> Current chairs: ajeddeloh bgilbert dustymabe jbrooks jlebon jligon kaeso ksinny miabbott mnguyen_ rfairley sayan slowrie
16:52:47 <bgilbert> #topic Collect metrics from Fedora CoreOS machines
16:52:55 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/86
16:53:41 <bgilbert> so the idea here: metrics are controversial but it's hard to direct development effort without knowing what users care about.
16:53:46 <dustymabe> for this one I think we need to be careful how we approach this. we need to be very vocal about this so users so we have the necessary transparency
16:53:51 <bgilbert> dustymabe++
16:54:21 <dustymabe> but I agree. this is something that will make us way better at predicting users needs and creating the best OS they could want
16:54:35 <bgilbert> e.g., which platforms, which container runtimes, potentially which features.
16:54:49 <dustymabe> too many times in the AH+CL integration process we've all had to "speculate" on what our users are doing
16:54:54 <bgilbert> in CL we have some metrics tied to the update system.  if users don't run updates, or do it via a private server, we don't know they exist.
16:54:57 <jlebon> has there ever been controversy about this in CL?
16:55:22 <bgilbert> jlebon: not afaik, but because of ^, metrics are a bit less explicit
16:55:26 <ajeddeloh> I haven't seen any, but CL collected very minimal metrics
16:55:29 <jlebon> right, gotcha
16:55:30 <bgilbert> also that
16:55:35 <slowrie> One additional feature style metric that might be nice to track is if a user has layered a package in the ostree
16:55:43 <slowrie> Not what, just that it's been used
16:56:02 <bgilbert> slowrie: good point.  want to add a comment to the ticket?
16:56:06 <ajeddeloh> with CL you didn't really have a choice if you wanted updates
16:56:07 <slowrie> and with full we could track what package was layered and if a significant number of users are layering the same package it might be worthwhile adding to the base
16:56:19 <bgilbert> slowrie: yeah
16:56:24 <dustymabe> slowrie++
16:56:24 <zodbot> dustymabe: Karma for slowrie changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:56:25 <jlebon> slowrie: that's a cool idea
16:56:31 <jlebon> slowrie++
16:56:31 <zodbot> jlebon: Karma for slowrie changed to 2 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:56:37 <dustymabe> slowrie: that would be great info to have for when "upgrades fail"
16:57:01 <dustymabe> i.e. 100% of failed upgrades had a layered package and 0% of successful upgrades had layered packages
16:57:19 <dustymabe> would be a pretty telling piece of information
16:57:37 <miabbott> slowrie++
16:57:37 <zodbot> miabbott: Karma for slowrie changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:57:54 <bgilbert> so since CL's tying of metrics to updates hasn't been great, this proposal is for a separate metrics system
16:58:04 <mnguyen_> slowrie++
16:58:14 <jlebon> kinda unrelated, but we need to seriously think about package layering + automated updates given the split versioning issue (https://github.com/projectatomic/rpm-ostree/issues/415)
16:58:32 <bgilbert> enabled by default with a moderate set of data, with a knob to turn collection up or down/off
17:00:10 <slowrie> As dustymabe mentioned I think it's fine to default to moderate and just make sure we call out in docs very explicitly and how to adjust it
17:01:00 <ajeddeloh> yup
17:01:14 <jlebon> SGTM
17:02:13 <bgilbert> anything else here, or shall we move on?
17:02:30 <bgilbert> side note, I dropped the meeting label from the OS versioning ticket, but can re-add if anyone wants to discuss
17:03:38 <dustymabe> might be worth discussing the versioning one
17:04:11 <bgilbert> #topic Version numbering for OS releases
17:04:16 <bgilbert> #link https://github.com/coreos/fedora-coreos-tracker/issues/81
17:04:53 <dustymabe> so picking up from the ticket
17:05:14 <dustymabe> can we define what a "snapshot" is
17:05:48 <dustymabe> in the contrived example where we build on monday and then rebuild on tuesday (let's say for stable stream)
17:06:10 <dustymabe> I don't anticipate changing any packages in the stable stream but maybe one for a fix
17:06:45 <dustymabe> but I think that is true in general, even if we don't need a backport/patch fix
17:06:53 <slowrie> In CL a snapshot is any build that was created with intention of a release, initially <version>.0, then every change that uses that base just increments the patch number
17:07:04 <bgilbert> dustymabe: snapshot in the sense of https://github.com/coreos/fedora-coreos-tracker/blob/master/Design.md#release-streams
17:07:28 <slowrie> Worth noting these snapshots are not always actually released if there were issues encountered during the release process
17:07:34 <bgilbert> there's a new one only every two weeks
17:07:57 <bgilbert> slowrie: that's not the way I was thinking of it
17:08:11 <dustymabe> right. so snapshot is basically the time at which we freeze on the package set
17:08:13 <bgilbert> slowrie: the CL equivalent would be a new alpha branched from master
17:08:17 <bgilbert> dustymabe: right
17:08:38 <bgilbert> slowrie: but in FCOS "master" is actually Fedora + updates, so it'll change without our intervention
17:09:45 <bgilbert> if the term is confusing we can pick a different one
17:09:56 <dustymabe> bgilbert: i think that seems reasonable. so in this case the YYYYMMDD would indicate the date we froze on the package set vs the day the build happened
17:09:58 <slowrie> I'm not sure I understand how that differs but the base idea of it makes sense to me
17:10:04 <dustymabe> I was thinking of it the other way
17:10:42 <bgilbert> slowrie: branched alpha and beta/stable releases are not snapshots, they're releases on an existing branch
17:10:54 <bgilbert> I guess "branch point" would be the CL equivalent, then
17:11:31 <bgilbert> FWIW I still don't like datestamps, but it appears I may be in the minority :-)
17:11:38 <dustymabe> :)
17:11:56 <dustymabe> slight tangent: so today in fedora our rpm repos are generated out of pungi composes
17:12:15 <dustymabe> and the pungi composes have IDs like: YYYYMMDD.CNTR
17:12:24 <bgilbert> hmm
17:12:37 <dustymabe> if we snapshot on a package set it could be useful to have that number translate over
17:12:37 <bgilbert> not a bad thought
17:12:55 <bgilbert> yeah
17:13:21 <dustymabe> but the relationship won't be direct
17:13:37 <bgilbert> at a minimum the compose ID should be in the release metadata; I'll add that to the writeup
17:13:42 <dustymabe> because we are discussing using our own koji tags etc.. but I think the idea is that we inherit most of the package set from the normal set of tags
17:14:01 <dustymabe> so the "loose relationship" could be interesting
17:14:40 <dustymabe> in general. I think your proposal where YYYYMMDD represents the date we froze on the package set is interesting
17:14:43 <dustymabe> and sane
17:14:55 <jlebon> i like a way of easily telling how old a version is. how that's expressed is flexible I guess.
17:15:01 <dustymabe> YYYYMMDD to represent the "build date: is also sane
17:15:13 <bgilbert> the idea is that the build date doesn't actually represent the age of the contents
17:15:25 <dustymabe> so maybe we just decide to go with one and then re-visit if we hit roadblocks or get new information
17:15:37 <jlebon> the YYMMDD compromise is kinda nice to make it less verbose
17:15:48 <dustymabe> jlebon: you mean YYMM.CNTR ?
17:15:57 <jlebon> ahh, right
17:16:07 <jlebon> i meant the YY part in general
17:16:19 <dustymabe> yeah that one gets us less digits, but if we want to represent the date we froze on a package set then I don't think we can do that one
17:16:22 <bgilbert> jlebon: +1
17:16:24 <jlebon> probably we can revisit the numbering system in 2100 if we're still around
17:16:30 <slowrie> Could also use yyMMDD
17:16:45 <bgilbert> there doesn't seem to be any controversy over using the Fedora version as the major version, which means we can safely revisit this once per Fedora release
17:16:53 <dustymabe> :)
17:17:02 <ajeddeloh> slowrie: ?
17:17:12 <dustymabe> ok so I had a revelation during this conversation (re: date being the date we froze on a package set)
17:17:17 <ajeddeloh> my keyboard doesn't have lower case numbers?
17:17:17 <dustymabe> I'll add that info to the ticket
17:17:17 <slowrie> ajeddeloh: year without century
17:17:35 <ajeddeloh> oh, thought you were emphasizing something about yy vs YY
17:17:55 <slowrie> old habit from datetime formatting where %y is year without century
17:18:31 <bgilbert> dustymabe: maybe we don't need to be tied to the compose ID
17:18:53 <bgilbert> we should absolutely have it in metadata, but Pungi IDs seem sufficiently obscure that maybe we don't need direct compatibility with them
17:19:19 <jlebon> yeah, i think i agree with that
17:20:41 <jlebon> not to mention it's not completely decided yet how our package set will be assembled, or even that might change in the future
17:20:55 <bgilbert> jlebon: right
17:21:00 <bgilbert> ajeddeloh: actually if we use upper-case numbers I withdraw my objection to date stamps :-)
17:21:03 <dustymabe> right. i think we don't have to decide everything now
17:21:06 <slowrie> time check, only 10 minutes left
17:21:12 <bgilbert> ajeddeloh: FCOS 30.@)!()^)!.0
17:21:12 <dustymabe> a lot of details will shake out in practice
17:21:28 <ksinny> Pungi ID is to get Fedora repo used to build FCOS?
17:21:28 <dustymabe> thanks slowrie for the time check
17:21:39 <bgilbert> ksinny: right
17:21:40 <jlebon> bgilbert: well, that's definitely supported by ostree
17:21:45 <jlebon> could have emojis too
17:22:33 <bgilbert> okay, moving on in 30s
17:22:48 <ksinny> bgilbert: ok, if we have this information in metadata then it should be ok
17:23:16 <bgilbert> #topic Open Floor
17:23:30 <bgilbert> ^ x3mboy_
17:24:17 <dustymabe> #info we've been in heavy development on the fedora-coreos-pipeline (new repo recently moved under the coreos github org)
17:24:37 <dustymabe> #link https://github.com/coreos/fedora-coreos-pipeline
17:24:47 <dustymabe> thanks jlebon rfairley ksinny for the work there
17:24:53 <bgilbert> +1
17:25:14 <jbrooks> awesome
17:25:15 <rfairley> dustymabe++
17:25:15 <zodbot> rfairley: Karma for dustymabe changed to 8 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:25:20 <jlebon> yeah, i'm quite happy with how that's going so far!
17:25:39 <jlebon> the emphasis is on making it easy to test locally
17:25:57 <rfairley> +1
17:26:05 <ksinny> dustymabe++
17:26:07 <ksinny> jlebon++
17:26:07 <bgilbert> looks like x3mboy_ is idle, but we can answer his question for the logs
17:26:08 <rfairley> works well on Fedora 28 right now?
17:26:22 <ksinny> rfairley++
17:26:22 <zodbot> ksinny: Karma for rfairley changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
17:26:24 <jlebon> yup, definitely
17:26:34 <dustymabe> once we get that in a good state we can start working with fedora releng/infra to figure out details of getting integrated with fedora
17:26:36 <rfairley> soon will update the docs with it working on F29 :)
17:27:00 <jlebon> dustymabe: yeah, that works
17:27:12 <bgilbert> I don't think we're ready to promote FCOS yet.  dustymabe or anyone else, opinions?
17:27:16 <dustymabe> for posterity
17:27:24 <dustymabe> 11:48:43      x3mboy | I would like go know if there is something you would like help to promote or publicize about Fedora Core OS
17:27:31 <ajeddeloh> yeah I'd agree with that
17:27:41 <ksinny> same here
17:27:56 <leoluk> what's the future for atomic CLI and system containers?
17:28:00 <dustymabe> yeah I think coordination with marketing isn't something we can handle just yet, but sanja might be a good person to talk to x3mboy, she might have some good ideas or want to help develop a strategy
17:28:07 <leoluk> I discussed this with lorbus yesterday and he suggested I bring it up in the meeting
17:28:10 <ksinny> although we need more contributors at the meomnet :)
17:28:16 * dustymabe waves at leoluk
17:28:52 <leoluk> (I'm new here, Open Floor sounded like the appropriate time to bring it up :P)
17:29:12 <dustymabe> leoluk: I think we've been thinking we'd like to go with something like portable systemd services in the future
17:29:16 <leoluk> https://github.com/coreos/fedora-coreos-tracker/issues/37
17:29:17 <dustymabe> discussion here https://github.com/coreos/fedora-coreos-tracker/issues/37
17:29:21 <jlebon> leoluk: we're not planning on shipping atomic in FCOS for the time being
17:29:22 <jbrooks> I'm curious, too, about kube/okd on FCOS, built-in / layered / containered etc
17:29:29 <bgilbert> leoluk: there's also some discussion in https://github.com/coreos/fedora-coreos-tracker/issues/37
17:29:34 <bgilbert> ah, yeah :-)
17:29:59 <dustymabe> jbrooks: that is probably worth a ticket if there isn't one specifically for it
17:30:15 <dustymabe> my thoughts are that it would be "like docker" where we bake it in but allow pinning other versions
17:30:44 <leoluk> okd uses static kubelet pods at the moment, but it's far from perfect IMO (logs being harder to access, special tools necessary to restart - it would be much nicer to handle them as systemd services)
17:31:00 <jlebon> yeah, we should figure that stuff out soon-ish given that one of our primary goals is being the best platform for kubernetes :)
17:31:06 <jbrooks> :)
17:31:06 <dustymabe> jbrooks: do you want to create a ticket for that?
17:31:14 <jbrooks> dustymabe, Yes, I can do that
17:31:43 <dustymabe> bgilbert: has the #action gavel
17:32:11 <dustymabe> jlebon: we should probably also figure out pretty soon if we need "modularity" support in rpm-ostree
17:32:39 <dustymabe> I had been thinking we would select different versions of packages using versions from modules, but rpm-ostree needs to support modularity in order for that to work
17:33:09 <jlebon> dustymabe: yeah agreed. could probably talk about this in https://github.com/coreos/fedora-coreos-tracker/issues/77
17:33:35 <dustymabe> jlebon: hmm. I think we need a different ticket
17:33:37 <leoluk> is the modularity use case (different runtimes) relevant for FCOS? I would assume that people would use modularity inside the containers running on FCOS
17:33:39 <bgilbert> #action jbrooks to create a ticket for deciding on the mechanism for shipping kube/okd pieces
17:33:53 <dustymabe> because this is talking about "layered software" vs the base package set
17:33:56 <dustymabe> but maybe not ??
17:34:04 <jlebon> dustymabe: the rationale being that we might use modularity for the base too
17:34:20 <dustymabe> yeah. i think it deserves it's own discussion though
17:34:29 <jlebon> yup, sure
17:34:35 <dustymabe> discussions get confusing quick if we mix ideas
17:34:54 <bgilbert> #action jlebon to file a ticket to decide whether we need modularity support in rpm-ostree
17:35:20 <bgilbert> jlebon: oh, I guess it was ambiguous whether you volunteered for that :-)
17:35:27 <jlebon> heh, that's fine :)
17:35:39 <dustymabe> :) - bgilbert is an excellent meeting moderator
17:36:10 <bgilbert> dustymabe: not gonna #info that, huh :-)
17:36:17 * jlebon has to grab food -- see y'all later!
17:36:43 <bgilbert> yeah, we're over time.  closing meeting in 60s if no one else has anything
17:38:07 <bgilbert> #endmeeting