17:30:01 <nirik> #startmeeting FESCO (2011-02-23)
17:30:01 <zodbot> Meeting started Wed Feb 23 17:30:01 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:01 <nirik> #meetingname fesco
17:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:01 <nirik> #topic init process
17:30:01 <zodbot> The meeting name has been set to 'fesco'
17:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:30:05 <mjg59> Hi
17:30:45 <nirik> morning everyone.
17:31:16 <sochotni> damn timezones :-)
17:32:30 <SMParrish_mobile> here but mobile so will be in and out
17:32:30 * nirik waits a bit more for quorum.
17:33:02 * notting is here
17:33:07 * mmaslano too
17:33:47 <nirik> well, thats 5 I guess...
17:34:05 <mjg59> kylem is here
17:34:10 <kylem> shh.
17:34:22 <nirik> ok, 6. ;)
17:34:39 <nirik> #info mclasen unable to attend today.
17:35:08 <nirik> #info present mjg59 kylem notting nirik SMParrish_mobile mmaslano
17:35:17 <nirik> #topic #516 Updates policy adjustments/changes
17:35:17 <nirik> .fesco 516
17:35:22 <zodbot> nirik: #516 (Updates policy adjustments/changes) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/516
17:35:26 <nirik> ok, I didn't remember to add anything here this week. ;(
17:35:31 <nirik> will try not to slack next week.
17:35:37 <mmaslano> I have something ;-)
17:35:46 <nirik> mmaslano: go ahead. ;)
17:36:01 <mmaslano> people were asking about 3 days in testing before automatical push in alpha
17:36:07 <mmaslano> but that wasn't implemented yet
17:36:18 <mmaslano> shouldn't we change guidelines after they are implemented?
17:36:19 <nirik> yeah, it's not been done in bodhi. ;(
17:36:39 <mmaslano> we should add comment to these, which are not working
17:36:47 <nirik> yeah, agreed.
17:37:00 <nirik> would someone be willing to add a note to the updates page about this?
17:37:13 <mmaslano> I can do it if I have permission to edit it
17:37:50 <nirik> yeah, it should be open.
17:37:57 <nirik> thanks mmaslano!
17:38:17 <nirik> #action mmaslano to update wiki for the 3days in testing vs 7 days in testing for branched releases.
17:38:32 <nirik> any other general updates comments/discussion?
17:39:17 <nirik> morning ajax.
17:39:22 <nirik> ok, moving along then...
17:39:33 <nirik> #topic #515 Investigate a "features" repo for stable releases
17:39:33 <nirik> .fesco 515
17:39:34 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515
17:39:49 <ajax> sorry for the late join
17:39:52 <nirik> cwickert was going to work on this. I guess we move along until we have a more concrete proposal.
17:39:59 <nirik> no problem
17:40:43 <nirik> ok, moving on unless someone has something on this...
17:40:53 <nirik> #topic #517 Updates Metrics
17:40:53 <nirik> .fesco 517
17:40:54 <zodbot> nirik: #517 (Updates Metrics) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/517
17:41:01 <nirik> kylem: any chance to poke at this over the last week?
17:41:33 <kylem> not yet, sorry, i've been on pto this week.
17:42:06 <nirik> ok, no problem. Anyone have any general thoughts on this before we move on?
17:42:35 <nirik> #topic #544 List of services that may start by default
17:42:35 <nirik> .fesco 544
17:42:36 <zodbot> nirik: #544 (List of services that may start by default) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/544
17:42:56 <nirik> ok, FPC voted and decided to push this to fesco. So, we are on the hook for the list and policy.
17:43:09 <kylem> oh super
17:43:18 <nirik> https://fedoraproject.org/wiki/User:Kevin/DefaultServices
17:43:37 <nirik> is the one I had from our last discussions. Basically spot's proposed guidelines and our list of exceptions.
17:43:47 <mjg59> Do we have the explicit statement from fpc?
17:43:56 <nirik> there were some concerns about us allowing local things that could have a security impact I think.
17:44:14 <mjg59> If FPC are concerned about it then FPC can take responsibility
17:44:19 <mjg59> Otherwise they get to trust our judgement
17:44:27 <nirik> https://fedorahosted.org/fpc/ticket/60
17:44:44 <nirik> "FESCo is responsible for defining an approved list of services which may autostart, and/or defining criteria to determine when and if a service may autostart."
17:45:09 <notting> oooookay then.
17:45:19 <kylem> well, that's... vagueish. :)
17:45:29 <mjg59> Works for me
17:45:30 <notting> proposal: nirik's draft, with s/FPC/FESCo/?
17:45:33 <nirik> I'll note that NetworkManager wasn't on the list we had... I guess it's dbus activated now?
17:46:05 <mjg59> I'd like to talk about what "network enabled" means
17:46:07 <notting> dbus services weren't in the list of services that 'started by default'... we can certainly investigate them
17:46:28 <mjg59> If a package can work without explicit configuration, and only binds to localhost, is that permitted or not?
17:46:59 <nirik> good question.
17:47:22 <notting> imo, yes.
17:47:33 <mjg59> I'd argue that it is, on the basis that in that case it's effectively equivalent to a daemon that has a unix socket for communication
17:47:38 <nirik> on one hand it could be usefull to people (sendmail, httpd), but on the other it means there is more security exposure from local users perhaps.
17:48:00 <mjg59> nirik: Running daemons typically have some kind of mechanism for user interaction
17:48:17 <kylem> well, ideally, even most localhost only services will drop privs after binding to their socket or whatever they need to do.
17:49:09 <nirik> sure.
17:49:19 <notting> nirik: a http server that only binds to localhost is, while not completely pointless, not useful for the normal case
17:49:32 <nirik> also agreed. ;)
17:49:45 <kylem> besides, the kernel is probably the biggest single source of local privilege escalations.
17:49:48 <kylem> ;-)
17:50:25 <nirik> yeah, we shouldn't allow the kernel to start by default, that would fix that. ;)
17:50:31 <kylem> for reals.
17:50:49 <nirik> anyhow, I could see possible reasons to adjust this, but I think it's an ok first cut.
17:50:55 <kylem> me too, looking it over
17:51:00 <notting> maybe s/network enabled/publically network facing/?
17:51:17 <mjg59> notting: People might start arguing over default firewall rules
17:51:34 <nirik> do we still have a default MTA?
17:51:39 <nirik> or did we finally quash that?
17:52:33 <kylem> i have sendmail on my f14 live install, so i assume so. :)
17:53:13 <nirik> I guess it never got finalized: https://fedoraproject.org/wiki/Features/NoMTA
17:53:31 <kylem> indeed.
17:54:25 <nirik> so, further thoughts, corrections, additions?
17:54:45 * nirik wonders if we shouldn't ask devel list for feedback and finalize next week.
17:55:23 <kylem> feedback eh.. that sounds unpleasant. ;-P
17:55:54 <nirik> could be, but there could be cases we are missing...
17:56:39 <mjg59> Yeah
17:56:41 <mjg59> Probably for the best
17:57:00 <notting> are we all at least in agreement about the general concept?
17:57:05 <kylem> yeah.
17:57:16 <notting> (b/c there will almost certainly be "TURN EVERYTHING OFF" responses, etc.)
17:57:16 * nirik thinks the general ideas are sane...
17:57:21 <nirik> yeah.
17:57:45 <mjg59> Yes
17:58:00 <mmaslano> yes
17:58:07 <nirik> ok, I can mail the list and try and gather/summarize feedback and we can revisit next week?
17:58:29 <mmaslano> sounds good
17:58:33 <kylem> perhaps you should use a smurf email account. ;-P
17:58:47 <nirik> :)
17:59:04 <nirik> #action nirik will ask for feedback on the proposed policy on devel list, will gather info and revisit next week.
17:59:27 <kylem> cool, ty
17:59:28 <nirik> ok, anything else here? moving on in a few...
17:59:54 <nirik> #topic #563 suggested policy: all daemons must set RELRO and PIE flags
17:59:55 <nirik> .fesco 563
17:59:56 <zodbot> nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563
18:00:38 <nirik> I guess 'daemons' here means anything that listens on the network?
18:01:02 <nirik> normally we discourage changing compile flags...
18:01:24 <mmaslano> not only on network
18:01:26 <notting> it's not really defined well in the proposal
18:01:36 <mmaslano> also services like cron
18:01:57 <notting> none of the listed examples are network services (except non-default rsyslog configs)
18:02:07 <nirik> so the guidelines say: "Compilers used to build packages should honor the applicable compiler flags set in the system rpm configuration. As of Aug 2006, this means in practice $RPM_OPT_FLAGS/%{optflags} for C, C++, and Fortran compilers. Honoring means that the contents of that variable is used as the basis of the flags actually used by the compiler during the package build. Adding to and overriding or filtering parts of these flags is permitted if there'
18:02:07 <nirik> s a good reason to do so; the rationale for doing so should be reviewed and documented in the specfile especially in the override and filter cases."
18:02:09 <kylem> i think this is one of those situations where we can drive upstream improvements.
18:02:21 <mjg59> So what are the costs?
18:02:26 <notting> but there also are a whole host of daemons that i'm sure aren't RELRO/PIE that aren't listed
18:02:32 <mjg59> pie can be a performance hit
18:02:38 <mjg59> What about relro?
18:02:54 <notting> e-d-s, pulseaudio, libvirtd, etc.
18:03:04 <nirik> PIE has startup time costs.
18:03:38 <notting> if it's only on startup, then the question is how much
18:03:45 <notting> 0.1 sec? less?
18:04:22 * nirik has no idea.
18:04:37 <kylem> i'm sure it's negligible.
18:04:41 <ajax> incredibly small
18:04:53 <mjg59> My question here is really "Why are these not default"
18:05:00 <nirik> are there enough advantages to consider changing them to be default?
18:05:01 <mjg59> If there's a win for daemons, why not anything else?
18:05:04 <ajax> i started building xserver PIE and the startup time difference was down in the millisecond range
18:05:06 <nirik> jinx.
18:05:49 <notting> mjg59: startup costs for a daemon that lasts the system lifetime is negligble. startup cost for shells?
18:06:03 <mjg59> notting: Still pretty low
18:06:12 <ajax> -z relro is basically always worth doing though
18:06:12 <daniel_hozac> there's also the attack vector.
18:06:33 <ajax> if for no other reason than it means your linker can actually implement C's 'const' keyword correctly
18:06:34 <kylem> mjg59, agreed.
18:06:44 <nirik> sounds like relro might not be available on all arches? so could be an issue for secondary, but they probibly have their own flags already anyhow.
18:06:49 <mjg59> It sounds more like it should be a win for anything that consumes untrusted data
18:06:51 <kylem> perhaps the gcc folks are just overly conservative.
18:07:14 <ajax> (otherwise, const void *foo = &bar; is emitted in .data, since it requires a relocation and can't be resolved until ld.so time)
18:07:20 <mjg59> So how about we counterpropose that we just enable this globally in the F16 cycle?
18:07:45 <mjg59> And get some toolchain people to look into it?
18:07:48 <kylem> raisonable. given it requires yet another mass rebuild.
18:07:50 * nirik is fine with that, but we might gather info from tools folks about it.
18:08:14 <kylem> indeed, let's ask them why this isn't the default. :)
18:08:22 <ajax> PIE is... debatably worthwhile as a global thing.  it doesn't really win you much besides the ASLR bonus (and the ability to link against executables as though they were DSOs)
18:09:05 <mjg59> The ASLR bonus is pretty much what we're looking at here
18:09:18 <nirik> proposal: suggest making it default in f16, ask for feedback on that and revisit.
18:09:22 <kylem> perhaps we should also investigate what other distros are doing.
18:09:25 <mjg59> Does it make a big difference on 64-bit as well, or is it mostly useful on 32?
18:09:30 <kylem> we don't want a randomization gap.
18:10:22 <mjg59> Strategic Randomisation Reduction Treaty
18:10:25 <nirik> proposal2: someone talks to toolchain folks and gathers info for us and we revisit next week. ;)
18:10:33 <kylem> i'll do that
18:10:47 <kylem> (promise. no backsies, no fingers crossed behind my back. :P)
18:10:50 <notting> kylem: need to send patch for -zmineshaft option?
18:10:57 <nirik> kylem: cool!
18:11:09 <kylem> notting, NO FIGHTING IN THE WAR ROOM
18:11:18 <nirik> #action kylem will talk with toolchain folks about this, see if making it default in f16 makes sense and what the tradeoffs are.
18:11:27 <nirik> ok, anything else on this?
18:11:34 <mjg59> Don't think so
18:12:08 <nirik> #topic #275 Propose a soft-path via co-maintainer status to becoming sponsored
18:12:08 <nirik> .fesco 275
18:12:09 <zodbot> nirik: #275 (Propose a soft-path via co-maintainer status to becoming sponsored) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/275
18:12:14 <nirik> ok, this is an ooooold ticket. ;)
18:12:28 <nirik> we discussed it long ago, and it kind of stalled.
18:13:02 <nirik> basically we have now a limited way for people to become packagers: submit new packages for review and get sponsored.
18:13:42 <nirik> This ticket is to try and expand that and allow us to add comaintainers of existing packages
18:14:16 <RobbieAB> Well, speaking as an outsider, I can honestly say the chances of that appealing are low. :s
18:14:59 <nirik> the problem is determining if someone has the skills/ability to maintain packages, and how to determine that.
18:15:01 <kylem> tbh i don't think lowering the bar is a useful thing. we need more people reviewing, not more packages for them to review.
18:15:15 <RobbieAB> I'm more likely to sign up to help with a package I like and care about than try and join with a new one.
18:15:38 <nirik> RobbieAB: right, so the proposed policy here would be appealing to you.
18:15:49 <nirik> kylem: this would not add more packages to review.
18:16:02 <nirik> let me throw up some cases that have hit recently:
18:16:14 <RobbieAB> nirik: Yes. :) I just meant the "current official" policy.
18:16:38 <nirik> upstream maintainer of a project wants to help maintain the fedora package. The fedora maintainer would love to have the help and knows that they know packaging and the package quite well.
18:17:04 <nirik> Currently they would have to submit a review of a package they didn't care about or have time to maintain, get that though the process then add as co-maintainer of the one they care about.
18:18:03 <nirik> another case is: some packages are poorly or not at all maintained. Someone interested in them submits patches to fix them, wants to maintain them moving forward...
18:18:12 <nirik> but they have to submit a review of a package they didn't care about or have time to maintain, get that though the process then add as co-maintainer of the one they care about.
18:18:34 <kylem> sorry, internet hiccup
18:18:58 <ajax> if the existing maintainer trusts a new person to be a co-maintainer, why would we disagree?
18:19:10 <nirik> One of the downsides to the proposed policy change in comment10 is that someone could get in with that policy, not know much or be evil, and get added as a comaintainer on another package where the maintainer didn't know they were new/didn't know/were evil.
18:19:40 <nirik> I think that risk is pretty low, as currently someone could get in as a maintainer of a small/easy/useless package and do the same thing.
18:20:01 <kylem> well, ideally, there's still the bar to provenpackager.
18:20:01 <nirik> so, all that said, I am +1 for abadger1999's proposal in https://fedorahosted.org/fesco/ticket/275#comment:10
18:20:02 <ajax> also, the bodhi process should limit the amount of damage you could do with that in any case
18:20:51 <nirik> I think having fesco folks know/sponsor should give us an idea of how popular this is or what pitfalls might happen due to it.
18:21:36 <ajax> yeah, +1
18:21:43 <nirik> so, votes? counter opinions?
18:22:00 <mmaslano> sounds good +1
18:22:04 <notting> i'm +1 to the proposal. can't imagine too many cases where we'd say no
18:22:24 <kylem> +1.
18:22:33 * nirik notes thats +5.
18:23:00 <nirik> #agreed proposal from https://fedorahosted.org/fesco/ticket/275#comment:10 accepted. will work to update docs and announce.
18:23:09 <abadger1999> Note -- the idea is not that fesco would have to strictly review people asking to be sponsored this way, just that there needs to be  a way to connect package owners willing to mentor someone with someone who can sponsor.
18:23:38 <nirik> abadger1999: yeah, I can't see us not doing it, but it allows us to see how popular this will be and watch the people who are added this way..
18:23:45 <abadger1999> and fesco seemed to fit the latter/has a ticketing system/etc.
18:23:52 <abadger1999> <nod>
18:24:05 <nirik> so, what do we need to do to make this live? just update wiki pages and announce?
18:24:10 <abadger1999> yep.
18:24:16 <nirik> we also need to change the package maintainer responsibilities pages right?
18:24:19 <abadger1999> I'll update the wiki pages now if you guys will announce.
18:24:34 <abadger1999> You could review that page
18:24:46 <nirik> ok. Cool.
18:24:56 <abadger1999> I thought the previous changes encompassed this but I haven't looked recently.
18:25:08 <nirik> let me know when all is done and I can announce...
18:25:11 <abadger1999> k
18:25:18 <nirik> thanks abadger1999!
18:25:26 <abadger1999> No problem
18:25:27 <nirik> #action abadger1999 to update wiki pages.
18:25:33 <nirik> #action nirik to announce new policy
18:25:39 <nirik> RobbieAB: you still around?
18:25:43 <RobbieAB> I am.
18:25:59 <nirik> #topic Fedora Engineering Services
18:26:12 <nirik> So, FES kind of became idle there for a while...
18:26:25 <nirik> mmgrath was driving it, and he moved on to other things...
18:26:39 <nirik> however, RobbieAB has stepped up to help move things forward again. :)
18:26:46 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
18:27:05 <nirik> RobbieAB: so, any news from things over the last week? do we need more tickets or more engineers?
18:27:36 <RobbieAB> At the moment, I am slowly prodding people and trying to get things moving again.
18:27:39 <kylem> RobbieAB, care to introduce yourself to the class? :)
18:27:50 * abadger1999 has seen that thom has been active on the C bundled library tracker :-)
18:29:41 <RobbieAB> Hi, I;m Robert, currently in Dublin, and in a moment of madness I let nirik and mmcgrath talk me into trying to run FES#
18:30:12 <kylem> cool, nice to meet you
18:30:29 <nirik> I think we could look at setting up 'fix rawhide broken deps' and 'fix f15 broken deps' tickets at some point...
18:30:33 <RobbieAB> I ran a quick role call and got 7 or 8 responses. Thom was one of them and I asked him to poke that C bundled library tracker.
18:30:47 <nirik> if other fesco folks have small nice engineering tasks, please do file them.
18:31:34 <RobbieAB> Is "fix rawhide broken deps" actually within the guidelines for FES? It strikes me as a ticket that will grow as much as it shrinks.
18:31:54 <RobbieAB> (A point that occured to me when thinking about it today)
18:31:58 <abadger1999> It is -- but some tickets will shrink and grow.
18:32:08 <nirik> There was also some movement on the cross desktop help/support links stuff... (talks with docs and websites)
18:32:21 <nirik> yeah, some will just grow/shrink over time.
18:32:34 <nirik> I would hope a f15 broken deps fixing would shrink to 0 before release. ;)
18:33:03 <RobbieAB> Well, F15 broken deps has a clear end point.
18:33:18 <nirik> yeah, rawhide keeps on rollin.
18:33:34 <abadger1999> bundled libraries will also shrink and grow over time, although with a slower rate of  change than broken deps :-)
18:33:57 <RobbieAB> nirik: Which is why I am wondering if rawhide fits within "FES specalizes on specific tasks with a beginning, middle and end"
18:34:40 <nirik> RobbieAB: yeah, although each particular broken package has a beginning,middle,end part to fixing it... so the parts of the task go away as they are fixed.
18:34:59 <nirik> in any case, rawhide isn't as important as f15...
18:35:19 <RobbieAB> Yeah, that is the logic I am using. I can set-up an F15 tracker anyway.
18:35:41 <nirik> cool.
18:35:57 <nirik> ok, anyone have anything further to ask RobbieAB or related to FES?
18:36:05 <mmaslano> hm, I thought broken depencies should be solved by maitainers of these packages?
18:36:29 <nirik> mmaslano: sure, normally so... but sometimes if a provenpackager has time and the main maintainer is busy they appreciate the help
18:37:00 <mmaslano> nirik: ok
18:37:15 <RobbieAB> Perhaps it should be set-up so a maintainer can ask for us to look at it?
18:37:44 <abadger1999> RobbieAB: thom has been doing a great job with triage on bundled libs -- he might be able to do with some additional help moving on to the next stage -- helping generate patches to fix packages where the maintainer doesn't have the time to do the coding themselves.
18:37:45 <nirik> RobbieAB: yeah, we could do that... although if they are busy they might not have time to ask...
18:38:15 <nirik> I think a 'ask maintainer and wait for a response for a bit first' might work better for those.
18:39:06 <RobbieAB> Ok, will note that.
18:39:21 <nirik> anyhow, I'd like to thank RobbieAB for taking this on, and am glad to see FES moving along again. :)
18:39:34 <RobbieAB> abadger1999: Possibly, but if that is me, it will be the blind leading the blind. :)
18:39:53 <nirik> if we end up with more engineers than tickets, we might look at opening up things to other groups to file things (the board, sigs, etc)
18:40:03 <abadger1999> <nod>  If someone steps up and says I know C, what can I do? you can throw them in there :-)
18:40:03 <RobbieAB> There was one that Thom raised a question on: lua-sec
18:40:30 <RobbieAB> Which had the original filer of the review request say he was no longer interested in.
18:41:07 <RobbieAB> abadger1999: Thom claims he knows C too... It's why I pointed him at that ticket. :)
18:41:21 <abadger1999> Cool
18:41:40 <nirik> ok, anything else to discuss here? or shall we move on?
18:41:53 <abadger1999> RobbieAB: POint me at the lua-sec thing and I'll look at it after the meeting with you.
18:42:55 <RobbieAB> abadger1999: Will do. :)
18:43:08 <nirik> #topic Open Floor
18:43:16 <nirik> Anyone have anything for open floor?
18:43:33 <mmaslano> yes
18:43:44 <mmaslano> number of broken packages in F-15 ;-)
18:44:29 <mmaslano> could we move next mass-rebuild?
18:44:30 <nirik> yeah, broken deps you mean?
18:44:39 <mmaslano> this one was done too late
18:44:45 <nirik> yeah, the mass rebuild timing was unfortunate here...
18:44:53 <mmaslano> or alpha freeze should be done later
18:45:25 <nirik> I think it was unavoidable due to dgilmore traveling before that...
18:45:32 <mmaslano> I have there a lot of packages, I'm not aware if they are fixed or not, because they are in "testing queue"
18:45:34 <glisse> btw it seems gcc 4.6 + -fno-omit-frame-pointer doesn't play well with mesa
18:45:41 <nirik> but yeah, doing sooner would be better.
18:45:44 <mmaslano> the F-15 branch report doesn't help me at all :-/
18:46:04 <nirik> mmaslano: yeah, doesn't help that we are in alpha freeze right now, so hard to tell how much is still messed up.
18:46:16 <nirik> as soon as that unblocks it should help a lot.
18:47:06 <mmaslano> also there was no message about freeze or I miss it
18:47:09 <nirik> not sure what else we can really do right now. ;( But we can do better next time.
18:47:35 <mmaslano> yes, if we have some how to mass rebuild, it should be there ;-)
18:48:14 <nirik> there was a note about the freeze in the mass rebuild announcement... but yeah, another would be good.
18:48:28 <nirik> https://fedoraproject.org/wiki/Mass_Rebuild_SOP
18:49:02 <nirik> https://fedoraproject.org/wiki/Alpha_Freeze_Policy
18:49:23 <nirik> could you add notes to those?
18:49:56 <mmaslano> ok, I'll edit it, thanks
18:50:23 <nirik> thanks.
18:50:42 <nirik> #action mmaslano to add notes about announcements and scheduling to the mass rebuild sop and freeze policies pages.
18:50:54 <nirik> ok, anything else? or shall we call this a meeting?
18:51:27 * nirik listens to the crickets chirp
18:51:30 <kylem> heh
18:51:38 <nirik> ok, will close out in a minute if nothing else comes up.
18:51:39 <kylem> nothing on my end... just writing up my action item
18:52:08 <nirik> Thanks everyone!
18:52:11 <nirik> #endmeeting