20:02:24 #startmeeting tc 20:02:24 o/ 20:02:24 Meeting started Tue Jul 30 20:02:24 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:27 The meeting name has been set to 'tc' 20:02:44 Agenda for today is at: 20:02:48 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:57 do we have Rob Hisrschfeld around ? 20:03:01 -s 20:03:24 ok, let's start with devstack then 20:03:42 o/ 20:03:48 (Rob told me he would be present only the first 30min so we might switch to him if he appears 20:03:50 ) 20:03:54 #topic New program application: Devstack 20:04:01 #link http://lists.openstack.org/pipermail/openstack-dev/2013-July/011896.html 20:04:06 (1) Scope, mission statement, how "essential" the effort is to OpenStack 20:04:14 So this is mostly an oversight when we set up the original list of already-accepted programs 20:04:24 Devstack was an official project in the old taxonomy, so there is no question of it being official/essential or not 20:04:34 The question was more in the scope, should it land in QA, Infra, or in its own program 20:04:46 Personally, since the core people caring about devstack are a separate set of the people caring for Infra or QA, it makes sense as a separate program 20:04:55 I agree 20:05:00 is it really a separate group? 20:05:07 I see it as a developer tool, would like the mission statement to say something about that 20:05:15 seems like a different group to me 20:05:17 it seems sdague and dtroyer are the main reviewers, and they are both in qa-core 20:05:23 also, again, the fact that we use devstack for infra or qa is an implementation detail. it's not devstack's primary purpose in life 20:05:26 I am? 20:05:26 e.g. would dtroyer identify himself as infra or QA? 20:05:29 russellb: enough for QA and infra not wanting to sheperd it 20:05:34 dtroyer: grenade? 20:05:40 I didn't think I was in either team 20:05:47 ah, right 20:06:00 well 20:06:06 does wearing one hat affect the other? 20:06:10 russellb: in the end if neither program adopts it, that means it's a separate group 20:06:18 I think that answers the "would dean identify himself as QA?" question :) 20:06:18 even if it has people in common 20:06:18 o/ 20:06:19 ttx: yep, guess so 20:06:37 I see it as a developer tool, would like the mission statement to say something about that 20:06:45 I dont' think it's about dean's self-identification - I see it as that ^^ 20:06:49 that's not the mission of qa 20:06:52 and it's not the mission of infra 20:06:54 current mission statement is: 20:06:56 oh, it does say that 20:06:58 "To provide an installation of OpenStack from git repository master, or specific branches, suitable for development and operational testing. It also attempts to document the process and provide examples of command line usage." 20:07:03 yeah, sorry 20:07:08 missed "suitable for development" 20:07:09 markmc: does that work for you ? 20:07:12 yep 20:07:46 More comments/questions on the Scope, mission statement part ? 20:08:19 * mordred thinks dtroyer is great 20:08:32 (2) Team/effort/community maturity 20:08:42 That effort is pretty mature by now. It's even almost in stable mode :) 20:09:01 definitely 20:09:10 dtroyer: is there more to do rather than maintain it ? Any short-term / mid-term objectives for the devstack "program" ? 20:09:26 At this point it's a bit of a catch-all project with a lot of pass-by contributors 20:10:04 The bulk of the work right now is making it all fit together but there is a lot of room for improvement 20:10:23 mostly incremental though, no plans for radical changes 20:10:28 dtroyer: and constant work to integrate more projects, i suppose 20:11:08 Comments / Questions on the Team/effort/community maturity aspect ? 20:11:12 right. a lot of that work comes out of the projects though as they know how their code should run 20:12:03 OK, ready to vote ? 20:12:22 yup 20:12:25 Sure 20:12:25 #vote yes 20:12:29 tss 20:12:32 wait for the signal 20:12:37 #vote ok 20:12:43 #vote lol 20:12:47 #startvote Accept Devstack as an official OpenStack program? yes, no, abstain 20:12:48 Begin voting on: Accept Devstack as an official OpenStack program? Valid vote options are yes, no, abstain. 20:12:49 Vote using '#vote OPTION'. Only your last vote counts. 20:12:49 #vote yes 20:12:50 #vote yes 20:12:52 #vote yes 20:12:54 #vote yes 20:12:56 #vote yes 20:12:56 #vote yes 20:12:57 #vote yes 20:12:58 #vote yes 20:12:58 * markwash votes for two 20:12:58 #vote yes 20:13:00 #vote yes 20:13:01 #vote yes 20:13:12 markwash: you need to switch nicks before voting a second time. 20:13:35 ttx: we can probably just let this one slide 20:13:39 yeah 20:13:45 #vote yes 20:13:45 30 more seconds 20:14:11 #endvote 20:14:12 Voted on "Accept Devstack as an official OpenStack program?" Results are 20:14:14 yes (12): markmc, ttx, galstrom, shardy, jd__, russellb, jgriffith, mikal, mordred, gabrielhurley, markwash, markmcclain 20:14:16 So that's a yes. 20:14:28 Thanks all...I promise not to rewrite it all in Go. 20:14:30 dtroyer: congrats. Not that it changes anything, but congrats still. 20:14:36 dtroyer: haha! 20:14:42 dtroyer: right, I missed that question. 20:14:45 dtroyer: oh. wait. I thought you were going to do the opposite 20:14:49 wait, did we just approve a non-python project? 20:14:52 wut?!? 20:15:01 indeed 20:15:03 markmc: my friend - infra has several java repos... 20:15:11 ssshhhh. 20:15:12 mordred, burn! 20:15:14 #topic Open discussion 20:15:23 First thing I wanted to mention, I submitted a "Meet the Technical Committee" panel session for the next OpenStack Summit 20:15:30 The idea being to explain what the TC does, our recent changes and decisions, and field questions from the audience 20:15:32 mordred: you better hope the board don't make you use the common python API code for all that... 20:15:43 We don't really know who will be in the TC by then, some people will probably not be available at the time it's scheduled (if it's accepted), and we don't really need EVERYONE to be present... 20:15:51 but I wanted to give you an early heads-up in any case 20:15:58 gabrielhurley: I'll implement it as a plugin 20:16:02 lol 20:16:16 & "plug-in" 20:16:17 ttx: I'll be there - I have no idea if I'll still be TC - but I'll be there 20:16:31 mordred: trying to crash ALL the panels ? 20:16:33 ttx: +1, the "meet the core devs" sessions are always useful and well-attended at other open source conferences. 20:16:39 ttx, sounds like a good idea (the TC panel thing) 20:16:48 The other thing I wanted to mention is that some of us mentioned the idea of considering non-voting tempest integration as a prerequisite before graduation from incubation 20:16:57 Historically we asked projects to set up QA/gating/tempest integration in the first months after graduation... 20:16:57 gabrielhurley: should we have a meet the core devs session at the summit then? 20:17:03 ttx: ++ 20:17:08 But in some cases that came back to bite us as other priorities tend to interfere 20:17:10 I would very much like to have this be a real thing 20:17:19 If we take that stance, it should be communicated. Trove might find it difficult to set up such thing in the time left before the end-of-cycle graduation review (end of August) 20:17:22 mikal: that's called "the entire summit". just getting the TC together and answering questions is good enough. 20:17:30 graduation from incubation should have as a requirement demonstrable non-voting gate jobs 20:17:33 that work 20:17:41 tempest requirement sounds reasonable ... but there's some minimal bar of test coverage too 20:17:51 not just "a single tempest test to ping the API endpoint" 20:18:04 nope. it should make us say "yes, when we turn that on as a gate, it will matter" 20:18:13 and have been running long enough that it doesn't seem flaky 20:18:16 markmc: sure, we always had that test coverage question... askign that they set up some CI gate is new though 20:18:32 gabrielhurley: well, we discourage conference attendees from coming to design summit sessions now, so that's not entirely true 20:18:35 the CI gate has to test something though 20:18:35 thing is - one of the things they get out of incubation is that infra will talk to them 20:18:53 mikal: damn. you've got me there... propose it if you like. ::shrug:: 20:18:54 so I'd see that they should make use of that during their incubation 20:18:55 It /MIGHT/ make Trove fail graduation if they can't make it happen in the remaining time. 20:19:05 hub_cap: fair warning ^ 20:19:15 mordred, what, at a minimum, should the gate for a new project test? 20:19:20 oh im watching 20:19:20 thx ttx 20:19:23 but i do have a Q 20:19:32 how come im alerted to this < 2mo in 20:19:39 markmc: I don't know - I think quality of the gate might need to be ajugdgement call from us for a bit 20:19:41 hub_cap: given that you're the first project to be held to that standard, feel free to raise questions 20:19:43 and required :) cant it be for /new/ projects? 20:19:58 mordred, right - we need to give fair warning that it's not just a single API ping test 20:19:58 i feel it'd be fair if i knew it from teh start, since heat integration was my requirement 20:20:25 hub_cap: to be fair - you DO have a devstack-based integration gating test right now - so I betcha a single person could get that transitioned to the devstack gate if they were motivated 20:20:28 but it's a fair question 20:20:37 im _totally_ interested in tempest, and its #2 on the list of things for me to do 20:20:45 but heat being #1 i dont want to skimp on it :) 20:21:37 I'm fine with not adding the hard requirement this cycle - especially because I know that trove does have testing automation based on devstack-gate already 20:21:39 sure mordred but motivated != pressured ;) 20:21:48 but I do want it to be a thing that we consider important 20:21:58 +1 mordred as soon as im done w/ heat integration im doing it 20:22:00 hub_cap: it's a bit unfair to sump the requirement after so many months of incubation, yes 20:22:06 heh ttx 20:22:06 devananda: ^^ also, this may or may not apply to you too 20:22:23 we are diligently trying to get out of incubation this cycle fwiw 20:22:49 I'm fine with considering a good work in progress sufficient in the Trove case, if we have insurance it's really top priority for the team 20:22:51 err, graduate incubation ;) 20:23:04 ttx: guaranteed its my prio after heat integration 20:23:11 mordred, others: thoughts ? 20:23:12 im not a fan of having tests that are different from the community 20:23:36 but we have tests :) and a ton of em 20:24:05 Next on the open discussion we have Trove scope expansion to NRDB. It was raised a bit late to be formally considered by the TC, but we can still discuss it 20:24:12 yea i figured ttx 20:24:21 id be happy to start the discusion now and finish it next wk 20:24:42 annegentle wanted to make sure her mission statement was ok, too, before she runs with it 20:24:51 ok /me waits 20:25:00 heh, a schedule for the open discussion :) 20:25:06 lol 20:25:06 agenda, rather 20:25:21 "open discussion" just means "in parallel" for me :) 20:25:28 ok then ill go! 20:26:16 hub_cap: go for it 20:26:19 so our redis POC makes no changes to the core api+core infrastructure. its just another _impl_. there are 2 extensions that are tied a bit to the guest impl but the redis guys are making those extensions in the guest as well. the guest already has a notion of 'im service X', so it can pretty easily get extensions from the codebase as well 20:26:39 and the /clusters api will also have 'cluster flavors' as we call it 20:27:04 so if you upgrade your redis instance, you will have a list of avail flavors so to speak, to upgrade to (not many for redis, mysql has many more) 20:27:12 hub_cap, is the POC code posted anywhere? 20:27:27 markmc: sooooo it is, pre rename 20:27:32 let me push it into the codebase 20:27:38 or at least put up a WIP review 20:27:45 im sick as a dog today but ill rip it out tomorrow 20:27:48 put up a WIP review I think would be great 20:27:54 it'd be great to do that, fire a mail to openstack-dev and let folks take a look 20:27:55 roger 20:28:06 * markmc doesn't have much of an opinion 20:28:07 absolutely. ill reply to the email i sent 20:28:19 i like your opinion markmc :) 20:28:19 anything else hub_cap could do in preparation for next week's decision ? 20:28:28 but maybe there's someone out there who has started working on something like this and has good insights 20:28:30 so - my concern is 20:28:36 :o 20:28:56 what do we do if now trove has mysql + redis + cassandra + mongodb + bearddb 20:29:06 and we end up with the virt-layer problem in nova 20:29:08 +1 to bearddb 20:29:18 of not-well-tested backends or backends that are abandoned 20:29:20 well mordred i wont accept any impl w/o sufficient tests 20:29:28 and i will deprecate / remove them if they are not used 20:29:35 i dont like bitrot 20:29:57 but are you going to expect the infra to test all the different backend combos? 20:30:00 mordred: i'm moving to requiring public CI for all of them by the release of Icehouse (even if it's third party testing, as long as results are public) 20:30:12 russellb: ++ 20:30:12 +1 russellb ill do the same 20:30:18 i'd like to see a similar requirement everywhere 20:30:24 yeah. I could totally live with that 20:30:24 well mordred ill fire up clusters, mysql or _blah_ 20:30:28 i know jgriffith is wanting to do something along those lines as well, based on recent ML posts 20:30:30 this sounds vaguely familiar :) 20:30:35 jgriffith: :-) 20:30:42 heh 20:30:43 my main concern was explosive backends 20:30:46 I think it's a natural progression 20:30:47 hrm 20:30:49 dirty 20:31:00 * mordred looks away in shame 20:31:04 mordred: ha!!! 20:31:11 >_< 20:31:17 -_- 20:31:26 :D i liked it 20:31:28 *snort* 20:31:33 * hub_cap channels my inner markwash 20:31:37 lol 20:31:44 * markwash lold 20:31:48 I think coffee just came out my nose 20:32:02 so, mordred given that i wont allow code w/o sufficient tests 20:32:05 which is still better than what happened to mordred 20:32:06 tempest tests, since they are new 20:32:26 and that ill work w/ you to make sure that your infinite cloud resources are not wasted :P 20:32:50 fwiw, we will be doign the same testing w/ mysql, for clusters.. so, i think its a natural progression. and cluster testing will be in tempest as well 20:33:36 and we could say the same w/ RDB systems, im sure we could impl a ton of those as well and end up w/ teh same issues 20:33:51 clustered sqlite anyone? 20:34:03 * hub_cap assumes its not really possible ;) 20:34:25 oh god 20:34:29 ok, any more questions on trove nrdb ? More next week about this anyway 20:34:45 yes ttx. ill have the POC shot to the ML tomorrow 20:34:50 for your perusing 20:34:52 annegentle: want to raise your program description, or the consequences of it ? 20:35:14 me annegentle? 20:35:25 ttx: I'll just point out the summary 20:35:39 Since we cannot govern all documentation equally with the resources available, our focus is core first and users first… 20:35:53 oh sry ttx... i thought annegentle said that to me, the fever is getting the best of me 20:36:10 oh dear :) 20:36:15 annegentle: I think prioritization is fair. 20:36:58 I think I'll be shaping and honing further as we work on release documents, but I think that we'll continuously publish all the time. 20:37:42 it's just that continuous release doesn't mean "all the documented procedures all the time" 20:37:47 annegentle: I still think if someone wants to work on some integrated project and document that, he should still be able to do so within the docs team 20:38:01 ttx: absolutely, we'll coach and assist as much as possible 20:38:02 but mentioning priorities sounds good to me 20:38:40 comments on that ? Can annegnetly run with her program description ? 20:38:45 annegentle, even 20:38:48 can I run gently? :) 20:38:52 gently. 20:39:05 I believe perfection is the enemy of good. 20:39:17 * markwash thinks you should /nick annerunsgently 20:39:33 I'm ok with focussing on core and users 20:39:45 so we will continuously improve to collaborate wider, and we've gotten many more contributors even in the last three months 20:40:15 I'd be a little wary of using "core" as the basis for prioritization, but absolutely some projects should be prioritized over others 20:40:15 heh 20:40:35 markmc: as long as it's not exclusive, i don't mind so much 20:40:36 I guess I pretty much trust the docs people to know the correct prioritization 20:40:45 *nod* 20:41:05 e.g. "what users care most about" 20:41:26 markmc: yeah and I specifically took the user committee's definitions of users 20:41:27 agree that documenting ceilometer is less important than documenting heat, for example 20:41:41 ttx: the great thing is, ceilometer has a great dev doc site 20:42:05 heh 20:42:22 Last thing I had on the agenda, although it's a bit emply if Rob is not around, is the Spider "what is core" thing 20:42:29 "empty" 20:42:38 so, on the "what is core" thing 20:42:49 I feel like the conversation has progressed on into the far distance 20:43:01 and I'm still stuck back trying to figure out what problem we're addressing 20:43:19 e.g. I thought it was about using the trademark as a lever to ensure compatibility between public clouds 20:43:28 and help form a market place of public clouds 20:43:38 yet, rob's "why we care about core" blog: 20:43:39 http://robhirschfeld.com/2013/07/22/making-openstack-meaningful/ 20:43:47 doesn't mention any of that 20:43:56 markmc: so I'm not sure it makes any progress to solve the question of inclusive vs. limited number of projects 20:43:57 it's all about ensuring we have a healthy project or something 20:44:03 this is just occurring to me now, really 20:44:22 some people apparently think that interop is easier if you limit the number of projects 20:44:27 I'm just curious what other TC members make of the discussion 20:44:28 I kinda think the opposite 20:44:41 It's kind of all over the board IMO 20:44:58 if we let every "openstack cloud" implement their own version of designate... we lose in interop 20:44:59 markmc: My opinion was intially a better/tighter definition of OpenStack 20:45:04 markmc: I think public cloud interop is important, but I'm not convinced that a big trademark hammer is the way to do it 20:45:05 but I don't think that's the direction any longer 20:45:13 markmc: but I don't have an alternate proposal either 20:45:20 I'm with jgriffith: everyone want's a different problem addressed. We're no longer trying to achieve any one thing with it (if we ever were). 20:45:31 markmc: +1 let's reaffirm the problem statement 20:45:38 if we say "an openstack cloud must have DNSaaS and it must be Designate" then the end result is more interoperable 20:46:17 I think the tradeoff is between "a lot of openstack clouds, somehow interoperable" and " a few very interoperable openstack clouds" 20:46:23 yes 20:46:25 but like 20:46:29 what does e..g "Velocity – the rate of progress and quality of the code base. " 20:46:36 or "Culture – open source culture strongly encourages sharing and collaboration." 20:46:41 have to do with any of this? 20:46:49 markmc: the stuff that rob is collecting and putting together 20:46:58 markmc: I can't speak for Rob but I had some conversations about that unrelated to the interop question 20:47:08 is it kosher for me to jump into the conversation since I am not on the TC? 20:47:13 are supposed to be basis for discussion and not the definitoin of it 20:47:15 AlanClark: please do 20:47:27 markmc: where is that ? 20:47:27 thanks 20:47:27 this is all open sores and stuff in here 20:47:28 markmc: we talked a bit about how to keep components like Nova, Neutron etc focused and continuing to get better 20:47:35 I'd also like to point out that ""an openstack cloud must have DNSaaS and it must be Designate" then the end result is more interoperable" is not actually true. How often do you try to make the existing OS services talk to themselves across clouds? 20:47:38 with the explosion of *other* things being introduced 20:47:50 markmc: I've been looking at http://robhirschfeld.com/2013/07/24/what-is-core-strawman/ and it doesn't mention velocity or culture 20:47:51 I'd argue that competing implementations of the same standard improves interop 20:48:13 gabrielhurley: interesting point, which makes me suggest we need to define better the *what* 20:48:13 ttx, http://robhirschfeld.com/2013/07/22/making-openstack-meaningful/ is framed as "why core is important" 20:48:14 gabrielhurley: well, that's one of the things that we keep coming back to - we are not a standards body 20:48:23 ttx, from http://robhirschfeld.com/2013/07/22/kicking-off-core/ 20:48:25 we don't know what we are 20:48:25 we are and always have been, a body where implementation is the definition 20:48:27 gabrielhurley: we are trying to do exactly that with heat in standalone mode 20:48:27 we do 20:48:32 gabrielhurley: +10000 20:48:33 know that we are not a standards body 20:48:37 markmc: I skipped that one and jumped directly to the strawman 20:48:38 says who? 20:48:48 we've said that strongly since day one 20:48:51 there's a lot of language in what Rob sent out that borders on being a standards body 20:48:56 at no point have we ever said differnetly 20:49:01 well, we'll fix that 20:49:11 that's why the focus on running the code 20:49:13 ttx, I'm note sure the strawman details the problem being addressed either 20:49:14 and not just being api compat 20:49:20 if all you need is api compat to be openstack 20:49:28 then we're a standards body - just a poorly organized one 20:49:34 mordred: that's why *you* focus on running the code... there are still a lot of folks in the community who are more concerned with API specs. 20:49:35 but we're not - we ship software 20:49:50 absolutely. api specs are important 20:49:58 and I gotta well you - when clouds diverge we all lose 20:50:09 agreed on that 20:50:18 but I'm not interested in specs that are there to allow some jackass to go rewrite openstack in java because he just doesn't like python 20:50:18 personally I have 3 gripes with the thing: (1) the use of "plug-in" term (solved), (2) it doesn't address the hard question of inclusive vs. limited approach, and (3) it relies a lot on tempest testing which will not just happen by magic 20:50:23 that could be a song 20:50:26 becuse that doesn't help anyone 20:50:42 mordred: I agree with that, but I think there's a spot in the middle 20:50:49 jgriffith: I agree with you :) 20:51:10 I just think that we have to have code - if all we have is a spec, then we're not very interesting 20:51:33 ttx: it's not intended to address 2 20:51:35 mordred: you'd rather cling to python than accept some jackass' rewrite even if it's better, faster, and more reliable? (hypothetically speaking) 20:52:00 gabrielhurley: if the TC decides that the jackass rewrite is better and that we should switch to it, then fine 20:52:12 but until then, whatever that thing is, it's not openstack 20:52:15 mordred: that's not really how consensus evolves :-) 20:52:22 I'm not arguing for not having code, I just don't want to us to write bylaws that specify coding practices or languages 20:52:35 is that not already implicit? 20:52:36 I also do not want that - and don't want to imply that 20:52:37 :P 20:52:52 but I think that openstack is quite specifically the output of those of us who form openstack 20:52:59 No offense but aren't we getting a bit sideways on this? 20:53:04 yep 20:53:06 heh 20:53:07 and yep 20:53:12 jgriffith, aresways is the precise term 20:53:19 heh, typo 20:53:20 markmc: haha 20:53:22 sad, failed joke 20:53:31 ttx: it's intended to provide framing for 2 20:53:32 intent was received :) 20:53:54 markwash: at the heart of the project is a community of developers. You won't turn them into Java devs overnight 20:53:55 with the idea that, like judgements about technical things, there's always going to be judgement calls to be made, and you can't just constitution a defition up 20:54:01 soooo... we should refine/restate the problem definition and then cut everything from the "what is core" document that's not addressing that problem? 20:54:19 gabrielhurley: might be a good way to start 20:54:22 markwash: so I'm with lordred on that one, whatever that thing is, it's not openstack 20:54:31 I think that the point of the document is still being very poorly communicated 20:54:35 lordred... he's been upgraded 20:54:40 whos trying to make people into java devs? 20:54:59 markwash: mordred: you'd rather cling to python than accept some jackass' rewrite even if it's better, faster, and more reliable? (hypothetically speaking) 20:55:08 gabrielhurley: ++ 20:55:10 I just think reboots are healthy and it looks like a cohesive community would never do them 20:55:25 ttx: mordred gabrielhurley so last spring we started having this disucssion among the TC IIRC (what is core) and punted it to the board 20:55:36 IIRC we were trying to think about "what is OpenStack" 20:55:40 that ^^^. it's not something you should be proscriptive against. just trust that if you do the right thing you won't ever need to. 20:55:40 so we punted 20:55:42 I was happy to punt 20:55:49 this document is an attempt to collect all of the various fibers that are running around this topic 20:55:54 it turns out that there are MANY 20:56:00 too many 20:56:03 ttx: yes, now I remember why we did so :) 20:56:03 as the basis to frame a real discussion 20:56:04 way too many 20:56:05 is this discussion purely about using the trademark to ensuring interoperability clouds which call themselves OpenStack? 20:56:09 jgriffith: I think we should keep it punted 20:56:11 it's not intended to be a definition of core 20:56:13 jgriffith: 20:56:25 ttx: I'm mixed, only because I'd like some false sense of my destiny :) 20:56:27 and just make sure they don't insert tech language in wahetever they come up with 20:56:29 also, I think the word core needs to diaf 20:56:32 it's become useless 20:56:42 ttx: that may be the best approach 20:56:55 mordred, we should call this discussion "how our trademark program for public clouds should work" 20:57:00 mordred: (or lordred, whatevs) what's diaf? 20:57:03 ttx: I don't think we necessarily have the same perspective/interests 20:57:09 anneisgentle: 'die in a fire' 20:57:10 fire fire fire 20:57:11 die in a fire 20:57:11 ttx: ^^ I mean TC versus board 20:57:15