14:00:26 <johnthetubaguy> #startmeeting Nova
14:00:26 <openstack> Meeting started Thu Mar 24 14:00:26 2016 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:29 <bauzas> tic tac
14:00:30 <openstack> The meeting name has been set to 'nova'
14:00:33 <alaski> o/
14:00:35 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Meetings/Nova
14:00:37 <bauzas> \o
14:00:39 <andrearosa> hi
14:00:40 <takashin> o/
14:00:40 <rlrossit> o/
14:00:42 <mriedem> o/
14:00:44 <johnthetubaguy> #topic Release Status
14:00:45 <edleafe> \o
14:00:48 <dansmith> ohai
14:00:51 <johnthetubaguy> hello all
14:01:00 <cdent> o/
14:01:04 <markus_z> o/
14:01:06 <johnthetubaguy> so we have RC2 proposed here: https://review.openstack.org/#/c/297006/1
14:01:09 <tojuvone> hi
14:01:25 <johnthetubaguy> planning RC3 to include translations, and other big things we hit on the way
14:01:42 <johnthetubaguy> #link http://docs.openstack.org/releases/schedules/mitaka.html
14:01:51 <alex_xu> o/
14:01:59 <johnthetubaguy> looking for RC3 week before April 4th I think
14:02:09 <johnthetubaguy> i.e. next week
14:02:11 <bauzas> yeah
14:02:17 <bauzas> sounds reasonable
14:02:21 <johnthetubaguy> #link https://bugs.launchpad.net/nova/+bugs?field.tag=mitaka-rc-potential
14:02:22 <bauzas> we have one bug in the pipe
14:02:26 <johnthetubaguy> trying to catch things in there
14:02:31 <johnthetubaguy> although also the ones that get merged
14:02:49 <mriedem> this is the current rc3 regression fix https://review.openstack.org/#/c/296305/
14:03:05 <johnthetubaguy> #link https://etherpad.openstack.org/p/newton-nova-priorities-tracking
14:03:06 <mriedem> need danpb / jaypipes to review that
14:03:10 <thomasem> o/
14:03:11 <johnthetubaguy> is for newton-ey things
14:03:37 <johnthetubaguy> mriedem: yeah, I should created the new milestone to target that one
14:04:00 <johnthetubaguy> any more release things?
14:04:16 <markus_z> there are 5 new bugs in the last 24 hours which aren't looked at yet
14:04:18 <johnthetubaguy> mriedem is doing a great job approving BPs to kick things going again
14:04:51 <bauzas> markus_z: one of them is, just not triaged :p
14:05:04 <johnthetubaguy> #help if you have a -2 on a patch, ask about getting your blueprint (and spec) approved for Newton, then ping in IRC to get the -2 removed
14:05:14 <johnthetubaguy> usual things for -2 removal ^
14:05:21 <johnthetubaguy> #topic Bugs
14:05:24 <johnthetubaguy> so we got onto bugs there
14:05:41 <johnthetubaguy> markus_z: the floor is yours
14:05:58 <markus_z> only the new bugs within the last 2 days
14:06:04 <jaypipes> mriedem: looking at https://review.openstack.org/#/c/296305/ now.
14:06:10 <markus_z> I couldn't look at them yet and I don't know if they could affect the release
14:06:21 <markus_z> rest looks fine. Need volunteers as usual
14:06:26 <mriedem> i'll look this morning
14:06:32 <markus_z> mriedem: thanks!
14:06:48 <markus_z> reminder: Nova bugs team meeting is happening each Tuesday
14:06:52 <johnthetubaguy> cool, sounds good
14:06:54 <markus_z> nothing more to say right now
14:06:56 <sdague> o/
14:07:00 <johnthetubaguy> mriedem: any stable things to raise?
14:07:00 <mriedem> shite
14:07:02 <mriedem> https://bugs.launchpad.net/nova/+bug/1561357
14:07:02 <openstack> Launchpad bug 1561357 in OpenStack Compute (nova) "VM deployed with availability-zone (force_hosts) cannot be live migrated to an untargeted host" [Undecided,New]
14:07:06 <mriedem> ^ might be a regression
14:07:30 <dansmith> bauzas: ^
14:07:30 <johnthetubaguy> that sounds that way, sounds like something bauzas and pkoniszewski were looking at
14:07:32 <mriedem> i don't have any news for stable, could use some help from other nova-stable-maint cores to go through the stable/liberty stuff that already has a +2
14:08:17 <bauzas> mriedem: so we discussed on that with johnthetubaguy this EU morning
14:08:42 <johnthetubaguy> thats why I remember it, that was before lunch though
14:08:45 <bauzas> mriedem: I don't think it's really a problem, because if operators force a destination when booting, they also need to force a destination when migrating it
14:08:56 <sarafraj> o/
14:09:12 <johnthetubaguy> bauzas: we should look if its easy to drop that force on the re-schedule
14:09:22 <mriedem> bauzas: we can talk in -nova after the meeting
14:09:26 <mriedem> sounds like a regression though
14:09:28 <johnthetubaguy> if its terrible then we can skip the backport
14:09:32 <bauzas> johnthetubaguy: that looks trivial
14:09:34 <dansmith> I dunno,
14:09:45 <dansmith> seems like a thing to just document the workaround
14:09:49 <bauzas> johnthetubaguy: I'm not worried by the fix, I'm more worried by the logic
14:10:03 <johnthetubaguy> it does over-ride the users preference, which is kinda what the force host is for
14:10:12 <johnthetubaguy> dansmith: we should just add a reno I guess
14:10:13 <sfinucan> (Sorry I'm late)
14:10:20 <johnthetubaguy> s/should/could/
14:10:23 <dansmith> johnthetubaguy: kinda seems like it yeah
14:10:23 <bauzas> but like mriedem said, we can discuss that in -nova
14:10:27 <johnthetubaguy> yeah
14:10:34 <johnthetubaguy> #topic Open discussion
14:10:40 <johnthetubaguy> #link https://etherpad.openstack.org/p/newton-nova-summit-ideas
14:10:57 <johnthetubaguy> I was going to ask about feature classification stuff
14:11:15 <johnthetubaguy> I have some help to start populating the matrix out, so hope to get that started
14:11:26 <johnthetubaguy> to help increase our test coverage, or at least highlight the holes
14:11:39 <johnthetubaguy> #link https://review.openstack.org/#/c/264719
14:11:46 <johnthetubaguy> but not quite sure how to track it
14:11:51 <johnthetubaguy> maybe a bp?
14:12:17 <johnthetubaguy> PS, there is nothing more on the agenda now, so feel free to pipe up with questions
14:12:46 <markus_z> I would have something?
14:13:05 <johnthetubaguy> mriedem: what do you think about the above, just use a blueprint to track it?
14:13:24 <mriedem> johnthetubaguy: i was going to say i was indifferent, specless bp would be fine, i haven't read the change yet though
14:13:38 <mriedem> like...
14:13:41 <bauzas> it's documentation, right?
14:13:49 <markus_z> specless bp sounds fine I think.
14:13:51 <mriedem> sdague is redoing the api docs, but i don't think we have a bp for that, and i'm fine without one
14:13:52 <bauzas> if so, +1 to a specless BP
14:14:04 <markus_z> just to point to something
14:14:11 <bauzas> just in case we need a whiteboard
14:14:12 <johnthetubaguy> yeah, its just docs, specless BP seems good, for a pointer
14:14:21 <mriedem> works for me
14:14:25 <sdague> mriedem: we will have something to point at once we've baked out the POC, probably blueprint + big etherpad
14:14:40 <johnthetubaguy> sdague: yeah, pointers are good, that works
14:14:41 <mriedem> sdague: ok
14:14:57 <mriedem> i think markus_z had something
14:15:21 <markus_z> I just wanted to shout out the start of the discussion how we handle RFEs from ops
14:15:31 <johnthetubaguy> RFE?
14:15:34 <mriedem> i brought that up in the ops meeting yesterday
14:15:39 <dansmith> request for enhancement
14:15:39 <markus_z> Request for Feature Enhancements
14:15:42 <dansmith> feature requests
14:15:42 <johnthetubaguy> ah, right
14:15:58 <johnthetubaguy> yeah, thats basically the neutron specless bp process
14:16:01 <markus_z> yeah, the wishlist bug reports clutter up the bug list
14:16:05 <mriedem> there were 2 ops guys in the meeting, the ptl said he'd try to stoke up some replies from other ops on the ML
14:16:20 <mriedem> johnthetubaguy: i think neutron actually uses LP bugs though
14:16:41 <mriedem> markus_z is proposing wishlist type / RFE bugs start in the ops ML
14:16:54 <sdague> right, the neutron RFE process mostly replaces specs
14:16:55 <johnthetubaguy> OK, gotcha
14:17:24 <mriedem> #link ops RFE ML thread http://lists.openstack.org/pipermail/openstack-operators/2016-March/009942.html
14:17:46 <markus_z> I'm bringing it up here in the meeting but put it on the Newton summit etherpad too
14:18:05 <markus_z> It's fine to trigger the discussion but I cannot make a decission without concensus
14:18:27 <markus_z> I don't find people for bug triage, not sure how to find people to work on wishlist items
14:18:43 <mriedem> like i said, raginbajin (ops PTL) was going to try and wrassle up some feedback from the ops people
14:18:47 <markus_z> long story short, I'll pester you at the summit with that topic :)
14:19:03 <mriedem> so i think we sit on this for at least another week or two
14:19:13 <markus_z> mriedem: yep, that's ok
14:19:15 <johnthetubaguy> feels like a good thing to discuss in an ops session at the summit
14:19:23 <mriedem> yeah, raginbajin also suggested that
14:19:26 <johnthetubaguy> (with a concrete proposal to review)
14:19:28 <johnthetubaguy> cools
14:19:40 <mriedem> the proposal is pretty concrete in the ML
14:19:52 <mriedem> at least, as concrete as a new thing should probably e
14:19:53 <mriedem> *be
14:20:08 <johnthetubaguy> yeah, sorry, I was unclear
14:20:50 <markus_z> that's all from my side
14:21:11 <mriedem> unrelated, i was going to point out the newton specs review etherpad https://etherpad.openstack.org/p/newton-nova-spec-review-tracking
14:21:12 <johnthetubaguy> cool
14:21:19 <mriedem> it's also in the ML
14:21:42 <tojuvone> I would have the maintenance API thingy as now have some kind of spec. Yes, API meeting was yesterday
14:21:45 <mriedem> i've mostly been interested in re-approving things from mitaka rather than looking at new specs
14:21:46 <johnthetubaguy> mriedem: we did talk about just using the single etherpad, rather than the two last time
14:22:08 <mriedem> johnthetubaguy: we did? :) the review priorities etherpad gets to be a monster
14:22:25 <dansmith> I stopped looking at it because it split
14:22:25 <dansmith> FWIW
14:22:37 <mriedem> ok
14:22:51 <johnthetubaguy> I think we need to keep sub team notes out of that etherpad
14:22:54 <mriedem> https://etherpad.openstack.org/p/newton-nova-spec-review-tracking started as mostly a way for me to keep track of how many previously approved things we've approved again
14:22:56 <dansmith> I think there's too much on it
14:22:57 <johnthetubaguy> lets just go back to review links
14:22:59 <dansmith> but I think the split was wrong
14:23:14 <johnthetubaguy> it needs to go on a diet that etherpad
14:23:18 <johnthetubaguy> to get it useful again
14:23:24 <dansmith> heh
14:23:27 <bauzas> ideally, it should be a gerrit dash
14:23:41 <mriedem> bauzas: http://tinyurl.com/hjhu75e
14:23:46 <bauzas> how we generate the dash url is the key question
14:23:48 <dansmith> I don't want a gerrit dash I think
14:24:02 <dansmith> unless it's hand-cultivated like the etherpad once was
14:24:10 <dansmith> it needs to be "top ten or less" for each priority, IMHO
14:24:17 <bauzas> mriedem: that dash is not saying which changes are prioritary and which not
14:24:27 <johnthetubaguy> yeah, I tried to ask for top 3-5, but I would settle for top 10
14:24:28 <markus_z> dansmith: "top ten" by which order?
14:24:36 <dansmith> markus_z: priority owner order
14:24:38 <mriedem> bauzas: technically we haven't set priorities for newton
14:24:41 <bauzas> dansmith: fortunately, we can limit a gerry query, but sure we can keep the etherpad short
14:24:42 <johnthetubaguy> right, the subteam's own order
14:25:15 <johnthetubaguy> bauzas: its delegated in the etherpad, thats not that easy in a gerrit dashboard
14:25:30 <bauzas> okay, sounds you got my convinced that I didn't had a great idea :p
14:25:41 <dansmith> bauzas: but short isn't the only problem
14:25:42 <bauzas> let's keep the etherpad, but keep it short
14:25:50 <dansmith> bauzas: if gerrit had a scoring system with priorities, then yes :D
14:25:57 <johnthetubaguy> dansmith: +1
14:26:06 <mriedem> so we're asking that subteams just lump 3-5 reviews into the newton review priorities etherapad?
14:26:09 <bauzas> dansmith: what's the other problem with etherpads ?
14:26:12 <mriedem> and those 3-5 are code and specs?
14:26:22 <johnthetubaguy> mriedem: yeah, maybe go top 10, and include specs and code?
14:26:24 <bauzas> except the brevity ?
14:26:32 <dansmith> mriedem: that's my preference.. ten or less
14:26:53 <bauzas> are we mentioning gerrit topic queries ? :p
14:26:53 <johnthetubaguy> if its short, it will hopefully stay useful
14:27:06 <dansmith> topics are fine
14:27:08 <dansmith> (with me)
14:27:08 <bauzas> ie. one topic and 20 changes ? :D
14:27:12 <bauzas> I do too
14:27:12 <mriedem> one problem i have with the etherpad of doom
14:27:15 <mriedem> is the order
14:27:21 <mriedem> i tend to only focus on the things at the top
14:27:31 <mriedem> now if you're cells v2, that's great for you
14:27:35 <dansmith> bauzas: 20 patches in a topic as listed means they're in the order of git priority
14:27:37 <johnthetubaguy> mriedem: its normally priorities at the top, other stuff below
14:27:46 <mriedem> johnthetubaguy: true
14:27:46 <bauzas> dansmith: yup, agreed
14:28:01 <mriedem> johnthetubaguy: but that's also how we end up having specs re-proposed for 3 releases
14:28:06 <johnthetubaguy> mriedem: hopefully with less patches we get more reviews on your screen ;)
14:28:24 <dansmith> mriedem: the problem with three etherpads is I focus on none of them :)
14:28:37 <mriedem> yeah, so i'm fine with a single etherpad to rule them all
14:28:43 <bauzas> wfm
14:28:46 <mriedem> i'm fine with keeping each section <10
14:28:55 <johnthetubaguy> so seems worth a try
14:28:57 <mriedem> let's put that in big super f'ing bold header at the top
14:29:02 <johnthetubaguy> +1
14:29:08 <dansmith> it was at one point It hought
14:29:09 <cdent> how about each subteam can put two reviews at the top of the page, everything else in sections below?
14:29:10 <dansmith> for liberty
14:29:26 <cdent> and if they don't keep that list of two up to date that's their own damn fault
14:29:27 <mriedem> cdent: there are like 30 subteams
14:29:33 <cdent> make it one then
14:29:34 <dansmith> yeah, not a good plan
14:29:43 <cdent> or get rid of some teams :(
14:29:47 <johnthetubaguy> yeah, priorities at the top, subteams below
14:30:06 <johnthetubaguy> so how about we just delete all the existing stuff
14:30:11 <cdent> it sounds like none of this actually is addressing the real problem, but if you want to put bandaids on it, it has to devolve the responsibility for attention to the teams
14:30:21 <johnthetubaguy> if its an active subteam, it will re-appear?
14:30:31 <mriedem> johnthetubaguy: not a terrible idea
14:30:34 <cdent> I like that
14:30:36 <dansmith> johnthetubaguy: you mean periodically delete the subteam section?
14:30:44 <mriedem> dansmith: well at least on release boundaries
14:30:53 <dansmith> ah, sure
14:31:05 <dansmith> mriedem: you could just rearrange the priorities in the etherpad every few weeks
14:31:08 <dansmith> if you think it'd help
14:31:21 <dansmith> like if you feel like one thing is getting neglected, push it to the top
14:31:33 <mriedem> yeah i might do that at some point
14:31:40 * cdent collects money to bribe mriedem
14:31:51 <dansmith> to be fair,
14:31:56 <dansmith> cells has been at the top for like two cycles,
14:32:03 <dansmith> and it gets very little review
14:32:04 <dansmith> IMHO
14:32:05 <mriedem> yes, cells v2 is obviously a prioirty
14:32:12 <alaski> dansmith: agreed
14:32:14 <mriedem> right, so this leads into my bigger issue
14:32:21 <mriedem> and why i started https://etherpad.openstack.org/p/newton-nova-spec-review-tracking
14:32:24 <dansmith> so I'm not sure how much pagerank matters :D
14:32:27 <johnthetubaguy> mriedem: dansmith: yeah, release boundary is the normal thing we do, we could do it at the milestones, but that seems a bit rude
14:32:41 <mriedem> we have a large backlog of re-approvals
14:32:42 <dansmith> I thought that's what mriedem meant
14:32:44 <mriedem> seen at the top of https://etherpad.openstack.org/p/newton-nova-spec-review-tracking
14:33:18 <mriedem> personally, i would like to freeze spec approvals for new things that are not directly related to priorities for the first milestone
14:33:49 <mriedem> i know that's not popular probably
14:34:18 <mriedem> i wanted to go over more of this at the summit, but the problem with that is, it's 4 weeks away still
14:34:27 <markus_z> mriedem: I think it's valid to give a warning that the next Ocata cycle could handle it that way
14:34:39 <cdent> (doing unpopular things)++
14:34:40 <mriedem> markus_z: i'm not sure why we couldn't do that now
14:34:51 <johnthetubaguy> mriedem: we have a bit backlog of specs that have code, and need reviews, so it seems like a good way of dealing with that I guess
14:34:53 <mriedem> we have A LOT of carry over from mitaka (and previous releases)
14:35:02 <edleafe> mriedem: +1
14:35:09 <johnthetubaguy> we have a heap of stuff from kilo
14:35:10 <mriedem> i really really want to flush what we have before saying we're going to take on new things
14:35:14 <mriedem> and then never reviewing them
14:35:21 <cdent> +1
14:35:35 <cdent> orbital mechanics: slow down to speed up
14:35:41 <mriedem> this is why i've just been looking at previously approved specs
14:35:42 <markus_z> mriedem: to be honest, I don't have an overview of the backlog. I thought people could percieve it as on too short notice.
14:36:01 <mriedem> markus_z: so people are going to complain, for sure,
14:36:04 <bauzas> from what I understood, is the Ocata cycle planned to be shorter ?
14:36:09 <johnthetubaguy> so the thing is, if we approve their thing, its not likely to merge anyways
14:36:13 <mriedem> markus_z: but people are going to complain when we approve their spec and never review their code either
14:36:15 <johnthetubaguy> this is just advance notice, in some ways
14:36:24 <johnthetubaguy> what mriedem said
14:36:28 <markus_z> mriedem: true. probably the bigger complain then
14:36:44 <mriedem> yeah, i'd like to at least be honest and get a more manageable chunk of stuff to focus on
14:36:44 <edleafe> markus_z: people complain more about getting bumped cycle after cycle
14:37:00 <johnthetubaguy> now there might be stuff that semi-priority, we could always see where that lands
14:37:11 <mriedem> my hope is that with fewer things to focus on as a team, we can chug through more things
14:37:15 <markus_z> edleafe: agree
14:37:31 <mriedem> and once we start to get a baseline, we can start adding new things in
14:37:32 <johnthetubaguy> so thats where I think we need to make the etherpad work better
14:37:42 <johnthetubaguy> limit the work in progress, so we get more done
14:37:46 <markus_z> mriedem: we should give an onboarding chance to the topics which need to be finished
14:37:47 <mriedem> johnthetubaguy: agreed
14:38:00 <mriedem> markus_z: onboarding chance?
14:38:16 <mriedem> markus_z: i'm really just talking about the backlog right now
14:38:25 <mriedem> which means things which need to be finished
14:38:25 <markus_z> mriedem: yeah, me too
14:38:45 <mriedem> so, i think there are 2 very easy things to do to get started,
14:38:49 <johnthetubaguy> so maybe we are having violent agreement here?
14:38:52 <mriedem> 1. clear the review priorities etherpad
14:39:09 <bauzas> just for a general note, it's not really a review problem, it's rather a commitment problem
14:39:12 <mriedem> 2. start adding in things (including specs) which are approved, which right now should only be previously approved tihngs
14:39:29 <bauzas> http://russellbryant.net/openstack-stats/nova-openreviews.html just tells us that patches are mostly waiting for submitters rather than reviewers
14:39:39 <markus_z> mriedem: The folks which don't get bp approved could spent effort on the approved backlog items. I think they need pointers how to help there.
14:39:56 <markus_z> mriedem: not sure if I can make myself clear
14:40:02 <dansmith> markus_z: that's the theory, but it rarely pans out that way
14:40:04 <mriedem> markus_z: i see what you're saying
14:40:09 <mriedem> yeah
14:40:23 <mriedem> for example, let's say today we said the only review priority is cells v2
14:40:25 <dansmith> mriedem: so what if we just do no spec approvals until summit? this next four weeks is just for flushing the queue
14:40:25 <markus_z> dansmith: oh, ok, I lack the long time experience here
14:40:25 <johnthetubaguy> mriedem: review stuff, and do bug fixes? there quite a lot of stuff, mox, centralize config, etc
14:40:32 <mriedem> dansmith: i like that
14:40:32 <dansmith> expecting basically only previously approved priorities to go
14:40:42 <dansmith> mriedem: not the whole n1, but just until summit
14:40:53 <mriedem> dansmith: that's still a month, so i'm fine with that
14:40:59 <johnthetubaguy> so that could work
14:41:04 <dansmith> they were previously approved, so they're clearly important
14:41:06 <edleafe> sounds reasonable
14:41:09 <mriedem> markus_z: but yeah, there are always other things to help on
14:41:14 <dansmith> and we don't approve new things until we decide on new prios
14:41:15 <mriedem> bugs, cleanup, reviews, etc
14:41:23 <markus_z> I'm in for that
14:41:37 <bauzas> dansmith: and we keep non-prio spec freeze ?
14:41:37 <markus_z> bugs cleanup dashboard: http://45.55.105.55:8082/bugs-dashboard.html
14:41:43 <mriedem> bauzas: yes
14:41:46 <mriedem> until summit at least
14:41:48 <dansmith> bauzas: no new spec approvals
14:41:51 <mriedem> that gives us a month to see how this goes
14:41:58 <dansmith> only re-approvals and landing things that were approved already
14:42:02 <johnthetubaguy> yeah, I guess we could limit the number of approved low priority blueprints at any time, post summit, etc, but thats for later
14:42:04 <bauzas> dansmith: that, I understood
14:42:25 <bauzas> dansmith: I just wonder if people want to add a new spec post-summit, and we cut those at N1
14:42:26 <mriedem> johnthetubaguy: i'd like to wait for after the summit
14:42:29 <johnthetubaguy> #info no new spec approvals until the summit, at which point we can come up with a plan for the cycle
14:42:36 <johnthetubaguy> mriedem: yeah, agreed
14:42:52 <bauzas> okay
14:43:00 <dansmith> bauzas: yeah,  but you can propose a spec whenever you want
14:43:01 <mriedem> bauzas: i imagine there will be some wiggle room for that in n-2
14:43:12 <dansmith> bauzas: just don't expect it to get approved
14:43:14 <mriedem> right, spec proposals is totally fine and encouraged
14:43:18 <mriedem> dansmith: ++
14:43:26 <johnthetubaguy> so there is a downside here, its good to resolve conflict in spec reviews in person at the summit
14:43:36 <johnthetubaguy> but I think we should ignore that, we have enough stuff anyways
14:43:37 <bauzas> dansmith: yeah, okay, I got it
14:43:45 <dansmith> johnthetubaguy: only 24 hours in each day
14:43:53 <mriedem> johnthetubaguy: yeah, i think that has to take a backseat
14:43:55 <dansmith> johnthetubaguy: can't win 'em all
14:43:57 <mriedem> johnthetubaguy: people can get on hangouts
14:44:00 <dansmith> johnthetubaguy: you win some you lose some
14:44:06 <mriedem> plus we will probably have a meetup
14:44:09 <johnthetubaguy> mriedem: dansmith: yeah, +1
14:44:11 <dansmith> hehe
14:44:13 <edleafe> there's always the midcycle :)
14:44:33 <mriedem> i'll post something to the ML on this too
14:44:41 <dansmith> mriedem: was just going to say.. cool
14:44:46 <dansmith> are we done here?
14:44:52 * mriedem expects angry feedback
14:44:52 <johnthetubaguy> I think we are
14:44:52 <markus_z> +1
14:45:11 <mriedem> +1 for being done
14:45:13 * johnthetubaguy passed mriedem the padded kevlar gear
14:45:20 <dansmith> heh
14:45:29 <johnthetubaguy> #endmeeting