20:02:02 #startmeeting tc 20:02:03 Meeting started Tue Dec 9 20:02:02 2014 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:07 The meeting name has been set to 'tc' 20:02:12 Hi everyone 20:02:15 Heya 20:02:18 Our agenda for today: 20:02:36 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:58 FWIW I transitioned the wiki pages so that they now reference governance.openstack.org 20:03:04 rather than duplicate info 20:03:16 neat 20:03:22 #topic Project structure reform spec 20:03:31 #link https://review.openstack.org/138504 20:03:42 That was posted last week, I want to collect as much feedback as possible before pushing another version of the draft (probably tomorrow) 20:03:55 There was some very recent TC member feedback I haven't had time to fully parse yet 20:03:58 I have to say its very well written 20:04:09 but so far I see no comment I can't address in a new draft 20:04:14 Its the best explaination of the problem we're trying to address that I've seen so far 20:04:17 o/ 20:04:34 There is an open question about the missing "impact for incubated projects" section that I wanted to discuss 20:04:37 yes, i don't see any major problems with it, and it's really clear 20:04:40 ttx: what do you see being the path for that document? 20:04:47 ttx: do we approve it and then show the community? 20:04:54 ttx: or do we want them to see it before we approve it? 20:05:00 new patchset, vote, then implementation using further changes 20:05:20 ttx: so, shouldn't there be a "explain" phase before implementation? 20:05:28 ttx: so that the community isn't surprised? 20:05:30 +1 20:05:30 well, we would socialize the spec for sure 20:05:37 for incubated projects, Solution 1 is to create an "incubated" tag in the original transitional taxonomy to reflect the current process. That's what earlier drafts proposed but I left it out of patchset 1 20:05:55 Solution 2 is to drop the incubation concept at the same time we introduce the new structure, and just consider all currently-incubated projects "openstack projects" 20:05:56 I think we should actually pause 20:06:06 i think implementation comes with explanation (like code should come with docs :) 20:06:09 Stop and tell people what we decided, why, and talk it through if needed 20:06:14 Before doing any implementation 20:06:19 +1 20:06:30 jeblair: people wont notice implementation until its done and then they'll feel rolled 20:06:36 mikal: sure, we should explain. I kind of wanty jay to start working on the code backend for the project taxonomy though :) 20:06:43 jeblair: given implementation is mostly in a repo people don't watch closely 20:06:50 On incuabted projects: For sake of seamless transition and baby steps, I think I'm leaning towards solution 1, and get rid of incubation as a second step -- but I'm fine with solution 2 too. 20:06:54 ttx: oh, yeah, I'm fine with that 20:07:02 mikal: i think actual implementation is not a patch 20:07:05 grr 20:07:09 ttx: we just shouldn't announce that Nova is the only OpenStack project until we've explained 20:07:18 ttx: I am fine with Jay coding the backend for that while we explain 20:07:19 mikal: heh 20:07:21 ttx: add it to my todo list 20:07:35 is not just a patch to the repo, it's a plan for how to actually do all that, including announcements, timetables, etc 20:07:59 anyway, we're probably violently agreeing 20:08:02 So, a silly question as well... 20:08:03 yes, implementation is more than just repo changes 20:08:12 Does "gets a room at the dsign summit" become a tag as well? 20:08:14 there will be ML posts and all 20:08:23 Or how to we allocate the somewhat limited space at the summit in the new world order? 20:08:30 mikal: so that's a good question. I'm working on the Vancouver summit 20:08:42 trying to secure more space 20:08:54 ttx: can you get 450 rooms? 20:09:03 I was leaning toward 500. 20:09:05 Yeah, you'll never have enough space 20:09:06 some of them can be really small 20:09:15 We need some other way of working out who gets one 20:09:26 There will always be smaller projects who have to miss out 20:09:44 but there may be some prioritization in order. the Foundation organizes the event, so maybe it can prioritize 20:09:49 I think that is a technical problem to solve external to the debate about project structure reform. 20:09:54 or we could defer to TC to prioritize 20:10:05 I want to have an idea of how much space we have and draft ideas first 20:10:17 jaypipes: yes 20:10:22 there's subjective criteria (tc/foundation prioritizes), but there's also some objective things we can do 20:10:22 jaypipes: probably, but it is a question a lot of people will immediately ask, so if we can address it before its asked that makes us look thinky 20:10:47 ttx: you already do prioritization of the time slots we have; i wonder what happens if you extend those ideas out to more projects? 20:10:52 As far as the spec goes, I'll push a new patchset tomorrow, hopefully we'll be able to vote on it this week and close it next week 20:11:02 For example we talked about a "widely deployed" tag. Perhaps we ask the Foundation to prioritize widely deployed projects for summit space. 20:11:19 mikal: thinky or not, it's a problem that can derail this entire discussion 20:11:34 * markmcclain first thought was the openstack room lottery 20:11:44 jeblair: Another idea is to limit the number of sessions in "large rooms" and favor smaller groups in parallel. 20:12:15 what about a size requirement for room 20:12:16 so I do think that exact room segmentation is going to be massively driven by venue 20:12:23 and stick everyone else into a shared space 20:12:25 I suspect that a discussion of how we allocate time slots to projects as the list of projects grows will indirectly also lead to a discussion around mid cycles if we start splitting the summit time up between more projects 20:12:48 and it seems weird to come up with all those fine grain rules ahead of time when our current model is basically to come up with a split plan about 3 weeks before the summit 20:12:50 sdague: yes, that's why I want to have venue details first 20:12:54 rank projects by number of active contributors, more contributors == more space 20:12:58 vishy: ++ 20:13:12 vishy: I actually used patchset proposed as a metric last time 20:13:23 as a measure of collaboration needs 20:13:25 I personally don't think there is a math formula here either that solves this 20:13:40 but then I also used "historic" values 20:13:43 this is actually going to be able talking with projects and figuring out their needs during the summit 20:13:44 ttx: do/can we have a count of ATCs attending the event, not just total count per project? 20:13:55 like I said... derail the discussion. 20:14:00 jaypipes: ++ 20:14:04 I think this can go offline 20:14:06 yes, this is not really the topic for today 20:14:07 jaypipes: sorry 20:14:16 jaypipes: all I was saying is we should think about it 20:14:21 Let's stop trying to fix it now 20:14:22 sdague: ++ to tabling this for now 20:14:23 I also think the tags work item should probably be a subgroup 20:14:26 And let ttx come back with a proposal 20:14:32 mikal: it's very much on my mind. There is a venue visit this week 20:14:37 sdague: ++ to talking to projects about needs 20:14:48 i should have space constraints in 10 days. 20:14:49 etc. 20:15:27 Once the spec is approved that doesn't mean our job is over. It's actually just starting 20:15:56 so back to mikal's other point, of socialization time 20:16:04 since it's more a framework for change than a change in itself. 20:16:19 what kind of time frame do people feel comfortable with there? 20:16:28 I'll probably turn the second draft in to a blog post for larger communication 20:16:45 approval next week, pause until new year ? 20:16:50 mikal: no need to apologize :) 20:17:01 New year at the least 20:17:11 We shouldn't make large governance changes over the holiday season 20:17:16 yeah, several weeks 20:17:16 * jaypipes would love to see a vote next week. 20:17:17 (as a general rule) 20:17:23 mikal: which of those is a large change ? 20:17:30 jaypipes: a vote on any topic, or just this one? 20:17:45 ttx: changing from an integrated release to somehting else seems like a large change to me... 20:17:53 mikal: we don't change that. 20:17:55 mikal: this one in particular -- i.e. ttx's second draft of this proposal 20:18:11 ttx: we can vote on it, but then we should start the "explain" phase in the new year 20:18:14 mikal: the integrated release will still very much survive until end of Kilo. 20:18:25 maybe that's what this needs 20:18:29 any change to the integrated release would come in a subsequently proposed change 20:18:37 a view of the timeline of how this would evolve 20:18:40 but not affect kilo 20:18:43 Yes 20:18:48 sdague: the "impact" section touches on that 20:18:49 Clearly I have misunderstood the plan 20:18:51 honestly, I don't really see a reason to not allow votes on new project inclusion pretty much right away. 20:19:08 jaypipes: yes, I don't think there is anythign warranting a long pause in there. 20:19:34 ttx: I just re-read that section 20:19:34 I mean, the holidays and all are going to be pretty light anways, so I suppose waiting until the start of the year is Ok, too 20:19:35 mikal: the change sets up a framework to describe something more complex 20:19:48 ttx: I think it wouldn't hurt to have more of a proposed timeline there 20:19:49 mikal: but we still import the "integrated release" concept in it 20:20:11 ttx: yeah, I get that integrated release becomes a tag 20:20:11 before we deconstruct it, but that's a larger change that we'll discuss afterwards 20:20:17 jaypipes: by votes on new projects, you mean provide the objective project criteria, right? 20:20:22 ttx: but it's *clear* that we intend to change that, and so I think having everyone understand the whole process for that change will make things go more smoothly 20:20:23 or did I miss something 20:20:26 ttx: I still think that people will immediately want their project included in openstack/ etc etc 20:20:52 mikal: i think if people do, we need to wait until we've hashed out the details 20:21:00 Anyways, we can take that discussion to a review of this proposal I think 20:21:03 mikal: sure. Not saying we'll rush anything. Just saying that the larger changes are actually still ahead of us 20:21:14 ttx: agreed 20:21:26 and will likely result in more heated discussions 20:21:29 ttx: all I'm saying is that we should accept that the Holiday period is going to be quieter 20:21:34 i think we should vote on the spec next week, start implementing it in the new year, but until we've actually implemented it, we should not rush to pretend that we have :) 20:21:46 otherwise we will just be very confused 20:21:50 jeblair: that seems sane 20:21:50 the trick here is to set the framework up first, so that those discussions don't end up slowing us down in other directions 20:22:11 I think it does make sense to create things as milestones with guessed on months when we want to have them done by 20:22:16 instead of just todos 20:22:33 i.e. we can start describing openstack projects better, even if agreeing on a compute base (or absence thereof) will take us a long time 20:22:41 maybe that would make it more clear to folks on sequencing or the like 20:23:01 sdague: I can add a timeframe aspect to the implementation part 20:23:12 because I expect that will be a point of confusion, and we do have a history in our community of thundering herds once an idea sparks 20:23:16 see: specs repos 20:23:53 ttx: great 20:23:59 sdague: just add a comment about that so that I remember to add it 20:24:08 yep 20:24:15 * ttx doesn't trust his memory after 9pm 20:24:17 Cool 20:24:22 cool 20:24:38 my question on incubation still stands though 20:24:57 should we import initially the "incubation" concept 20:25:11 or just drop the incubation concept at the same time we introduce the new structure, and just consider all currently-incubated projects "openstack projects" ? 20:25:21 #2 20:25:34 Herm 20:25:36 2 20:25:36 kill incubation imo 20:25:38 yeah, I don't see any reason to carry it over artificially if we're not going to actually incubate any projects 20:25:39 I need to think more about that one I think 20:25:39 it's arguably more of an active change to pick #2 20:25:40 yeh, I'd just drop it 20:25:46 but then the writing is on the wall 20:26:08 +1 to just dropping it, unless it still has some kind of real meaning 20:26:27 russellb: it would be the first one we drop. Can be same change, or subsequent change 20:26:43 heh, i don't think we'd ever have time to implement the rest if we kept it :) 20:26:44 ok, sure 20:26:45 would it make sense to wait until we have some other tags in place? 20:27:14 and prioritise reviewing incubated projects for whether they can have those tags applied 20:28:17 what would it mean to retain that tag, when we've stated an intent to remove it? 20:28:19 (just concerned that there will be a temporary vacuum for incubated projects in which they're not receiving guidance about how to move forward) 20:28:32 retain it means we need to define it 20:28:50 zaneb: a fair point, but I feel like that's actually where we're at 20:28:58 and apart from "legacy procedure artifact in becoming integrated" I don't know what we can put there 20:29:34 zaneb: cross-project teams are in the process of defining/communicating/creating those tools for projects which they don't directly support 20:29:44 until that work is done, there *is* a vacuum 20:29:47 i think the guidance to new projects is: go be part of the community and make some good software :) [which is really the point of doing all this, i think] 20:29:51 at least, that's my perception 20:30:00 jeblair: yeh, that's my pov 20:30:14 devananda: yes, and this is nothing new 20:30:17 yes, I don't think it's likely we're going to be holding any incubation reviews while also trying to rewrite this process 20:30:19 jeblair: is that any different for currently-incubated projects, vs. non-incubated projects? 20:30:27 dhellmann: exactly 20:30:30 most horizontal teams have been reinventing themselves over those last cycles 20:30:37 because there was just no other way 20:30:38 devananda: no, and I think that's kind of the point 20:30:48 jeblair: (that's a rhetorical question, if it wasnt' obvious :) ) 20:31:48 OK, so you guys seem to lean towards #2. 20:32:01 I'll draft a "impact for incubated projects" in the rev2 20:32:06 ttx women too 20:32:13 to spell the consequances out. 20:32:28 well, our female member is not present, and I was addressing TC members 20:32:36 sorry 20:33:02 Here but on my phone just to make sure you use gender correct pronouns :) 20:33:07 damn 20:33:20 guys and gals maybe 20:33:22 heh 20:33:33 ttx: may I suggest "ya'll" :) 20:33:36 folks 20:33:37 I think gals requires a certain hair style doesn't it? 20:33:40 folks is always good 20:33:41 Y'all is safer 20:33:43 y'all 20:33:55 * ttx just finished Ancillary Justice, for those interested in pronouns 20:33:56 sdague: sorry, yes, that's what I meant. 20:33:57 +1 to y'all 20:34:08 or even just "you" :) 20:34:08 y'all it is 20:34:14 progress 20:34:31 anyway, the only other thing is I think the work items should probably have a point person assigned to each one 20:34:33 this meeting is starting to feel like an ent moot 20:34:37 so they aren't nebulous 20:34:43 and get lost 20:34:44 +1 y'all. none of this ya'll business ;) 20:35:08 sdague: ok. I own most of them, except the taxonomy website which is jay's 20:35:12 dhellmann: LOL 20:35:21 I suspect TC members will start proposing tags though 20:35:28 and own them to completion 20:35:42 ttx: ok, so lets be explicit about it then 20:35:44 I want the "funniest project" tag. I will administer that one 20:36:05 Anything else missing ? 20:36:09 mikal: i support your candidacy to administer that tag. 20:36:10 I also left a comment on that :) 20:36:37 I also want to put in a bid for "most hygenic project" 20:36:41 OK, let's move on to next topic then. I have a surprise topic for open discussion too 20:36:42 But anyways... 20:36:56 #topic Housekeeping changes 20:37:03 * Add new advanced services repositories for neutron (https://review.openstack.org/#/c/138479/) 20:37:11 That is supporting the advanced services split in Neutron, acked by PTL. Will approve tomorrow morning unless someone opposes it 20:37:20 * Move hacking under the QA program (https://review.openstack.org/#/c/138499/) 20:37:31 This one has all the approvals lined up, will approve it now 20:37:57 * Add Castellan project to Barbican program (https://review.openstack.org/138875) 20:38:07 This one is proposed by the PTL. I'll approved it tomorrow morning unless someone opposes it 20:38:24 * Completed the gerrit-powered-agenda project split (https://review.openstack.org/139944) 20:38:47 This one is just reflecting a project split and rename that has already occurred. Now has jeblair's +1 as Infra PTL... Will approve if I get that and nobody complained before tomorrow morning 20:39:16 #topic Open discussion 20:39:28 Early look at potential L names: https://wiki.openstack.org/wiki/Release_Naming#L_naming 20:39:30 http://peakery.com/lemming-peak-canada/ 20:39:33 BOOM 20:39:36 +1 20:39:43 :D 20:39:48 * mikal votes for Lemming as well 20:39:53 credit to marun for finding that 20:39:54 russellb: nicely played 20:40:07 how come wikipedia doesn't know about it 20:40:16 though I guess that can be fixed too 20:40:18 russellb: you need to add that to the wiki page me thinks 20:40:21 ttx sorry I tipped your hand, sitting in the same room as these folks 20:40:32 +1 for Lemming 20:40:36 * dhellmann imagines the fun we could have if we call it Limerick 20:40:46 * dtroyer likes the four letter name trend we have going… 20:40:46 lemming is even in BC 20:40:52 jeblair: yes! 20:40:55 * ttx checks that this thing actually exists 20:41:05 Langley should be quietly dropped as well 20:41:15 I don't think a CIA themed release is in our marketting best interests 20:41:16 20:41:17 mikal: ++ 20:41:26 I still think Loonie should be listed in "Other symbols" 20:41:29 lemming, lemming, lemming 20:41:34 Heh 20:41:37 ++lemming 20:41:46 alternative google maps link: http://goo.gl/7uZ49O 20:41:50 I must admit that Lemming is even a BC landmark 20:42:00 which makes it a strong contender 20:42:05 :) 20:42:11 mikal: now you have to find a munchkin in tokyo 20:42:23 perhaps we can take a day trip up there and throw ourselves off. 20:42:26 But then we had "Lizard" which is cool too ! 20:42:30 anteaya: I am asking the city to rename something right now... 20:42:35 take a moment and imagine the universe where we release "OpenStack Love". 20:42:38 lemming! 20:42:39 it's cold bloodeed and... ok.ok. 20:42:40 jaypipes: ummm, no roads that I can see 20:42:43 mikal: that will work 20:42:52 OpenStack Liberty! 20:43:13 now we need to be dropped on Lemming Peak by helicopter 20:43:33 Mirantis do good parties 20:43:39 I'm sure they're up to helicoptering the TC around 20:43:41 mikal: LMAO 20:43:49 can't cost much that then TC dinner 20:43:55 more* 20:43:56 ttx: LOL 20:43:59 ha! 20:44:07 true statement 20:44:37 OMG 20:44:40 jeblair: lol 20:44:47 We have to argue about mountains for the next 15 minutes? 20:44:54 no 20:45:06 mikal: it's in the charter 20:45:10 can someone edit https://wiki.openstack.org/wiki/Release_Naming to add lemming 20:45:12 ttx: you accept the wisdom of the peanut gallery then? 20:45:27 sure, i can 20:45:32 what other names would you like as backup ? We need to do some namecheck trademark thing 20:45:33 * russellb takes the wiki page lock 20:45:51 so better include 3 names 20:45:53 laurentian 20:45:57 lizard 20:45:57 laurier 20:46:01 lizard 20:46:07 spock 20:46:19 so we want to pick the 3 worst names right? 20:46:36 lizard, lulu, love 20:46:44 Longueuil, Lasqueti, Llangorse 20:46:52 spock five: http://ibackpackcanada.com/spock-five-the-new-canadian-currency/ 20:46:58 eek, that last one is a little too welsh 20:47:12 My wife suggests "Lemon" 20:47:15 markmcclain1: trouble is, the namecheck on lemming might just return 1 20:47:27 so we need a decent backup 20:47:44 I like lightning from the wiki list... 20:47:47 Lawn 20:47:55 Love isn't bad 20:47:57 +1 for love 20:48:05 London would be in keeping with our "not where you think it is" theme 20:48:06 mikal, kevinbenton: needs to at least pretend to be in BC 20:48:20 ttx: lightning is on your wiki list 20:48:23 dhellmann: ++ 20:48:28 Lightning (Peak) 20:48:29 yes, but not lemon ? 20:48:36 Oh, yeah 20:48:40 We can ignore my wife there 20:48:40 lightning is neat, A bit too neat 20:48:41 lightning sounds so cheesy, but i kinda like it too 20:48:47 +1 for Love; +1 for Lolo 20:49:00 Still +1 for Lemming, but +1 for Love as well 20:49:04 Lipton is a brand of tea... 20:49:08 +1 for Lanz 20:49:10 How can you not be +1 for Love? 20:49:10 unlikely to pass, yes 20:49:20 Spread the OpenStack Love! 20:49:29 in all seriousness, not sure about the negative connotations of lemming, but it's just so funny because it's been used so much already 20:49:32 Love is going to be so cheesy 20:49:45 Imagine the parties for OpenStack Love! 20:49:49 mestery: yes! 20:49:53 Yeah, lawsuit right there 20:50:07 * fungi can see the complaints already 20:50:13 mikal: you are such a cynic, but i love you anyway 20:50:19 * dhellmann imagines hippies 20:50:22 jeblair: we can hug it out later 20:50:28 there be hippies in bc 20:50:31 OK, I guess I can compile this to a list of candidates for our staff to check 20:50:36 Anything else ? 20:50:38 Longview has some ok connotations 20:50:39 Leather 20:50:43 There's ahttp://en.wikipedia.org/wiki/Leather_Peak 20:50:47 oh dear. 20:50:58 Sigh 20:51:00 marun: yes, it's on the list 20:51:08 Lower Post 20:51:12 err or at least it was. 20:51:20 may have removed it because it's not BC 20:51:25 also, http://en.wikipedia.org/wiki/Lynx_Mountain 20:51:29 Lynx 20:51:41 Lucid Lynx? 20:51:44 anteaya: you clearly havne't seen the creepy lynx ads in australia 20:51:49 I have not 20:51:56 just seen Canadian lynx 20:51:56 mikal: youtube 20:52:01 ttx: 'leather peak' is on the border of alberta and bc 20:52:18 marun: I blame Google 20:53:38 anteaya: https://www.youtube.com/watch?v=LAx-NP4T9CY (I do not endorse this product) 20:53:55 i do also like london to go along with juno and havana 20:53:59 Lanz 20:54:03 it has a Z therefore it is cool 20:54:17 jeblair: ++ 20:54:22 Other topic: we'll discuss joehuang's cascading at next week cross-project meeting -- I wasn't at that cascading/cells cross-project session in Paris. Who was ? 20:54:27 seems we have several decent options, so that's cool 20:54:34 ttx: I wasn't I had a clash 20:54:35 i was 20:54:41 ttx: I thnk John / Dan Smith were though 20:54:53 yep, would be good to invite them 20:54:58 so is that getting any traction is the real world ? 20:55:00 I certainly understood that Cells v2 was the Way Forward though 20:55:09 ttx: not afaict, no 20:55:21 mikal: their proposal aims to address some stuff cells doesn't 20:55:27 but it was still far from clear to anyone in the room 20:55:36 feels like joehuang didn't get a strong enough "no" answer and is pushing for a cross-project effort yo adopt cascading all over 20:55:49 Bold move for sure :) 20:56:09 well, I just don't see it happening if it's in parallel without strong support from everyone 20:56:25 Agreed 20:56:29 i didn't really pick up *any* support in that room, honestly 20:56:44 but then I guess it's a topic for next week, just wanted to see who had an opinion and could help drive that discussion to some conclusion 20:56:52 a big part of it is just approach to the whole thing 20:57:05 should we address it on the mailing list thread before the meeting? 20:57:11 well, that would help 20:57:16 dhellmann: ++ 20:57:18 dhellmann: we could, they did post a follow up on there 20:57:22 i was so caught off guard by their post though 20:57:26 I can't really oppose his claims of support as I wasn't in that room 20:57:30 it was so far off from the conclusion i got from the meeting 20:57:38 it would be best coming from someone who was there -- the best I could do is ask about the outcome of the meeting 20:57:43 Yeah, I feel a bit like ttx 20:57:49 I wasn't there, so I don't really know what people concluded 20:57:56 There was an etherpad though, right? 20:58:04 well, i guess i can take an action to respond sometime this week 20:58:07 but that definitely doesn't match what people told me happened there 20:58:13