20:01:55 #startmeeting tc 20:01:56 Meeting started Tue Jan 5 20:01:55 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:00 The meeting name has been set to 'tc' 20:02:02 Hi everyone! 20:02:04 o/ 20:02:07 Happy new year! 20:02:10 hi 20:02:11 ttx: o/ 20:02:14 Our agenda for today: 20:02:14 happy new year, indeed 20:02:19 o/ 20:02:19 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:25 * dims lurks 20:02:30 #topic Resolution about Image Uploads and Linux Kernels 20:02:36 #link https://review.openstack.org/#/c/256438/ 20:02:41 This is getting pretty close 20:02:44 there is a good feedback from russelb 20:02:53 I was waiting for any additoinal feedback before revving again 20:02:55 yeah I think we should add Russell's paragraph 20:02:55 o/ 20:02:57 there is indeed 20:03:00 would prefer that tweak, but happy otherwise 20:03:16 ++ 20:03:17 cool. if nobody else has anyting else, I'll rev and have it ready for next week 20:03:20 better include it and have a new vote round and see how far we end up 20:03:26 ++ 20:03:43 +1 on the tweak 20:03:43 if you inline edit it we can even vote on it in this meeting 20:03:49 oh. weird 20:03:53 that's super fancy 20:03:56 SUPER fancy 20:04:04 not sure that you *have* to inline edit to be able to vote in meeting, but yes :-p 20:04:16 * dhellmann makes the mind blown gesture 20:04:32 * ttx tried that earlier today, lots fun 20:04:35 * devananda lurks as well 20:04:44 i tried inline edit once, screwed it up. :( 20:05:12 mordred: if you submit a new rev while the meeting is still going, let us know and we'll revote 20:05:19 don't forget to save your file then save the edit then publish the edit 20:05:27 I inlined edited 20:05:31 and click OK then save 20:05:35 * mordred feels very hipster 20:05:45 feels almost like github 20:06:02 not enough emoji for that 20:06:04 Update from Monty Taylor Show Ignore 20:06:04 * prometheanfire has trust issues 20:06:10 hmm; tough choices 20:06:29 +1 20:06:33 (to the update) 20:06:44 is there a hotkey for review in the new gerrit ? 20:06:48 'a' 20:06:49 what 'r' used to be? 20:06:52 russellb: thanks 20:06:55 np 20:06:55 Nice work mordred 20:06:58 \o/ 20:07:13 * dhellmann looks for "a" in the words "review" or "reply" 20:07:14 ok one more 20:07:14 that's 6 ... 20:07:19 dhellmann: yeah, no idea 20:07:28 dhellmann: i have it as "append" in my head 20:07:33 which only kind of barely makes sense 20:07:37 and we have a winner 20:07:47 russellb : "a review"? :-) 20:07:51 approved 20:07:52 heh, that works too 20:08:35 'add review'? 20:08:45 I've been thinking "answer" 20:08:54 don't know why 20:08:56 autobots transform ? 20:08:58 russellb, mordred: I suppose you will push that to appropriate board corners ? 20:09:04 * jeblair just hits alt-2 20:09:18 I gave up on google key shortcuts making sense a while ago with the gmail ones 20:09:22 ttx: I think I saw hogepodge representing defcore lurking already 20:09:24 hogepodge is here on behalf of defcore 20:09:27 so that's a first step :) 20:09:34 get the feedback to that committee 20:09:34 ok good 20:09:35 so done! 20:09:38 #topic Add The Four Opens 20:09:39 markvoelker: is here also 20:09:45 hogepodge: thanks for coming 20:09:48 #link https://review.openstack.org/256439 20:09:49 and markmcclain 20:09:50 I have not yet done ttx's edit 20:09:53 err markvoelker 20:09:59 This one looks good to go, with the dependent patch from Doug 20:09:59 but I think it's a good idea 20:10:06 * markvoelker has duly noted it 20:10:10 The version from the project team guide was a bit refactored, but I'll propose it as a followup 20:10:15 ttx: well, I have a -1 on it 20:10:22 ah hm recent one 20:10:23 ttx: basically the exact same thing as the edit on the prior patch 20:10:35 * purp_too catches up while lurking 20:10:44 yah - I was trying to not re-wordsmith this 20:10:54 it was really about moving the wiki content to the governance repo 20:10:55 if we're making it more official 20:10:57 I think we need to 20:11:03 because well, its more official 20:11:21 it was already pretty official *shrug* 20:11:25 it gets linked all the time 20:11:25 lifeless: I think we can import the current version and push changes as subsequent edits 20:11:35 +1 to that 20:11:42 I'm comfortable with the wording as it is 20:11:49 same reason I'll push my refactoring from the Project Team Guide as a follow-up too 20:12:07 mordred is just importing the current one from the wiki 20:12:16 Makes sense to me 20:12:19 yeh, this seems fine to me 20:13:11 I tend to agree that we could reword that paragraph, but I think we can bikeshed this one quite a bit and wouldn't like to hold the import too long 20:13:21 honestly, there are times for being more explicit and shoe banging to get the spirit across 20:13:30 I'm fine that this has that tone 20:13:37 and as russellb said, the current version is still "official" until we approve this one 20:13:46 we have had to be VERY explicit on the open core topic several times in the past 20:13:47 so not worse 20:13:55 including once with me yelling in a board meeting 20:14:07 if there was more of that previously, we wouldn't have had to spend so much time on the bring your own kernel issue 20:14:11 it's a "give an inch and they'll take a mile" topic 20:14:32 +1 20:14:38 mordred: so, I'd like to see that statement from the board too then! (Amd I can't think of a better person to make that happen :)) 20:14:38 I also think it's fine to take this stance as a technical position, which is well within our purview 20:15:07 russellb: perhaps we should propose something at a board meeting to get the board to also say the same thing? 20:15:15 so I'm fine taking the majority votes we already have and merging this now, taking lifeless concern to a subsequent change 20:15:23 it's important for us to take a stance on, actually, because it has large implications on project scope 20:15:26 lifeless: does that work for you ? 20:15:36 jbryce: ^^ would love some feedback at some point about how such a thing might look from the board side 20:15:39 mordred: sure, not sure what form that would take ... 20:15:44 ttx: my only concern is being respectful to the boundaries between tc and board 20:15:47 but generally +1 20:15:54 I *totally* agree with the thing itself. 20:16:12 kinda funny, the red hat product has enterprise in the name :-) 20:16:16 lifeless: I get it -- consider this version to be the import of the current situation and a base for subsequent changes 20:16:22 we won't turn down contributions because they might endanger any of the open core strategies other folk are building around openstack 20:16:27 we could tweak working later though, i'm not worried 20:16:30 lifeless: that is true 20:17:00 lifeless: and we also don't prevent people from having those strategies 20:17:02 I'd rather review the change separately from the import 20:17:08 mordred: right. Sadly. 20:17:27 makes it clearer what changes and why 20:17:41 ttx: sure 20:17:46 not really in the spirit of our licensing to prevent it, either ... i look at it as more that we don't want to artificially limit scope 20:17:55 ttx: my concerns are being actioned by russellb and mordred now, so I happy :) 20:17:56 we will not accept contributions that only exist to facilitate them 20:18:07 ok, then I'll approve this now based on current approvals 20:18:07 jeblair: ++ 20:18:30 approved 20:18:48 looking forward to the discussion on watering down the language there (or not) 20:18:52 we're efficient in this new year 20:19:01 #topic Remove containers from Nova's mission 20:19:04 Moar fun 20:19:06 SOOOOOO 20:19:06 all kinds of agreeing 20:19:07 russellb: was just noticing that. =] 20:19:09 #link https://review.openstack.org/256440 20:19:13 there's tons of good feedback on this one 20:19:13 The discussion is still ongoing on this one 20:19:24 Most seem to agree that containers are a second-class citizen in Nova, so the mission could omit them 20:19:28 which has made me want to circle back around and try to express the intent before hacking on wording 20:19:30 BUT most seem also to agree that support for containers should stay in Nova 20:19:34 yah 20:19:39 So the discussion is now around what changing the mission would actually result in. 20:19:42 I don't think I ever wanted to suggest deleting them 20:19:50 it's pluggable, you can do whatever 20:20:11 just not the primary intent of the API 20:20:29 but making it clear that nova's purpose in life is not to be a docker/kube competing container management/orchestration system, but rather a system that shines as infrastructure on which to run things like kube and swarm 20:20:32 making it a primary target implies lots of stuff that could/should be done, so makes sense to change it to me 20:20:39 russellb: exactly 20:20:44 ++ 20:20:53 I do not believe what is currently written in this expresses that clearly 20:21:05 mordred: ++ to what you're saying there 20:21:11 nice to see all the good feedback 20:21:32 and to the concern in the comments, I think if we do it _right_ it's a positive message to the container ecosystem, not a "openstack doesn't care about containers" 20:21:39 mordred: agree that putting containers on the same level as VM in the current mission was a bit misleading 20:21:41 on a procedural note, how do we get the nova team to sign off on the change, since they're not pushing it? 20:21:49 dhellmann: ptl +1 20:21:54 dhellmann: ask them ? 20:21:59 although in theory we can just push it 20:22:07 well, there is a lot of nova core feedback on the change already 20:22:12 I think getting nova ptl happy is important 20:22:14 I'd rather have them agree with the mission they have :) 20:22:17 ++ 20:22:18 sdague : enough, though? 20:22:23 dhellmann: it's mostly negative 20:22:36 i think the “run a kernel/image/look like a server” delineation coming from the earlier position around defcore is really important. containers can sometimes look like a server—a unit of infrastructure—but more and more are used as the application unit vs an infrastructure unit and i think that kind of usage is what fits poorly with nova 20:22:48 sdague : how many nova core +1 do we need to feel comfortable that the team has had a chance to consider the change? 20:22:51 jbryce: ++ 20:22:54 mordred: no, I jbryce ++ 20:22:59 sdague , ttx: I don't think the ptl is enough 20:23:01 dhellmann: i'd say leave that to the PTL to ensure before he signs off 20:23:02 woops. typo 20:23:03 I don't really see a consensus on removing that 20:23:13 meaning, trust the PTL to gather the team's consensus 20:23:43 russellb ++ 20:23:49 right, so what about just truncating the mission statement 20:23:57 To implement services and associated libraries to provide massively scalable, on demand, self service access to compute resources. 20:24:03 treating containers in ways that look like a server makes some sense under the nova api and i think people will continue to have some use cases for that. treating a container in the way that kubernetes does for instance makes no sense in nova land to me 20:24:11 and stop calling out the tech 20:24:13 jbryce: agreed 20:24:24 sdague: i think “compute resource” is not quite specific enough, thought, and leads to some of the confusion 20:24:29 sdague: FWIW, I think calling out the specific layer is important 20:24:35 jbryce: agreed 20:24:36 yeah, i think some more detail is useful here 20:24:44 sdague: a kubernetes container construct is about a differently abstracted type of compute resource 20:24:52 TBH, I don't really want baremetal to be in the scope as stated 20:24:53 sure, and I don't disagree with that 20:25:04 dansmith: calling out the specific tech is only adding confusion, esp. as the tech (and how its used) changes 20:25:05 hence why i (clunkily) was saying infrastructure unit of compute vs application unit of compute 20:25:21 devananda: well, I disagree :) 20:25:25 don’t know that i have the best terms myself, but when i’ve talked with people about the issue that seems to be where things start to get confusing 20:25:28 dansmith: right. but I think _that_ is a different conversatoin tbh - I was trying to keep this specifically about "things that can run kernels" vs " things that can't" 20:25:39 but I also think that this sentences is the wrong place to slice all that 20:25:42 dansmith: since the bare metal conversation is on murkier lines and needs to also be sorted out 20:25:46 dansmith: unless you think nova should be about virtualization -- and nothing else? 20:25:47 I mean look at the mission statements from other projects 20:25:54 "To implement services and associated libraries to provide on-demand, 20:25:54 scalable, and technology-agnostic network abstraction." 20:26:08 heh, yeah, that's pretty broad 20:26:15 Indeed 20:26:18 mordred: yeah I just would hate someone to expect us to adopt another baremetal driver peer to ironic on the grounds that it's in here. But, agree it can be a different convo 20:26:27 It's an aspiration, not a description 20:26:31 dansmith: I also agree with that - that would be hella yuck 20:26:35 Something to strive for 20:26:42 mission: boil the ocean 20:26:47 heh 20:26:47 the goal, not the status 20:26:50 dansmith: I agree with your concern there too 20:27:07 sdague: I really like your truncated mission statement from above. 20:27:21 mordred: so it looks like you need to have another take at wording and come back another week ? 20:27:28 oh yeah 20:27:31 because I think that what gets done in a project at the end of the day is based on a shared understanding in that project 20:27:46 sdague: it is - BUT - nova is special and important tbh 20:27:53 and then we need to revive the feedback loop from Nova people 20:27:57 sdague: we do have a mission statement in nova itself, so should this just say "do what nova considers to be its mission" ? 20:28:03 in that people outside the project need to understand its boundries more so than with the other projects 20:28:09 and in reality, I think there is a general shared understand in Nova right now that this is mostly about Virt, and some other things that can expose to look at it a bit, when they make sense. 20:28:15 I know that johnthetubaguy is pushing hard for describing feature classification, it would probably help the discussion 20:28:56 bauzas: still, johnthetubaguy has said on that review that he favors things that run a kernel, so I think he's still on board with tightening 20:28:57 I mean, we have some feature capabilities that need to be accepted by drivers, others that would not be fine for some features look not good for Nova mission 20:28:58 bauzas: yeh, that's a long road to get there 20:29:02 thing is - I tihnk this isn't just about the nova team - largely because the nova team thinks it's just about virt - but consumers want a compute api that can give vms and bare metal - so if nova is just a virt layer, we might need to grow a compute consolidation layer that has nova and ironic backends 20:29:21 and I think that's a very big kind of decision 20:29:26 Also not totally sold on this change being a natural consequence of the previous position on byok 20:29:44 dansmith: ++ 20:29:49 ttx: +1 20:29:53 mordred: I think that's somewhat true. I also think people want to sometimes choose a container 20:29:54 mordred: That would be a much larger decision 20:29:54 dansmith: yeah, I agree with that position 20:30:00 mission statements are largely for not-the-team IMO 20:30:01 not coordination thereof, just booting one 20:30:09 they are a coordination and communication thing 20:30:19 It's a welcome clarification on what the priority is, not a natural consequence of byok 20:30:22 mordred: i agree completely 20:30:25 our hypervisor support matrix already provide some way to explain what a nova driver should implement 20:30:48 cdent: I have heard people say tht they've heard people want that, but I haven't experienced many people actually wanting that - as evidenced by how historically nobody has ever cared about the lxc driver that's been there for 6 years 20:30:54 so it seems there are two parallel ways of looking at this: is Nova only about virt (or also baremetal or containers or other tech) vs. is Nova about "computers" or "units of compute" 20:31:31 that comes to a far larger scope 20:31:47 mordred: yeah, I don't expect fat (infra-unit) containers to stay a thing for long 20:31:55 me either 20:31:58 lifeless: Having struggled with how to explain the reasoning for a DefCore decision, I tend to agree ... but they need to be crisp enough to help the team think, too. 20:32:12 as jbryce said earlier, the way many folks use containers does not fit well with Nova as it is today -- and I think that's perfecty fine 20:32:13 purp: certainly, yes. 20:32:24 devananda: ++ 20:32:38 and I think it's worth the TC making a statement about that 20:33:24 I guess I'm not seeing that urgency, personally. We had one confused product team at Oracle that did a thing we didn't like. We've clarified that. 20:33:37 OK, I propose we continue the debate on the review until at least next week. I suspect mordred might push a new rev 20:33:46 sdague: I think that's where I am also. Project team missions are their missions. 20:34:03 I think it's ok that we react to things that people do that we don't like by telling them so 20:34:12 annegentle: +1, and since the TC one currently disagrees with nova's stated one, there should be a fix 20:34:36 not by trying to preemptively imagine all possible failures and protect against them 20:34:45 dansmith: patch the nova repo you mean? 20:34:52 sdague: I agree - it's not urgent. however, I think it is important to start a conversatoin about the vm/baremetal/conatiner intent more broadly than nova-core, becuase I think more than any other team this particular topic is super far-reaching in terms of openstack as awhole 20:34:53 annegentle: no, patch the TC one 20:34:53 I'd also like to see some clarification from the nova team as to whether they view Nova as specific to virtualization technologies, since that has come up a few times in this discussion 20:35:00 dansmith: ah ok then yep 20:35:03 mordred: ++ 20:35:14 annegentle: nova has a documented mission, and if the TC one conflicts, then change the TC one (or loosen to remove the conflict) 20:35:26 this topic has significant implications for workload scheduling across projects 20:35:29 sdague: i can see not requiring a new policy to be adopted, but i think discussing these and working through the issues is actually very valuable 20:35:35 mordred: who are you calling an awhole? 20:35:41 that is one of, if not, my main interest in it right now 20:35:44 dansmith: who am I not? :) 20:35:48 mordred: touche. 20:35:48 dansmith: snort 20:35:54 alright, let's move on 20:36:06 next topic! 20:36:06 if the nova team thinks one thing for the future of openstack, and the tc thinks a different thing - we need to dig in to that and figure out it - so consider this mainly just an opening to the conversation 20:36:08 sdague: I'd argue it's useful to clarify now to lend more guidance/direction so that future folks don't go so far astray. 20:36:14 it's a valuable conversation and needs lots of talk lots of places :) 20:36:18 annegentle: ++ 20:36:24 and a discussion we'll continue soon ! 20:36:30 #topic Cross-project spec rubberstamp: Add clouds.yaml support specification 20:36:31 thanks jbryce for insights also 20:36:32 purp: I will be massively surprised if 1 paragraph in a yaml file prevents people from going astray 20:36:39 #link https://review.openstack.org/#/c/236712 20:36:51 annegentle posted a few questions and asked for clarification, not much answers on this one 20:37:02 after many dozen person to person conversations did not 20:37:02 sdague: True, but it's also the transcripts of these discussions and the review comments that get used as guidance. 20:37:06 mordred: ETOOMANYREVIEWS 20:37:13 ttx: inorite? 20:37:16 Maybe simpler to wait ? 20:37:49 unless you feel you can answer live to Anne 20:37:58 ttx: should I follow up on any of the projects to research their current state? 20:38:14 or maybe mordred knows what to do with them :) 20:38:14 annegentle: new projects should implement cli's as plugins to openstackclient 20:38:35 mordred: yeah, that sounds right to me 20:38:41 annegentle: existing projects ... I'm working on making patches for all of them :) 20:38:58 I mostly wrote this so I wouldn't have to explain why I was writing patches for everyone 100 times 20:39:10 annegentle: so do we need another rev or are you good with that one ? 20:40:01 mordred: I still need a line for "what do newish projects do?" 20:40:08 kk 20:40:10 I'll rev 20:40:16 mordred: thanks 20:40:18 alright, let's push it back 20:40:22 #topic Cross-project spec rubberstamp: Backwards compat for libraries and clients 20:40:27 #link https://review.openstack.org/#/c/226157 20:40:30 yay this one isn't me!!! 20:40:36 heh 20:40:45 arh nothing like a last-minute -1 20:40:52 * ttx reads 20:41:02 \o/ 20:41:05 yeah 20:41:18 mriedem: so, the dependency mgmt spec covered the issues with capping 20:41:29 mriedem: I really don't want to revisit that *again* 20:41:50 mriedem: not when its already a spec, and nothing has changed to make capping better 20:41:51 i don't really have that spec in my head atm 20:42:05 there have been things which have made capping less painful 20:42:10 which i've pointed out several times before 20:42:12 https://specs.openstack.org/openstack/openstack-specs/specs/requirements-management.html 20:42:39 lifeless: if you end up doing another rev, maybe leave the tag details to the tag definition discussion, as I suggested. But don't do a rev just for that 20:43:41 ttx: I think I need to, because release-constraints won't be static - it will change as libraries do point releases 20:44:04 ttx: I didn't add that back in after adding stable branches-stay-a-thing-in post summit discussion, and mriedem noticed (thanks!) 20:44:08 lifeless: ok. Maybe that one was not that ready for rubberstamping after all 20:44:32 let's push it back to the drawing board for a bit ? 20:44:33 ttx: well, it did previously have mriedem 's +1, so who knew :/ 20:44:38 heh 20:44:48 it's the 2016 mriedem 20:44:50 well, it's a big spec, and we were hashing it over again in irc today 20:44:57 i've never been crazy about this honestly 20:45:02 but i've gotten tired of fighting it 20:45:06 yeah, there was a big discussion on IRC today, 20:45:14 which seemed to open a lot of significant concerns 20:45:25 from myself, the stable PTL, and the oslo PTL 20:45:28 mriedem: I think the point we disagree on is whether capping works 20:45:35 so I don't think acting like mriedem is crazy is appropriate here 20:45:45 better now than after we approve the spec :) 20:45:47 dansmith: noone is acting like mriedem is crazy, are they ? 20:45:55 i get that capping sucks, but it's sucked for a reason many times in the past (icehouse and juno are fresh in my mind), and a lot of those reasons have been improved 20:46:00 lifeless: the language used above is kinda rude and not very welcoming to discussion, yeah 20:46:38 dansmith: thanks for letting me know, though I really can't see that. He had voted, we moved to rubber stamp, and then a problem was found (excellent!) and we're discussing it more 20:47:01 I for one welcome the extra discussion. We need to get those things right 20:47:06 dansmith: I kinda feel like you're escalting in the worst possible way what I'm typing on IRC today 20:47:07 i've always thought this was weird from a packaging perspective 20:47:17 TBH, I hadn't had a chance to read this spec before the large discussion today, so I haven't commented on it, 20:47:35 but it seems like there are some implications or procedures that need to get worked out 20:47:35 anyhow, procedure wise, this is not ready for TC rubber-stamp 20:47:56 yes 20:48:05 so lets let the meeting proceed, and folk interested in this can go to openstack-dev probably as the most relevant place, and we can discuss further 20:48:07 We may have to schedule it again for cross-project discussion if necessary 20:48:20 lifeless: agreed 20:48:22 #topic Open discussion 20:48:29 * "Upstream development" track at the Austin OpenStack Summit 20:48:38 Over the holidays came the good news that we'll have an "Upstream development" track at the Austin Summit 20:48:47 It's something I suggested a couple of months ago so that we can clearly have upstream-developer-targeted presentations 20:48:56 without artificially using cross-project workshop space just to raise developer awareness on specific topics 20:49:00 ttx: remind me, which direction is that? 20:49:05 It shall happen on the Monday in Austin, with Design Summit starting on Tuesday 20:49:05 ttx: ah ok 20:49:13 Things I expect to fit in this track are: 20:49:19 general communication about development process changes 20:49:26 new features in a central project that need adoption in other projects 20:49:32 present corner use cases that may need support from development 20:49:39 developer-oriented infra talks 20:49:45 development best practices, lightning talks on cool tricks 20:50:01 things we abused other tracks for in the past, with varying success 20:50:14 I'll need a couple of co-chairs for this track. I suspect everyone is interested, but I only need a few, so only raise your hand if you *really* want to be part of it :) 20:50:36 questions on that ? 20:50:42 i like it :) 20:50:45 that's not a question, though. 20:50:50 russellb: do you like it? 20:50:50 Very good idea (also not a question) 20:50:58 jeblair: i do! thanks for asking! 20:51:08 might be worth a brain storming session on the stuff we'd like to see in there, and rounding up volunteers 20:51:12 (NB: we still have "project updates" as a track for developers to present new features to operators/endusers) 20:51:26 sdague : ++ 20:51:37 sdague: yes, before the deadline 20:51:45 ttx: yep 20:51:53 sdague: I'll take the action of organizing that 20:52:15 #action ttx to set up a brainstorming about what the TC would like to see on the upstream dev track 20:52:27 n00b question: what does a co-chair do to help organize a track? 20:52:31 sdague: I think I'd like to have a lightning talk slot on cool tricks 20:52:42 purp: vote on proposed talks 20:53:01 ttx ... and ... ? 20:53:02 in this case I expect the co-chairs to reflect the consensus from the TC 20:53:13 ttx: can we make sure those are recorded as well? 20:53:13 * purp doesn't believe anything is that simple. ;D 20:53:17 purp: make the final selection in the summit org interface ? 20:53:37 sdague: they should all be 20:53:44 sdague: recording with as well? upstream track or lightning talks? 20:53:50 which* 20:54:09 purp: trust us! :) 20:54:13 jbryce: both I suspect... but everything would have a presentation format and benefit from our crazy AV support 20:54:15 jbryce: upstream track 20:54:21 edleafe: you forget, I *know* you. 20:54:25 =D 20:54:31 upstream track will be recorded by default, lightning talks, may or may not be depending on where they end up 20:54:45 ok, great 20:54:45 jbryce: they would end up in a traditional presentation slot/room 20:54:47 unless you’re saying a lightning talk slot in the upstream track itself 20:54:53 ttx: ahh, then yes 20:55:03 * N/O naming 20:55:07 mordred: I've seen the poll results. Did you already push ordered candidate names to Lauren, or should I ? 20:55:23 I kind of expect Newton to end up encumbered. Olimpic may also be an issue, given the IOC strongarmed enforcement of trademark. We'll see 20:55:23 I have pushed them to lauren/foundation staff 20:55:24