20:02:42 #startmeeting tc 20:02:43 Meeting started Tue Jul 14 20:02:42 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:46 The meeting name has been set to 'tc' 20:02:50 Alright, here is our agenda for today: 20:02:55 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:14 o/ 20:03:22 * devananda lurks 20:03:27 #topic Cross-project-spec final approval: Eventlet Best Practices 20:03:30 #link https://review.openstack.org/#/c/154642/ 20:03:41 Looks like this one has lingered enough and has enough consensus to get the final approval rubberstamp 20:03:58 Any objection ? 20:04:04 STAMP IT 20:04:21 stamped 20:04:24 all the stamps 20:04:32 #topic Add neutron to starter-kit:compute 20:04:34 * mordred stamps the stamps 20:04:35 ttx: o/ 20:04:39 #link https://review.openstack.org/196438 20:04:56 This is a continuation from last week discussion, where we delayed decision for one week, waiting for a new patchset and Jay to have enough time for a deeper dive 20:05:13 on this one and its friend, I fixed some typo-style reviews from folks in follow-on patches 20:05:14 Looks like it won a majority over the week 20:05:27 thanks, pleia2 ! 20:05:39 oops, wrong channel - me leaves and says sorry 20:05:46 (just returning from a 2-day break so if I appear to be slightly off, that's normal) 20:06:10 Questions before we move to final approval on it ? 20:06:11 o/ sorry 20:06:49 personally, pretty happy how it all turned out 20:07:05 me too 20:07:13 yes, I think our starter kit now gets stronger 20:07:17 I think we found some good clear language about some things 20:07:30 it's almost like collaboration worked to a positive benefit 20:07:36 \o/ 20:07:41 mordred: we should build a project around that concept 20:07:45 I have a question on the install guide, has anyone talked to Lana or the install guide folks about it? 20:07:47 ttx: bah. it'd never work 20:08:11 annegentle: Lana +1ed the review, but not sure if she considered the install guide specifically 20:08:18 ok, cool 20:08:18 annegentle: we have to collaborate with MORE people? ;) 20:08:27 even more! and they *gasp* write stuff 20:08:30 ugh 20:08:53 Alright, 30 more seconds to record your vote on this historic moment and I'll rubberstamp it 20:09:37 done 20:09:55 A few more tag adjustments/definitions 20:09:56 #topic Redefine release tags to match new models 20:10:02 #link https://review.openstack.org/198789 20:10:08 this one is about adapting the release tags to the recent changes in Liberty 20:10:16 In particular the rise of the "follows development cycle with intermediary releases" model 20:10:25 The old set of tags were additive, and only a few combinations were actually supported 20:10:35 This new set of tags clearly defines 4 exclusive options 20:10:37 question o/ 20:10:42 annegentle: yes 20:11:11 ok, so we have release:none (think: openstack/governance) as an example, but are we applying tags at a release cycle point-in-time eventually? 20:11:36 annegentle: you can still push tags. They just don't result in tarballs or anything 20:11:54 ttx: they result in a page being published 20:12:36 annegentle: you mean for docs ? 20:12:42 thinking of it from a docs standpoint, right. 20:12:53 ttx: how would we know when to apply a governance tag 20:13:00 I may be overthinking this, totally possible 20:13:06 if the docs are not continuously produced and you "publish" them on a tag, I would count that as a release 20:13:25 (it's a doc release triggered by a tag) 20:13:36 I would agree, fwiw 20:13:37 But that's arguably a corner case 20:13:42 yes, on the docs site we use a mechanism like that, but for tags published to governance.openstack.org do we need something similar 20:14:01 annegentle: governance.o.o is continuously published, so I'd say no 20:14:11 it has no release, the repo is the state 20:14:20 right now governance.openstack.org is continually published, with no "release" mechanism, but we may way to change that to publish tags after a release date. 20:14:37 annegentle: sure, and then we'll change the release model tag 20:14:38 (pages that describe tags is what I mean) 20:14:45 ok, got it 20:14:48 it can certainly evolve over time :) 20:15:07 Alright, has enough votes now, will approve in 30sec 20:15:14 unless there are other questions 20:15:24 I'm good 20:15:54 ok done 20:15:57 #topic Add and apply vulnerability:managed tag 20:16:01 #link https://review.openstack.org/199720 20:16:11 This one is proposed by the VMT, to keep track *and* communicate which projects are directly handled by the team 20:16:16 fungi: around? 20:16:19 yep 20:16:20 o/ 20:16:26 questions on that one ? 20:16:41 looks like it's well received 20:16:54 I found the name funny but I agree the alternative is funnier. 20:17:00 basically just documenting the current state with a tag, not changing any policy/process (yet) 20:17:25 yeh, super straight forward: STAMP! 20:17:26 Alright... no questions ? 20:17:35 stamping in 30 sec 20:17:38 it feels like this is a better first step, then we can evolve the process in a more governance-facing way once we have the initial tag definition 20:18:03 stamped 20:18:05 one more ugly wiki article get vaporized! 20:18:08 #topic No longer support attributes in tags 20:18:15 fungi: DIE WIKI DIE 20:18:19 heh 20:18:20 I do agree with jaypipes' suggestion to link to the wiki, but I think that can be a minor update patch without full meeting review 20:18:26 #link https://review.openstack.org/199986 20:18:33 So... With the removal last week of the integrated-release tag, we don't have any tag using attributes anymore, and I think it's the occasion to phase the concept out 20:18:42 dhellmann: yup, later patch totally cool. 20:18:44 I blame attributes for giving to some people the wrong idea of what a tag is. A tag should have an opinionated description and an objective application. 20:18:56 In the recent months we've been pushing things like "team:diverse-affiliation" rather than "team:diverse-affiliation (score=80%)" and I think that's good rather than bad. 20:19:08 So I would further encourage that direction by removing that concept from the template, and ultimately from the file format 20:19:23 Looks like I have a majority with me 20:19:28 Questions ? 20:19:32 seems fine, and can always re-propose it if there's a good argument in the future to add it back 20:19:34 as someone who continually has to parse this yaml file, i would love to remove attributes and just have tag names in the list 20:19:46 dhellmann: don't disclose our secret plan! 20:19:55 * dhellmann shuts up 20:20:10 dhellmann: plan is to phase them out when/if we introduce deliverables as a v2 format 20:20:14 but shhh 20:20:19 ok, so STAMPING? because this seems really straight forward 20:20:27 yup 20:20:29 yep, in 30 seconds unless someone yells 20:20:36 can i yell for a different reason? 20:20:43 your time will come 20:20:47 russellb: you can yell any time 20:21:01 ok great, just checking, i don't have anything to yell about, i just value my right to yell 20:21:07 yes, this whole consensus thing is starting to strike nerves 20:21:10 I also value your right to yell 20:21:18 #topic RPM distribution packaging of OpenStack 20:21:23 #link https://review.openstack.org/191587 20:21:30 RPM packaging is back on the docket after a few week's hiatus 20:21:39 I think that's a great initiative, clearly an open collaboration reducing duplication of effort 20:21:52 It feels more "real" now than it was a few weeks ago, so I see no reason to further block it 20:22:15 real work getting done? 20:22:57 well, just the fact that the two main distros agreed on a plan and co-PTLs is telling enough 20:23:13 yah. /me is a fan of agreement 20:23:17 there was a new rev, you may want to reapply votes 20:23:20 ttx: I rebased https://review.openstack.org/199720 20:23:38 yeh, I feel like this seems pretty straight forward, fedora and suse working together 20:23:39 Let me restamp that for you 20:23:48 so speaking of 'and' we used '&' for searchlight.. which is the preferred style :) 20:24:07 ttx: and https://review.openstack.org/199986 20:24:09 that seems like it can only be good for our community to have more commonality 20:24:10 * mordred hands markmcclain a not-very-undrunk jaguar 20:24:14 you can't use and & & together? 20:24:21 or 20:24:26 o/ 20:24:26 you can't use and and & together? 20:24:40 haha... seriously I think the collaboration is a good thing 20:25:12 * ttx F5s 20:25:16 so with no questions, probably keep moving. 20:25:21 votes can collect later 20:25:26 Alright, we have a majority apparently. 20:25:27 we don't have to hold up for them 20:25:40 Objections to me stamping now ? 20:26:00 I like collaboration. 20:26:00 and... 20:26:06 done! 20:26:17 Welcome, RPM packaging. 20:26:22 #topic Add Fuel to OpenStack Projects 20:26:28 #link https://review.openstack.org/199232 20:26:34 i'm in the process of -1ing this. 20:26:41 Large project that has been part of our landscape for some time now 20:26:48 fuel does not use OpenStack CI at all, and does not conform to the the project testing interface 20:27:04 Right. Another thing I'm concerned about here is... a project in OpenStack should not be owned by a given company. And here given how large and old the contributor base is, it is de-facto owned by Mirantis 20:28:06 yeah the top 100+ reviewers from there 20:28:07 I'm still not sure I would -1 over it, but... I'd like to be sure the project is not locked 20:28:18 I had forgotten that they do not have any jobs running in openstack's ci system. that they have an additional CI system for some things does not bother me - but it would be great if it would conform to the PTI and also have the jobs that can be in openstack's ci in openstack's ci 20:28:29 mordred: ++ 20:28:34 dont they have another gerrit too? 20:28:36 that's the gist of the comment i just left with my -1 20:28:42 I seem to recall running into it once 20:28:43 http://governance.openstack.org/reference/new-projects-requirements.html doesn't specify the PTI as a requirement 20:28:48 its not mentioned at all 20:28:53 and diversity is now a tag 20:28:57 I'm *really* confused here 20:29:04 diversity isn't a blocking issue 20:29:18 I think " 20:29:20 The project has core reviewers and adopts a test-driven gate for changes" 20:29:21 lifeless: er, the pti itself is a requirement... its a resolution the tc passed intended to apply to all projects 20:29:24 I just think this is another instance where team:diversity-danger would be appropriate 20:29:52 anti-diversity? 20:29:56 jeblair: its documented in the governance repo, its not prescribed by the url I linked to as criteria for inclusion 'in openstack' 20:29:58 PTI stands for? 20:30:04 all: please read Dmitry's response to Sean Collins acknowledging quite openly the areas that the Fuel team needs to improve. 20:30:04 annegentle: project testing interface 20:30:06 annegentle: Project Testing Interface 20:30:08 It's also a fork of the puppet modules, which seems strange. 20:30:09 which we should probably formalize at some point, because a whole crop of recent projects fall into diversity-danger 20:30:11 thanks 20:30:26 jaypipes: yah - I liked that response a lot 20:30:37 BTW, how'd the Triple-O CI region work out? ... 20:30:37 annegentle: http://governance.openstack.org/reference/project-testing-interface.html 20:30:41 I must've confused the ci with it 20:30:48 jeblair, lifeless : should the PTI be added to new-project-requirements? 20:30:51 jaypipes: yeah. I guess another way to ask my question would be: is an installer an opinionated thing, or can open design work for it 20:30:58 jaypipes: there were two, and one has worked well :) 20:31:06 dhellmann: i'm boggling a little at the legalese here... 20:31:25 jeblair: I'm not trying to be legalistic. 20:31:30 jaypipes: yah - so - I think having an additional external CI is a great thing 20:31:38 is there API overlap? 20:31:42 jeblair: I'm trying - as a tc member no less - to actually understand the decisions the big tent discussion actually made 20:31:47 jaypipes: because there are things tha tthings like fuel and tripleo are never really going to be able to test in the infra systems 20:31:58 jaypipes: otoh - there are plenty of thigns that can - and should - be tested there 20:32:01 i would contend that if the tc pases a resolution applicable to all projects of course it's required for new projects. however, if there is confusion on that point, then yes, i suppose we should add an item to the new projects criteria that says "adheres to resolutions passed by the tc that apply to all projects" 20:32:08 russellb: my point being that CI for bare-metal provisioning isn't the same problem domain as virtualized systems... Fuel has its own CI system, modelled on upstream with an active intent to align entirely with upstream. 20:32:09 jeblair: the docs have a lovely page, which replaced another much longer page, and folk are saying that things elsewhere are also actually requirements. 20:32:14 I agree with jeblair 20:32:20 jaypipes: got it 20:32:29 lifeless: I thinnk OpenSTack projects are about Open Collaboration. If there is no collaboration, I don't see the point of having that project in openstack. It can live in corporate borders. 20:32:45 lifeless: that's fair -- we have arrived at this conversations with widely divergent assumptions. i'm just surprised is all. we can converge i'm sure. :) 20:32:47 So I need to be convinced there will be collaboration in Fuel design basically 20:32:48 ttx: sure, and the four opens are clearly covered and docs. 20:32:59 to be clear 20:33:06 I'm not voting for or against fuel at this point. 20:33:07 jaypipes: cool - so, I think that's awesome - similar to what we told the folks last week, maybe having the fuel team take the first couple of steps of that would be nice? 20:33:30 I want though, to feel that we're being clear and upfront to them about whats expected 20:33:30 lifeless: I'm more after some clear statements from the Fuel team, rather than blocking anything. 20:33:30 jaypipes: like, I think it would be awesome for fuel to be in the tent (I did +1 before I was reminded of the CI bits) 20:33:32 mordred: yep, and they are eager to address the disparities. 20:33:40 jaypipes: that's excellent to hear 20:33:46 jeblair: absolutely. 20:34:03 mordred: jeblair's "retire stackforge" patch was certainly a kick in the pants to get going. 20:34:06 so, I think we should add a note saying that they must /also/ meet any global policies the TC may have 20:34:16 where they == new projects 20:34:19 I'll draft that up 20:34:23 lifeless: thx 20:34:24 lifeless: sounds like a plan, thanks :) 20:34:26 mordred: as was the long ML thread with EmilienM about aligning to puppet-openstack upstream. 20:34:41 jaypipes: ++ 20:34:47 jaypipes: o/ 20:34:49 jaypipes: that's good, hogepodge does that address concerns? 20:34:58 and any Tuskar API overlap concerns? 20:35:19 plenty of overlap in the deployment space already 20:35:25 so i'm not worried about that part 20:35:25 EmilienM: that ML thread was just another push for Fuel to align more with upstream stuffs... 20:35:31 yeah, me neither 20:35:37 ok 20:35:50 yeh, I feel like deployment has so many different approaches, we just need to let those all play out 20:35:57 agree 20:36:04 jaypipes: does that mean something like fuel becoming a downstream consumer of puppet-openstack modules? 20:36:05 it is very clear that one size does not fit all there 20:36:27 sdague: crystal clear :) 20:36:36 jeblair: yes, that has already been 100% agreed. 20:36:46 jaypipes: they are clearly not ready yet though. Do we have a timeline for this? 20:36:47 has progress been made in renconciling them? it's been promised for a long while but never seems to happen 20:37:08 EmilienM: the intent is 100% there. it's just going to take a little time to align, of course. 20:37:14 lifeless, jeblair : https://review.openstack.org/201764 20:37:19 I just have to switch from thinking Fuel is Mirantis's installer to "Fuel can be a community-developed openstack installer" 20:37:26 EmilienM: dmitry is actively working on a timeline, yep. 20:37:35 EmilienM: we can take this offline, though... 20:37:36 and what is important to be in the big tent, attent or real situation ? 20:37:48 EmilienM: both. 20:37:51 jaypipes: cool, ping me anytime 20:37:56 dhellmann: so I think thats insufficient. I have a different change in draft 20:38:02 lifeless: k 20:38:06 jaypipes: so, I think maybe we should start an email thread similar to EmilienM's about the puppet modules about which bits of fuel CI we can realistically do in infra 20:38:17 and what that plan wants to look like 20:38:25 jaypipes: I've been told it's happening as far back as Hong Kong 20:38:33 how much time is needed? 20:38:34 me too :) 20:38:35 hogepodge: I do think it's good to give them a push then through this review 20:38:50 mordred: my long and though thread? 20:38:51 so those concerns from hogepodge and EmilienM are concerning to me 20:38:57 hogepodge: it is happening, yes. I'll ask Dmitry to email the ML with the current timeline and plan. 20:39:00 EmilienM: ^ 20:39:03 jaypipes: sounds good 20:39:15 mordred, jaypipes: yeah, we know we can't test everything, but we can certainly do some (there's quite a bit of testing in puppet-openstack and it's getting better quickly) 20:39:21 because if it's been a long line of promisses and no action, it's hard to have faith going forward 20:39:25 mordred: https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg55455.html ? 20:39:36 jeblair: ++ 20:40:02 sdague: understood, and acknowledged. time and actions only will prove things out. 20:40:41 maybe we defer until Puppet team can ack that they're happy with collaboration? 20:40:47 seems like a good step forward 20:40:55 russellb: ++ 20:40:56 to show good faith around increased collaboration 20:41:08 russellb: I like that idea 20:41:38 ttx: jeblair: dhellmann: https://review.openstack.org/201766 20:41:40 russellb: ++ i think that's a good idea. 20:42:01 jaypipes: ^ may want to look at that too 20:42:05 woah that's a lot of agreement 20:42:20 so, how about we table for now, there are a few collab todos, and swing back around later in the cycle and see how all of that is going 20:42:27 russellb: man, what did you DO? 20:42:35 sdague: +1 20:42:42 let me #agree that 20:42:45 #agree 20:42:53 lifeless: 3 different changes there... 20:42:59 dhellmann: there are 20:42:59 * jeblair agrees with the agreeable russellb 20:43:04 #agreed Fuel -- table for now, there are a few collab todos, and swing back around later in the cycle and see how all of that is going 20:43:18 but in theory, i think it makes perfect sense 20:43:24 dhellmann: and if we have contention, I'll split them out. 20:43:45 lifeless: +1 from me.. 20:43:46 OK... MOAR topics 20:43:51 yep, I'm good with concept, just want to make sure the team is collaborating with the rest of OpenStack well 20:44:01 is someone writing the requet in the review itself? 20:44:05 request 20:44:15 and I want to discuss a bit on the roadmap and open design going forward 20:44:35 since it might be a bit of a cultural change. We never had a *large* non-diverse project yet 20:44:50 so I'd like to start the discussion on open design early rather than late 20:45:04 OK, ready to switch to next topic ? 20:45:09 yup. 20:45:13 #topic Add the Delux Project 20:45:19 #link https://review.openstack.org/199768 20:45:26 Sound like a great thing to have in rather than out 20:45:27 clever name at least 20:45:32 lifeless: generally looks good but i have a nit ;) 20:45:38 There is a bit of a culture/tooling clash which makes it more difficult for me to consider them "one of us", but I think that comes with the territory 20:45:47 and it's just not possible to hold that against them 20:45:58 There was a comment about the name, which I think I agree with 20:46:10 right, I agree it's more similar to translation moving towards more open tooling to me 20:46:17 All other horizontal teams are named after the function. And this particular name has quite a few collisions 20:46:18 ttx: agreed. our code-centric tooling just doesn't mesh with the expectations and customs of the UX and designer folk. 20:46:35 so why not "OpenStack UX" ? 20:46:49 right, though phabricator may bring us some of that, correct? 20:46:49 jeblair: nit picked 20:46:56 Probably just didn't see the parallel for name 20:47:00 jeblair: (I've pushed an update) 20:47:00 OpenStack UX is prefect 20:47:11 yes, one of the reasons we're specifically looking at phabricator is to help address this use case 20:47:31 in fact - thanks for mentioning that in the commit message Piet 20:47:48 np 20:47:58 (because it will be _great_ to have commentable mockups directly associated with future-looking work (ie what we call blueprints now)) 20:48:09 jeblair: that would be awesome 20:48:15 If the OpenDaylight UI was not called DLUX it would probably have been ok, although I prefer horizontal teams being named by function 20:48:23 Piet: cool, thx 20:48:29 Needs a rebase anyway 20:48:58 You can still be called "the Delux crew" :) 20:49:14 Is it possible to rebase now and have you folks vote? 20:49:16 side note, maybe we should have a projects/ directory of yaml files to avoid having to rebase patches to projects.yaml so much 20:49:42 Or an alphabetical ordering enforced 20:49:55 * rockyg thinks russellb's idea is brilliant 20:49:57 side note noted 20:50:04 is it noted on the side? 20:50:22 I think it has a side of bacon 20:50:25 russellb: that will make writing tools to consume the files much more difficult :-/ 20:50:26 I think the detail in teh commit message allows me to feel comfortable with this project not using irc for meetings, and it is the only project I feel this way about 20:50:27 Other questions on UX ? should we wait for the rebase and vote on it ? 20:50:34 mm bacon 20:50:34 esp. since many fetch that file remotely 20:50:37 you got me right there 20:50:47 dhellmann: ok, don't want it to be more difficult 20:51:33 anteaya: I agree 20:51:38 OK, let's move on and pile up on the review when it's patchsetted 20:51:44 #topic Remove cinder from starter-kit:compute 20:51:50 Let's try to sneak this one 20:51:53 I think this one makes sense to most folks already ... 20:51:54 #link https://review.openstack.org/199680 20:52:09 yeh, we are already at 7 +1s 20:52:10 mordred: especially with jgriffith away 20:52:10 i also am concerned about invision but am optimistic about a potential move to phab. (sorry this was late) 20:52:12 but its' based on the reasoning in the neutron patch - cinder is a good case of non-disruptive addition to an existing cloud 20:52:28 ttx: I have heard tell that jgriffith is in favor 20:52:34 We can approve it today if everyone is fine not having jgriffith comment on it 20:52:38 mordred: ttx I'm ok with it 20:52:39 honestly, jgriffith and I had a long conversation about this in #openstack-dev (so it's logged somewhere) 20:52:44 jgriffith: here he is! 20:52:46 oh look! it's a jgriffith 20:52:48 oh there he is 20:52:53 sorry I'm late 20:52:59 I just added my vote 20:53:11 No pb, I just didn't want to rush it without giving you a chance to chime in 20:53:13 jgriffith: you saved a whole guessing game 20:53:24 Looks like we have a winner 20:53:28 yeh, I think this was just part of the collab process with the starter kit, trying a thing, then poking at that thing a bit in real systems, and realizing the initial guess might need a little tweaking 20:53:30 Will rubberstamp in 30 sec 20:53:32 appreciated 20:53:37 questions, raise them now 20:54:13 no questions your honor 20:54:20 Alright, approved 20:54:26 ^? 20:54:30 probably will fail to merge with current state but meh 20:54:41 Ill pick theml up tomorrow 20:54:43 ttx: don't forget the follow up word fix too 20:54:45 #topic Workgroup reports 20:54:58 yeh, there are some trival typo patches in the stack as well 20:55:01 Project team guide... 20:55:02 ttx, mordred: indeed, that should be speedy approved. :) 20:55:07 I'd like the workgroup to review https://review.openstack.org/#/q/project:openstack/project-team-guide+is:open,n,z 20:55:13 Couldn't get flaper87 to post an updated draft for the open development chapter before he went PTO 20:55:19 and I'd like us to have that chapter before we formally publish the first version of the guide 20:55:26 I'll probably pick up that chapter 20:55:37 "Next tags" workgroup... 20:55:48 I mentioned it last week, and sdague started a thread about it -- a workgroup to actively seek and define useful missing tags 20:55:58 Currently we have sdague, russellb, zaneb, Ghe and me, which is already a good size, but feel free to join if you have free cycles 20:56:11 At this stage it's mostly individual brainstorming, but I'd like to start converging, so we'll likely set up a meeting soon 20:56:26 yeah a meeting sounds good to collect ideas and prioritize them 20:56:30 yep 20:56:34 and then i'm happy to carve one off and drive it 20:56:46 should we try this week ? I'm at OSCON next week 20:56:46 ++ 20:56:59 this week is fine with me 20:57:00 like ~Friday or so 20:57:11 yeah, Thursday or Friday for me 20:57:19 OK, will propose something 20:57:20 feels like a good Friday thing 20:57:22 for some reason 20:57:29 Communications... 20:57:30 I am free most of Friday 20:57:33 comms communicating! but let's not do a post this week. 20:58:02 please remember to tweet links to the posts. I'm also trying to get the "Categories" working so they're all collected 20:58:15 Anyone else ? 20:58:19 #link http://www.openstack.org/blog/2015/07/technical-committee-highlights-july-10-2015/ 20:58:37 #topic Open discussion 20:58:56 Next week I'll be in Portland for OSCON, so I originally thought I would miss the meeting, but I think I can actually make it, since it's around lunchtime 20:59:06 Who will be around ? 20:59:12 I should be 20:59:17 I'll be on vacation next week 20:59:18 for the meeting or oscon 20:59:25 i'm around for the meeting. 20:59:26 I'll be on vacation next week 20:59:29 russellb: oscon, 20:59:32 and will not be on computers 20:59:34 * annegentle also around for the meeting, not oscon 20:59:39 nova midcycle next week so I'll be on MN instead 20:59:47 mordred: I tried that today, didn't work out well 20:59:47 aye 20:59:52 I'll be there 21:00:03