20:02:45 #startmeeting tc 20:02:46 Meeting started Tue May 10 20:02:45 2016 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:47 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:49 * rockyg lurking under the bushes 20:02:49 The meeting name has been set to 'tc' 20:02:50 ooh do we have enough? 20:02:55 Hi everyone! 20:02:56 ttx: oh, sry I guess I didn't raise my hand 20:02:57 morgan: we do 20:02:58 o/ 20:03:01 ttx: okie 20:03:06 Our agenda for today: 20:03:09 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:19 #topic Update management expectations for release tags 20:03:31 #link https://review.openstack.org/308045 20:03:33 * stevemar lurks in the background 20:03:40 This is about adding a few warnings about release models, to help people pick the right ones 20:03:51 We have 7+ votes on this one so I'll approve it now, unless someone wants to discuss those further 20:03:53 o/ 20:04:19 ttx: I was just wondering there are a bunch of projects with tags today that don't meet the new requirements 20:04:32 wait, I don't want to discuss these further. I'm just saying hi :P 20:04:32 like ? 20:04:53 tempest 20:05:16 it doesn't go through the relmgt but it's tagged as one of the cycles ones 20:05:29 there are 2 ways to fix that 20:05:45 yeah, remove the tag or go through relmgt 20:05:49 right 20:06:23 we'll do an audit of the other deliverables and talk to their owners 20:06:30 I just was saying the tags were previously just a cadence thing and now it's more than that. Is it just tempest in this case 20:06:30 should that block the tag change ? 20:06:37 I don't think it should 20:06:37 ok, that's what I was wondering 20:06:40 ttx: nah 20:06:55 release models have always been a catch-up game 20:07:01 I believe I've removed tagging permission for most of these projects already 20:07:09 trying to align the model with project reality 20:07:46 ok, so if it's not an objection but just a side question, I propose we approve it and I #action dhellmann to look into the oddities 20:07:57 dhellmann: you're gonna get actioned 20:07:59 ++ 20:08:06 All for actioning dhellmann 20:08:31 #action dhellmann to look into (or delegate looking into) release model oddities as a result of https://review.openstack.org/308045 20:08:48 and approved 20:08:49 * dhellmann notes that "delegate" and that ttx is also on the release team 20:09:03 yeah, that was my way of half-actioning me 20:09:11 #topic Naming for P & Q 20:09:18 action fractions 20:09:29 Those are 4 reviews clarifying the language in the naming rules so that they continue to work in the future 20:09:37 ...and narrowing the geographic locations for P and Q 20:09:43 * Remove sentence about version numbers (https://review.openstack.org/312127) 20:09:53 * Clarify language around summit to name mapping (https://review.openstack.org/312128) 20:10:01 * mordred wrote patches 20:10:01 * Add naming poll info for P release (https://review.openstack.org/310425) 20:10:09 * Add naming poll info for Q release (https://review.openstack.org/310426) 20:10:16 mordred: want to talk about those ? 20:10:19 sure! 20:10:35 mordred: do you like to talk ? 20:10:35 so when we say "the summit" we're talking about the thing we have now, and not the new gathering thing, correct? 20:10:38 so - 312127 is cleanup. it references an old method of numbering things 20:10:41 dhellmann: yes 20:10:43 dhellmann: yes 20:11:02 k 20:11:37 312128 is an attempt to capture the actual reality as it is now, but also in such a way that the p and q patches don't get caught into a sea of loosely defined words 20:11:38 dhellmann: basically this is picking option 3, as described in my comment on https://review.openstack.org/#/c/310425/ 20:12:23 before we talk about p and q - any concerns/questions/hotdogs on the first two? 20:12:24 the benefit is that it's a single rule which works for the past and the future 20:12:34 ttx: ++ 20:12:36 slight diversion, on the numbering / naming. If the name for the summit and the release are not actually going to quite be the same thing. Have we considered synchronizing the numbers for components. Because which nova, cinder, keystone, barbican are all released together and were potentially tested together is becoming more confusing 20:12:44 whatever the future holds 20:13:05 sdague: I'm confused by your confusion 20:13:10 sdague: can you restate that? 20:13:28 * flaper87 confused by mordred's confusion on sdague's confusion 20:13:36 mordred: tell me what versions of cinder, nova, keystone, neutron, glance were tested together in "mitaka" cycle 20:13:40 ISTM that we'll call it the $name PTG and the $name summit, so I'm not sure they would be different 20:13:42 the name for the release will be the name for the summit happening during its development. 20:13:54 yah. what ttx said 20:13:58 this should not change that 20:14:01 sdague : http://releases.openstack.org/mitaka/index.html 20:14:18 dhellmann: sure, but I bet know one can tell off the top of their head 20:14:41 anyway, it's a diversion, we can move on 20:14:46 * mordred would just grab the stable/mitaka branch of openstack/openstack ... 20:14:48 sdague: that's not really a new issue introduced by this patch though 20:14:49 sdague : probably not. and that will only get worse over time as more projects are added. Does it make sense to add something in Ocata and start numbering it somewhere other than 1? 20:15:02 http://ttx.re/new-versioning.html 20:15:10 June 26, 2015 20:15:19 yeah, this has been an issue since we changed versions in liberty 20:15:21 dhellmann: yeh, I was thinking max(version) 20:15:23 * rockyg agrees with sdague and thinks maybe an inventory of stuff released to gether should be in every project? 20:15:43 maybe we should talk about this separately from the naming? 20:15:43 the releases.o.o website is tracking the version numbers 20:15:45 because, especially log messages in components tend to indicate version numbers which are all unsycned 20:15:45 I think the releases.openstack does have the inventory 20:15:50 Having an inventory is fine, I'm not sure about aligning projects versions 20:16:11 anyway, lets table to a future meeting 20:16:15 ++ 20:16:17 it's a bit orthoginal 20:16:19 ++ table 20:16:29 everything keeps going back to if openstack is a unitary thing, or a collection of disparate parts 20:16:36 cdent: it is a unitary thing 20:16:39 always has been 20:16:43 and that has not changed 20:16:48 alright let me see how many votes we have now 20:17:03 it was decided I think 4 or 5 years ago in a vote of what I think was actually teh TC but might have been the PPB 20:17:07 and to my knowledge nothing has changed that 20:17:20 mordred: except it (individual projects) doesn't seem to act like it a lot of the time… 20:17:23 Looks like we have enough to pass them all now. Objections ? 20:17:26 dtroyer: yes. that is correct 20:17:34 individual projects like to buck the One Project decision 20:18:07 but lacking a decision to the contrary, the existing decision stands and part of our work is working with those projects to remove the disparity 20:18:14 who makes sure projects do release notes? 20:18:27 maybe we should reopen in open discussion? 20:18:29 (also can be tabled, heh) 20:18:31 yeah 20:18:32 I'll take that as a "go ahead, approve" 20:18:39 ++ttx 20:18:45 ttx: go 20:18:47 let's name us some releases 20:18:51 done 20:19:03 #topic Update Magnum Description and Mission 20:19:09 #link https://review.openstack.org/311476 20:19:19 This one is the result of a discussion at the Summit around Magnum's scope 20:19:27 The commit message summarizes the discussion better than I can 20:19:32 ttx: did you approve the P and Q things too? I guess that means I get to go do some work :) 20:19:37 mordred: yes 20:19:46 This will result in a new project team being created to focus on the abstraction API side of things 20:20:00 mordred: looks like they took our suggestion for the name afaict 20:20:16 IMHO the split will really help since those are two different use cases with two different user bases 20:20:32 And confusing the two really hurt the messaging around Magnum in the past 20:20:33 ttx: this *may* result in that -- I don't remember anyone actually volunteering to do that work in the summit session 20:20:43 Aside from the usage of scaling which I guess is addressed, that was my only thought. 20:20:47 I believe the split will help clarifying the goal, which was confusing to many (including me) 20:20:47 dhellmann: I've seen launchpad groups being created 20:20:54 ah, ok 20:21:06 split good in this case. 20:21:22 flaper87 : indeed 20:21:31 hmm, although the name is already taken 20:21:35 anyway 20:21:41 thingee: I honestly think the use of scaling there is fine. It's really about spreading out COEs. 20:21:41 \o/ 20:21:43 ttx what was the name? 20:21:45 Since Hongbin (PTL) pushed the most recent patchset I consider he is OK with the current wording 20:21:48 * mordred has named yet another openstack project 20:21:54 annegentle: Higgins, the butler in Magnum 20:21:59 hee 20:22:10 flaper87: my thought was whether it's COE's themselves, not magnum scaling. 20:22:20 Confirm. I am fine with that 20:22:25 thingee: COEs don't autoscale 20:22:35 they need a lot of help, which Magnum provides 20:22:41 thingee : operators can scale up COE's with COE's cooperation :) 20:22:46 apps deployed on COEs autoscale 20:23:01 (as long as there is enough space on the COE) 20:23:18 ttx : y that too 20:23:29 was still missing a couple of TC members votes last I looked 20:23:31 Questions ? 20:24:01 Looks like we have 9+votes now 20:24:03 dims: I like the "with COE's cooperation" part 20:24:07 ++ 20:24:15 * morgan is waiting for the page to load. 20:24:20 :) 20:24:25 #coffeeshopwifi 20:24:43 * thingee is on the same wifi - it's no good. 20:24:45 ok, approving now 20:25:00 #topic Add golang as an approved language 20:25:06 #link https://review.openstack.org/312267 20:25:19 This one is likely to take a few meetings before we come to a conclusion, especially with the ML thread being in full swing 20:25:20 the thread is *still* active 20:25:23 morgan: I read that as "coffees hop" 20:25:33 The programming language resolution from last year opens the door to supporting new languages in OpenStack official projects 20:25:35 * thingee waits for termie to appear 20:25:37 mordred: that too 20:25:41 #link http://governance.openstack.org/resolutions/20150901-programming-languages.html 20:26:01 It explains that we should weigh the technical benefits for OpenStack (using the best tool for the job) against the community costs (community fragmentation, infra overhead...) 20:26:23 The proposal is that we add Go as a supported language for official OpenStack projects, so that performance-sensitive data-plane pieces of Swift, rewritten in Go, could be merged in mainline code 20:26:35 Designate has similar needs for a DNS server proxy, and would use Go for that if we added it 20:26:49 Before this goes in every direction, I'd like to try to structure the discussion 20:26:49 thingee: perhaps the openstack version of godwin's law sohuld be called "Thingee's Law" and should be "As an online discussion grows longer, the probability of a comparison involving termie approaches 1" 20:27:09 First discuss the perceived community costs, then the technical benefits for OpenStack, and then weigh one against the other 20:27:10 ttx: well, we were going to propose something simlar if swift hadn't 20:27:25 ttx++ 20:27:26 mugsie: I assume we == designate 20:27:31 So... community costs first 20:27:38 flaper87: yeah 20:27:43 Adding any language is a bit costly in community terms, but we should try to estimate and quantify how costly Go is likely to be 20:27:57 First cost is community fragmentation, which was raised by bswartz on the ML 20:28:26 "strongly believe that mixing 2 languages within a project is always the wrong decision, and doubly so if one of those languages is a niche language. The reason is simple: it's hard enough to find programmers who are competent in one language -- finding programmers who know both languages well will be nearly impossible. You'll end up with core reviewers who can't review half of the code and 20:28:28 developers who can only fix bugs in half the code." 20:28:29 mordred: very good - but mostly because he would've wanted us to go this path eventually :) 20:28:33 * bswartz1 lurks 20:28:51 ttx: yeah, I pointed that out on the review as well. I admit this bit worries me. 20:28:59 flaper87: bswartz1: that's definitely a valid concern 20:29:02 we've seen this pain to a degree with python and javascript 20:29:10 I think of all languages we could add Go is not the worse 20:29:12 it's not just theoretical 20:29:16 * amrith mumbles something inaudible about .NET 20:29:25 since there is some decent overlap in communities 20:29:33 * edleafe smacks amrith 20:29:35 * notmyname sees IRC client light up 20:29:36 mordred: and java 20:29:38 (more than between Python and Java or Python and C) 20:29:48 how do we get operators input? packagers? 20:30:04 ttx: ++ on go not being the worst 20:30:06 Eventually, I believe we'll end up with a split community. Not every Go developer is a pthon developer and the other way around. 20:30:07 there have been some people in thread speaking on it's maturity. seems like most of the pain pointsthere were captured in the last infra meeting 20:30:20 well, I mean we've seen the issues in active openstack projects where the project is in two languages - python and javascript being the combo that we have currently 20:30:22 mordred: yeah, I see that issue in openstack-health (granted it's a big example) 20:30:25 wrt to dependnecy management 20:30:29 For JavaScript we basically considered that the fragmentation was a necessary evil -- you can't program a client side web interface in Python 20:30:37 s/it's/it isn't/ 20:30:38 but the fragmentation exists 20:30:41 exactly 20:30:45 ++ 20:30:52 it's not a show-stopper 20:30:55 it's just a thing 20:30:59 and is a real cost 20:31:08 A project like StoryBoard definitely suffered from being coded in Python + Javascript, requires dual expertise to be a core there 20:31:23 we have had projects cope already - "We already had that, for example in Horizon, moving from a mostly Python 20:31:23 oriented community to a mostly JavaScript community." from Matthias 20:31:53 While I understand the difficultly for contributers, was this not raised when allowing other languages was first approved? Once more than 1 language is allowed, especially "server side" projects, the fragmentation is inevitable - is this then a separate discussion around allowing dual languages in a single project vs allowing Go (or ) into OpenStack? 20:32:02 ttx: our community is more than devs, naturally. So I want to hear more technical info on the downstream effects, can you run multiple sourced services when coded in both Go and Python? or is it one or the other? 20:32:08 should be upto the project and cores to take the plunge i think 20:32:13 dims: ++ 20:32:14 Kiall: it's purely a discussion of the community costs currently 20:32:19 dims: That's one of the reason I don't contribute to Horizon. I just don't do JS. 20:32:22 Kiall: I think if the language is really needed, then this outweighs the cost. It's a trade-off 20:32:37 but we should just not underestimate the community fragmentation cost 20:32:38 mordred: Right, but those costs must have been weighed when http://governance.openstack.org/resolutions/20150901-programming-languages.html was approved, no? 20:32:49 annegentle: ++ on packagers and ops feedback needed 20:32:53 does it need a separate gate? or is supporting Go a similar sized effort to the javascript efforts? 20:32:56 mordred: my only show-stopper has been support in gate and understanding that. Happy to see the last infra meeting touch on this. Without gate testing, we don't really have much to show. 20:32:57 dims, I disagree. I think the projects and the cores should have an input but the decision should not be delegated down (if that is what you implied) 20:32:58 Kiall: no, we decided that we would exmaine each language case-by-case 20:33:10 Kiall: no - that was more about asserting that there was no specific python requirement 20:33:12 annegentle: Go doesn't have the co-installability issues that Python does… static-linking effectively makes every binary like a packaged venv 20:33:28 annegentle: flaper87: from the swift side, we've got that. we've already seen swift+golang deployed together in prod 20:33:30 Kiall: and that we'd address specific suggestions as they arose using our best judgement 20:33:32 ttx+mordred: noted. 20:33:32 amrith : here we can choose that golang is a valid option. then projects can choose where to add that to their arsenal 20:33:36 Everyone, please, let's focus on the community cost for now. 20:33:40 dtroyer I've seen that for clients, okay. 20:33:47 if infra has the tools they need and the questions are resolved around it for reproducible installs/builds/testing it is less of a concern to me. 20:33:52 Second type of community cost is infra / QA / release management support 20:33:53 notmyname: that's actually great news 20:33:54 I agree that the fragmentation concern, within a project, is a worthwhile concern. We've seen it within Ironic 20:33:57 but it is a serious concern if we don't have that answered. 20:34:03 is there a bigger community cost from allow just some projects, or allowing a free for all? 20:34:10 allowing* 20:34:11 do we have any idea what we are getting into there ? 20:34:21 morgan, thingee: we had the beginnings of the discussion with notmyname in the previous infra meeting about infra needs 20:34:21 dtroyer: it may or may not have similar issues when it comes to distro packaging (coinstallability isn't just about virtualenvs, it's also about dependency management and packaging/distribution) 20:34:43 dims, that brings me to my concern on this which is how the intended governance model would work. Is what is being discussed here "Go for Swift" or "Go for All" 20:34:49 ttx: I haven't really started looking at what it would take to release go code using our current systems for releasing other things 20:34:54 mordred, jeblair: any chance you could summarize the early discussion on infra cost ? 20:34:55 mordred: ++ i was watching. but seeing that move in a positive direction would be a requirement for me to sign off on this move. 20:35:00 ttx: it's very early 20:35:06 jeblair: right, but that is now a build-time/package-time issue, not a deployment issue 20:35:07 and additions. 20:35:09 so - the main thing is that we've got some design thinking to do 20:35:11 ttx: IMO, not really. We'll not have a reasonable idea until we try it. 20:35:20 go has a very different set of assumptions 20:35:20 mugsie: gate testing is a community cost - if you consider free for all 20:35:32 Horizon has a lot of issues with fragmentation, and JS is a reasonable knowledge expectation for UI developers, but it also inhibits outside contribution 20:35:32 because i don't want to see us say "Lang X is GREAT! AND WE USE IT" with out a path on the infra front. 20:35:35 which means that we have to learn things about what tooling go has now 20:35:44 and figure out how it fits in with the rest of things 20:35:48 I certainly don't feel comfortable letting this in until we have a better understanding of what the pla is CI/Infra wise 20:35:52 we're in the phase right now of collecting reuqirements 20:35:55 yeap. but less fragemtation is a potential plus (as there might be more people familair with go) 20:36:00 flaper87: +1 20:36:25 will there be an expectation that a go-project publish its docs in the same format as python projects? 20:36:27 It seems to me that teams which wish to implement parts of their projects in Go (or any other language) could do so outside the tent and integrate with projects inside the tent in exactly the same manner that all 3rd party vendors integrate 20:36:29 mugsie: just to be clear - one of openstack's problems (and it has many) is not ability to find contributors 20:36:32 mugsie: but will they be familiar with our very python way of doing it? Like imposing python concepts around docs? 20:36:37 or that a go-sub-project's docs be written into the docs of the parent-project? 20:36:37 mordred: so i think this is where we can continue to explore the CI story and infra story before we need to sign off on this choice (and it sound slike we might need to think about this for more than just golang) 20:36:43 so as said in the review, let designate and swift begin showing collaboration on this effort by figuring out the ci/infra pieces together. 20:36:44 and, what definition of complete for infra/test/doc/release would allow a Go project to start? 20:36:56 thingee: ++ 20:36:57 bswartz: right 20:36:59 thingee: ++ 20:37:05 annegentle: I think we need to have an idea of what the issues are, that they are solvable, and who is going to work on them 20:37:12 ok, my IRC exploded and it's getting hard to follow. 20:37:12 devananda I'd like discussion on that docs Q as well 20:37:13 annegentle: I don't personally think we need them all solved at the outset 20:37:13 I think all cross-project team need to do their homework and tell us what a world with Go would look like from their perspectrive 20:37:21 * amrith tries to parse mordred's last comment 20:37:25 mordred nor do I, but a list would help. 20:37:26 mordred: +1 20:37:36 ... " one of openstack's problems (and it has many) is not ability to find contributors" 20:37:37 bswartz: i am not willing to prevent non-python inclusion if we have the other bits lined up. 20:37:43 amrith: I think we need to have at least identified the issues and who is going to work on solving them 20:37:47 oh. that 20:38:05 I think 'not' in the wrong place, maybe. ok 20:38:05 morgan: it's another option which should be considered 20:38:07 amrith: mugsie made a comment about possibly opening the door to the potential hordes of go devs 20:38:09 ttx: ++ 20:38:14 heh, off the top of my head, no special treatment for Go docs. That makes things easier. 20:38:16 bswartz: i think it is unreasonable to say "no languages but python/js (at this point)" out of hand. but coming up with the story/way to handle it is important before we specifically include it 20:38:20 amrith: I was merely pointing out that finding developers is not a probelm we have currently 20:38:27 in fact, if we could have a few less it would be nice 20:38:29 notmyname if you can think of a Go-based doc system we should look into, let me know. 20:38:46 mordred: I doubt there will be hoards, but there might be more people in the community with familiarity of both languages 20:38:47 bswartz: am willing to say this will come up again even if we ask it to be 3rd party for now. 20:38:48 annegentle: last we chatted, I think "godoc" was tossed out as the thing that did dev-level docs 20:38:57 mordred yeah that's sort of the point here, should we prioritize and focus? 20:38:57 the release management team will look into that too, and I suspect the discussion with infra will continue this week as well 20:38:58 mordred, I think there are different problems in different projects but let's stay on the 'go-train' for now. 20:39:01 instead of just a small group of people in swift + designate 20:39:07 annegentle: Go has a certain level of documentation built in https://godoc.org/golang.org/x/tools/cmd/godoc 20:39:09 it might be the ultimate solution, but... we'll see as the convo progresses 20:39:16 annegentle: it's on the list of stuff to answer. currently the full extent for the answer is "godoc + sphinx". (which isn't a full answer, obviously) 20:39:17 I think we should move gradually with this inclusion. If anything, we should start just with specific cases rather than opening the gate to every project. 20:39:26 ttx: it seems there are two threads to the discussion. a) social fragmentation of project teams b) technical challenges to meeting existing expectations around shared infrastructure 20:39:31 notmyname timsim check. 20:39:48 one of the things that I am noticing is that a large part of the language change choice seems to be based on the performance of a specific implementation detail in how we use python: eventlet 20:39:48 devananda: ++ 20:39:55 clarkb: ++ 20:40:00 * mordred stabs eventlet 20:40:02 clarkb +++++ 20:40:02 devananda I think a) should include fragmentation of all community teams. 20:40:03 clarkb++ 20:40:08 it is probably also worth considering that maybe we have made poor lib choices and that langs are not necessarily the thing to get stabbed here 20:40:09 clarkb : true 20:40:17 clarkb: +1 20:40:20 clarkb: ++ 20:40:27 clarkb : yeah, I'd love to see a comparison with asyncio or twisted or some other similar framework 20:40:28 clarkb: ++ 20:40:41 clarkb: that's part of the technical benefits discussion 20:40:46 so lets be fair, if the social fragmentation is a real concern, isn't it fair to let a couple projects lead into it? 20:40:47 yay! back to twisted! 20:40:52 and see how it goes (beyond horizon) 20:40:54 clarkb : i still think having one more choice is not bad. projects can choose to take adopt it or not 20:41:00 for swift, it's not eventlet that's the problem. it's the way threads are handled 20:41:02 espe. with the overlap within python and golang communities? 20:41:15 dims: sure there may be a valid reason to switch it just seems odd to say "eventlet is bad so we used Go" 20:41:17 wat 20:41:19 so, to stay on the community costs side of the discussion... 20:41:25 morgan: mentioned that above. Letting 1 or 2 projects experiment should be fine as long as the concerns on Ifra/CI are clarified 20:41:26 ttx: ++ 20:41:30 morgan but that's part of the problem of defining community costs ONLY with dev cost. 20:41:31 its definitely a way to address that issue, but its a very high cost one compared to potential alternatives 20:41:31 yah ... SO 20:41:37 I'd like to disagree with morgan 20:41:48 the costs on the infra side to support go are not going to be small 20:41:50 flaper87 : swift and designate have already done PoC's 20:41:52 devananda listed two aspects of community costs, are there others ? 20:41:52 it's going to be a LOT of work 20:42:05 dtroyer: NO https://wiki.openstack.org/wiki/UnifiedServiceArchitecture 20:42:09 so doing that work to allow one or two projects to 'experiment' is a bad approach 20:42:11 :) 20:42:17 there's way more than dev cost here. infra, test, doc, packaging, deploying 20:42:25 dims: I know but POC is out of the TC governance and they've done that on specific environments and different communities circunstances 20:42:31 the work on all of the things may well be completely worthwhile 20:42:33 morgan: we already have fragmentation between python and JS community, as was pointed out earlier 20:42:38 I'm worried about the community not the technical implications in the specific projects 20:42:42 mordred: is it true we have to do someo of this work *anyway* though for any new language? 20:42:57 morgan: there is a cost for every new language, yes 20:43:00 is it worth generalizing the approach mostly at this time, and then move into "language" specifics? 20:43:05 this is the reason that we don't want people just doing new languages all the time 20:43:07 or are we already past the generalization part 20:43:12 and why we're talking about it now 20:43:23 mordred : this resolution does not do that...just go 20:43:26 I'm just saying that I think we can sort out the pros/cons before asking someone to go figure out deps and mirroring for infra 20:43:33 dims: yes. exactly 20:43:45 oh. wait. I was disagreeing with flaper87 not morgan 20:43:50 lol 20:43:51 morgan: I believe adding another language will create another "group" of folks that, while part of the big tent, feel disadvantaged and perhaps struggle to work with the Python community 20:43:51 mordred: hehe. 20:43:51 I think 20:43:53 mordred: what did I do now? 20:43:54 no idea 20:43:57 I was disagreeing with SOMEONE 20:44:01 who may or may not even be here 20:44:07 OK, we need to move on 20:44:11 devananda : now we are telling them to go away, which is not good either 20:44:15 ttx: but we're having so much fun! 20:44:17 mordred: +1 to figuring out the _technical_ costs of to sharing infrastructure across languages 20:44:28 mordred: before folks go off and do a bunch of work 20:44:30 devananda: yes 20:44:37 although I think it's not just technical 20:44:40 there is a social cost here 20:44:42 So I think we managed to narrow down the community costs to two broad categories, one of them needing investigation by various teams 20:44:43 which sounds techincal 20:44:46 but I tink is a community thing 20:44:46 and i believe that can be done by a collaboration between some TC / CPL folks, and some golang folks 20:44:56 mordred: social cost, that's the biggest of my worries here 20:45:01 that is - there are a different set of underlying assumptions as to goals/desires baked in to various languages 20:45:03 I'd like to have time for a quick summit postmortem in open discussion while we still remember what happened there 20:45:04 mordred : we are heavily weighted towards what we know...python 20:45:06 I'm not assuming that those are the same people -- but if there are golang experts on the TC / CPL team, great :) 20:45:11 go makes a different set of tradeoffs 20:45:13 which si great 20:45:16 it should 20:45:24 ttx: I would also like time to discuss the leadership training trip 20:45:28 but mapping those social expectation tradeoffs into our world 20:45:31 so I propose we defer the discussion on the technical benefits of Go to next week -- that will let the ML thread continue to grow 20:45:37 is a community issue in addition to a techincal issue 20:45:41 dhellmann: as would I 20:45:51 perhaps we should discuss this again next week and summarize today's discussion in the review 20:45:58 a case in point - go has an amazing ability to reference depends directly via git 20:46:01 which is neat and tehcnical 20:46:16 but it places a very different value on 'releases' than we traditionally have 20:46:26 * dhellmann would find all of this easier to digest in a document instead of irc 20:46:28 and the broader go community operates in that way 20:46:28 morded .. it is a nightmare for packagers ... 20:46:29 mordred : y we peeled that onion the other day on -dev 20:46:38 dims: awesome 20:46:43 amrith : y zigo already mentioned that 20:46:55 OK - let's continue on the thread, I'll summarize the discussion on community costs on the review, and talk technical benefits next week 20:46:57 mordred: that is one thing we will nedd to have specific guidance about… just because tooling allows bad practice doen't make it right… so yeah… 20:47:12 dtroyer: and not just allows - but actively promotes 20:47:13 dtroyer : ++ 20:47:19 #action ttx to summarize community costs start-of-discussion on the review 20:47:24 dtroyer: vendoring code is considered "the right thing" in the go community 20:47:30 yay ttx :) 20:47:37 #topic Open discussion 20:47:38 dtroyer: and there are several sets of tools to make it easier for people to do 20:47:44 * Summit postmortem 20:47:53 So... how did Austin work for you ? 20:48:02 I'd like us to discuss this today while it's still fresh 20:48:15 good bbq 20:48:17 I was pretty happy with the Upstream development track, I think we should try to have that in Barcelona again 20:48:19 the keynotes are still a wasted chunk of my day, but are a great time for me to get to sleep in a little 20:48:32 mordred: you should have come to the dev lounge 20:48:33 i'd rather be working with people during that time 20:48:39 nice to have vids to point to also for Upstream dev track 20:48:42 thingee: Gus's Fried Chicken was great too :) 20:48:46 cost me more productive time than I would have guessed 20:48:46 fast video posts, dang. 20:48:47 dev lounge needs a size increase 20:48:48 thingee: yes, but at the same time also not enough bbq :) 20:48:50 sdague: maybe next time let's schedule things 20:48:57 I liked the upstream track, too. 20:49:03 ++ dhellmann 20:49:09 mordred: we managed to get the DS area doors open during keynotes this time 20:49:10 mordred: +1 on the keynotes feedback. I normally don't show up 20:49:14 The location was nice, the dev area worked well! 20:49:16 I only popped over the the upstream track once, because it was on the other side of the universe 20:49:26 yeah, the walking on monday killed my feet 20:49:29 upstream track was good - it was a shame it was on the same day as cross-project and ops - and yes, it was very far away 20:49:29 I was pretty disappointed by the productivity of the cross-project workshops day 20:49:34 I think that distance was sub optimal 20:49:35 I think I had 14k steps Mon. and Tues. 20:49:36 I never made it into the expo hall 20:49:41 devananda: me either 20:49:43 ttx: yah. there were too many things co-scheduled 20:49:44 Feels like we have the same discussions every 6 months, we spend 20 min reexplaining the issue to the attendees, we don't have the people we need in the room and then the 40-min clock hits 20:49:48 mordred: didn't you give a few of those keynotes? ;) 20:49:55 ttx: I feel like the ones I were in were pretty good 20:50:02 Kiall: heh. I gave very few of them 20:50:04 but, again, it's about being at an actionable middle 20:50:05 we had some schedule conflicts that I think could have been avoided in some of the project tracks (oslo & nova in one case) 20:50:10 ttx: I felt that they were hit-and-miss. a couple x-project sessions I was in went well 20:50:11 sdague: that's because you avoided the ones that were repeats :) 20:50:13 we need to do a better job with PTLs of planning 20:50:17 ttx: yes, I did 20:50:18 random observation, going to this summit with the idea of a split summit in mind, made me very much wish the summit was split already. 20:50:20 intentionally 20:50:21 sdague: we had a session we wanted you in 20:50:23 but there were some decidedly difficult conflicts on Tuesday for me 20:50:24 sdague: but you were in another session 20:50:34 dougwig: me too 20:50:35 sdague: so the one you weren't in didn't get as far as it could have 20:50:35 dougwig: yes, same here 20:50:37 dougwig : +1 20:50:38 sdague: but you're juist special 20:50:41 I also didn't go to *any* of the main conference tracks this time 20:50:45 \o/ 20:50:49 devananda: me either 20:50:52 since I wasn't speaking / on any panels, I completely avoided that building (aside from check in) 20:50:57 devananda: well, I went to the ones I was giving 20:50:58 devananda: me neither 20:51:00 devananda: did you wish you could ? 20:51:06 no! I did go to one - I went to gothicmindfood's talk 20:51:14 mordred: oh! right! I went to that one 20:51:20 ttx: yep. that's actually an event I would like to attend 20:51:24 I went to mordred and ttx's talk :) 20:51:24 devananda: ++ 20:51:28 I went between buildings for the appdev track every day 20:51:35 * gothicmindfood enjoyed all the hecklers from the TC 20:51:42 a lot of folks on the Ironic team skipped out of the design summit to attend vendor talks, or operator talks about ironic 20:51:43 I would love to spend time in the conference 20:51:51 some folks are doing really cool things with the project, it turns out :) 20:51:51 but as usual, that is not an option 20:51:57 Another takeaway I got was that the workroom trick (trying to lure people away from work rooms to get things done) is no longer 100% working 20:52:12 some of those rooms were completely overcrowded 20:52:15 ttx: I do not think the workroom distinction worked at all this time 20:52:21 ttx: That has NEVER worked for neutron 20:52:22 at leat not for me 20:52:36 mordred: it was only a matter of time before they saw through the trick 20:52:38 ttx: the distinction did not make any difference for ironic this time 20:52:52 gothicmindfood: LOL glad you enjoyed our presence ;) 20:52:53 ok, any other feedback ? 20:53:09 dhellmann wanted to discuss leadership training 20:53:12 lunch options on the dev side were the worst I've seen in a while 20:53:12 Workshops being 2 blocks away kinda sucked :) 20:53:21 yeah. don't confuse glutenfree with gluten containing stuff in the same lunch box 20:53:25 (Designate gave one, I nearly got lost..) 20:53:25 ttx: I can give a quick update 20:53:31 rockyg: yea.... :( 20:53:32 devananda : i had to go out for all lunches :) 20:53:38 yes, I've noticed that about 1/2 of the TC has signed up to go to training. I've been waiting to see if there was a critical mass before committing. How many others who haven't signed up are doing the same? 20:53:38 ok, let's parallelize this 20:53:46 rockyg, you didn't like the vegan food with mayo eh? 20:53:47 we've got 10 ppl + me signed up over at https://etherpad.openstack.org/p/Leadershiptraining 20:53:58 feel free to shout summit feedback while gothicmindfood explains training 20:53:59 gothicmindfood : only about 7 of those are TC 20:54:06 amrith, it was the pasta salad in the GF sandwich box 20:54:07 gothicmindfood : which is about 1/2 of the TC 20:54:08 * dims is on vacation that week 20:54:09 * claudiub looks at the time, panics, and just throws in the networking-hyperv governance patch for review: https://review.openstack.org/#/c/311566/ 20:54:15 I'm waiting to hear from dhellmann mestery johnthetubaguy and markmcclain about attendance 20:54:31 I've also got 3 ppl who are not current or recent-former TC members who are interested 20:54:33 mestery: it's close-ish to where you live 20:54:48 oh, mestery lives around here too eh? :) 20:54:50 claudiub: will approve that one tomorrow morning unless someone complains 20:54:51 gothicmindfood, are you taking names of people who'd liek to attend? 20:54:52 dhellmann: some of those are recent-former TC 20:54:54 jroll: minnesota 20:54:58 aha 20:55:00 not that close :P 20:55:02 gothicmindfood : true 20:55:03 non-tc members, that is 20:55:05 jroll: :) 20:55:06 ttx: gotcha, thanks. :) 20:55:13 jroll: yeah it is, it's all relative :) 20:55:15 gothicmindfood: I think it's time to open to anyone 20:55:16 amrith: current plan is to keep it open to TC and recent-former TC for the next two days, then open the rest of the slots up to the community 20:55:24 ttx: I can do that, happily :) 20:55:24 ++ 20:55:42 amrith: so - I'll send an email out tomorrow AM, EST to let people know they can go ahead and sign up 20:55:48 mtreinish: I think of close-ish as driveable but fair enough 20:55:49 even if they're not TC :) 20:55:53 gothicmindfood, thx. will keep eye open for that. 20:55:55 * tellesnobrega is away: I'm busy 20:56:09 gothicmindfood: so how many slots will be open? 20:56:17 morgan: right now there are 9 more slots. 20:56:19 gothicmindfood: If we get cross-community attendance I have ideas of hard leadership problems to discuss there :) 20:56:21 gothicmindfood: cool. 20:56:33 thanks claudiub 20:56:49 I have also asked the Foundation if there are any staff there that might be interested, but that was an aside, and I didn't get the sense they wanted me to hold spots for them 20:56:55 dhellmann: it doesn't seem you got much of an answer from anyone who isn't on the list who isn't dims 20:56:56 claudiub pretty sure it'll go on next week's agenda, never fear 20:57:02 mordred : no, not really 20:57:07 stevemar: ^ cc 20:57:12 ttx: that sounds gnarly and awesome \o/ 20:57:41 gothicmindfood: I'll talk to you about them once we have the attendance settled 20:57:48 dhellmann: I could imagine johnthetubaguy having travel issues. I will however look askance at mestery if he skips, given it's one delta hub to another 20:57:53 dhellmann: does that answer your questions ? 20:58:06 ttx: sounds good 20:58:14 ttx: I'll touch bases with some folks tomorrow. I think not everyone is here. 20:58:49 OK, any other topic for open discussion ? 20:58:56 or random thoughts ? 20:58:59 or summit feedback ? 20:59:19 ttx : 3 keynotes...i was shaking my head :( 20:59:40 the ones on the next day were better though :) 20:59:46 ttx: yah. reitterating the dismay at some of the keynote content 20:59:51 ttx: would be nice 21:00:04 how about Intel re-writing Nova in Go? :( 21:00:06 thanks to dhellmann for raising that in the feedback session 21:00:15 * dtroyer sees something shiny over there 21:00:16 app wasn't half bad. Just need to tie it into the phone clock on the "my sched" portion 21:00:16 ok, out of time 21:00:17 edleafe, c# 21:00:19 yeh, it would be nice if the keynotes were actually about openstack, and not random non openstack gorp 21:00:19 yes, the foundation folks were really receptive to that but I wouldn't want to speak for them on any action they plan to take 21:00:27 agree thanks dhellmann for bringing that up 21:00:33 edleafe : you should have posted that just before the summit :) 21:00:34 We'll continue the discussion on Go next week, please chime on the thread if you have a strong opinion one way or another 21:00:55 discussion next week will be focused on technical benefits 21:00:55 dims: I'll time it for the next one :) 21:01:00 lol edleafe 21:01:08 sounds good ttx 21:01:09 giving time for Infra/RelMgt/Doc to do their homework on Go support 21:01:23 Thanks everyone 21:01:27 ouch; did edleafe just throw that pitcher at me? 21:01:27 #endmeeting