20:02:06 #startmeeting tc 20:02:07 Meeting started Tue Apr 19 20:02:06 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:08 ttx: flaper87 asked me to say he might not make it today 20:02:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:10 The meeting name has been set to 'tc' 20:02:10 * morgan hides. 20:02:12 * stevemar sneaks in and sits in the back 20:02:22 Hi everyone! 20:02:26 Our agenda for today: 20:02:32 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:02:39 * rocky_g snuffles and coughs quietly in in the back but away from edleafe or stevemar 20:02:41 * edleafe can't see with stevemar sitting in front of him 20:02:55 #topic Retire release:has-stable-branches tag 20:03:01 #link https://review.openstack.org/305702 20:03:16 This one completes the transition to stable:follows-policy by removing the old has-stable-branches tag 20:03:26 o/ 20:03:26 Now has enough votes to pass, will approve now unless there are questions 20:03:40 no questions from me 20:04:11 #action ttx to follow up to project navigator folks so that they use the new tag 20:04:30 #topic Add release:cycle-trailing tag 20:04:35 #link https://review.openstack.org/306037 20:04:48 This one fills a gap we currently have: some projects are not formally part of "the OpenStack release" (since they release after the date) but still are pretty attached to the cycle 20:04:49 this seems pretty straight forward 20:04:59 Currently we force those to be "independent", but that's not the right answer 20:05:09 Hence the proposal for a specific model for things that are linked to the release cycle while not formally part of the release 20:05:12 basically for packaging / config management stuff to follow official release right? 20:05:20 Yeah... The only thing I'd like us to be careful with is our usage of the word "release" 20:05:30 I still think "the Mitaka release" should be done and complete on release day, otherwise it doesn't mean anything 20:05:37 So cycle-trailing things are not part of "the release", they are published after the release 20:05:46 And we'll have to present things on releases.o.o in a way that makes that clear 20:05:59 ttx: ah, good point, they depend on the the mitaka release 20:06:28 Still a better place to be than to consider them cycle-independent 20:06:30 yeh, I guess, I doesn't seem to me to be that confusing if puppet for mitaka lands the week after the release :) 20:06:33 which was just wrong 20:06:35 but so be it 20:07:17 sdague: i don't see it that way, but this is a nice clarification 20:07:26 sdague: erm.. i see it the same as you 20:07:28 sdague: I don't want people to go to the release page on release day and then back the next week and discover additions... We need to consider it shipped at some point 20:07:33 sdague: better to be clear 20:07:39 thing is- I imagine that the puppet to deploy mitaka might continue to be updated as people learn things 20:07:41 "this is following a dev cycle" 20:07:47 but we need a place for things trailing the release 20:07:52 mordred: yeah same here... hm 20:07:58 mordred : so will mitaka, as stable updates are made 20:08:12 dhellmann ++ 20:08:13 dhellmann: right - but those are not feature things 20:08:15 dhellmann: ok, so it is a "point in time" 20:08:18 mordred: possibly like we update stable/mitaka in projects as we learn things 20:08:21 a few folks from fuel, puppet have looked at it and were ok with it. so +1 from me. only question i had was around the 2 week time frame. but that seemed ok to them 20:08:27 so sdague you make a good point they will probably call it those the "their" release mitaka as well, anyways 20:08:28 mordred: sometimes they are 20:08:28 it just clearly says "this isn't expected to release at the same day 'mitaka' is GA" 20:08:39 morgan: yes 20:08:39 for instance, mitaka added the ability late in the cycle to bootstrap keystone not using an admin token 20:09:00 one could imagine the puppet people adding support to the mitaka puppet 3 months later as a new 'feature' for managing mitaka 20:09:01 o/ 20:09:05 * mtreinish1 curses verizon 20:09:18 I think trying to shoehorn things like puppet into the same box as things like nova is going to hurt 20:09:20 has enough votes to pass, so will approve now unless someone objects 20:09:27 mordred : are you anticipating some sort of issue with what has been said? 20:09:29 mordred each project has the ability to use the semver minor version to indicate 'feature' changes if they so choose 20:09:30 mordred: we just backported mtu logic to liberty today, stuff happens 20:10:01 dhellmann: nope. just being verbose 20:10:05 mordred : ok 20:10:16 mordred: as an alternative, what would the option be, stay "independant" release? 20:10:19 ok, so we seem to violently agree, just making a few verbose points 20:10:20 I think there will be puppet for mitaka 20:10:34 it will be confusing to people if we tell the puppet team they can't say that 20:10:35 not because i think it *needs* to be independant or cycle-trailing 20:10:37 just curious 20:10:48 sdague, I think you are right, else its just too confusing 20:10:55 sdague : we're not saying that. "puppet for mitaka" is ok. "puppet in mitaka" is less clear. 20:10:55 puppet for mitaka sounds good to me 20:10:56 i support a clear line "these things follow the cycle, but are part of the cycle" 20:10:56 morgan: ya. I do not htink it's important for the puppet modules to have a mitaka release of the modules. although I thin kthey can choose to do so if they'dlike 20:11:10 regardless of how it's communicated 20:11:16 via a tag... via... and meail 20:11:16 morgan: ++ 20:11:18 * amrith sneaks into a back row seat 20:11:21 a comment.. a branch, etc 20:11:24 mordred: we don't force them to follow cycle, they choose to :) 20:11:39 ttx : ++ 20:12:02 lets try the tag. 20:12:06 I agree that it might make sense for them to be independent, but they want to follow the cycle and have a styable branch per release 20:12:06 anyway, this seems extra meta :) 20:12:07 if it doesn't work, we remove it 20:12:17 we have that superpower 20:12:21 so we just give them a way to express that 20:12:35 yeh, it was an ask, I don't think it confuses things 20:12:36 yeah, the tag still seems like a sound idea, to better express what they do 20:12:40 the puppet, kolla, etc things want it. 20:12:48 or seem to like it 20:12:50 because currently none of the models fit that case. Doesn't mean we force all deployment stuff to follow that model 20:12:55 lets see how it works. 20:13:02 ok, approving then 20:13:10 yeah, seems worth trying 20:13:28 alright done 20:13:39 #topic Grant Cross-Project Spec Team Voting in Specs 20:13:43 #link https://review.openstack.org/306244 20:13:49 thingee: want to introduce ? 20:13:53 sure 20:14:25 in a previous TC meeting I was bringing up the fact that I would like to abandon openstack-specs that inative once communicated with the owner. 20:14:29 this is no longer a problem anymore :) 20:14:31 but 20:15:00 regardless I wanted to have the openstack cross-project team recognized to do voting on these specs 20:15:08 that involve the project team they represent. 20:15:19 jeblair requested a formal resolution to be written to capture this 20:15:28 is there a list of those folks besides in gerrit? Just for reference 20:15:39 thingee: so kindof like the rollcall vote for the TC goverance repo but for the x-project team? 20:16:08 this is giving the ability to the cross-project team to say whether a spec is good or not for their team, instead of the TC looking over that consensus by those teams and finalizing it in their own vote. 20:16:29 sdague: https://wiki.openstack.org/wiki/CrossProjectLiaisons#Cross-Project_Spec_Liaisons 20:16:39 morgan: yes 20:16:59 thingee: these liasions are like the others where it's the ptl or a ptl chosen delegate? 20:17:19 mtreinish1: yes see our project team guide http://docs.openstack.org/project-team-guide/cross-project.html#cross-project-specification-liaisons 20:17:31 mtreinish1: yes, although is that table pre-populated with PTLs to start thingee ? 20:18:02 I don't understand what the purpose of the voting would be -- just to register feedback? 20:18:19 agentle: originally yes. This team was formed late last year, email communications were originally made on list and directly to ptls to either serve themselves or delegate. 20:18:38 thingee is there a gerrit group populated from that wiki? 20:19:06 bswartz: so previous TC meetings, discussions were that the project team members themselves should know better if a spec would work for their project. If there is consensus in the community and these teams, why would the TC need to rubber stamp. 20:19:15 dims: not yet 20:19:26 i'd like to see it become a formal managed via code review group rather than "populate from the wiki" 20:19:34 if that makes sense 20:19:42 morgan: sounds fine to me 20:19:55 what I like about this is that it removed the TC from the approval process -- doesn't prevent us from commenting, but we don't stand in the critical path 20:19:59 * morgan doesn't trust wiki to be authoritative 20:20:00 so if a majority of liasons vote yes for a CP spec, it gets merged? 20:20:04 ttx: +1 20:20:07 this also introduces a chair to the group. so I guess ideally that person would be able to update the gerrit group 20:20:13 morgan : +1 20:20:22 bswartz: yes, though there's discussion of instead a percentage rather than an integer 20:20:24 ttx: +1 20:20:26 bswartz: i think the TC still can comment/weigh in (as we should) 20:20:29 morgan: +1 20:20:36 morgan: +1 20:20:49 and should be able to vote (it is our job to do so and look at the benefit/health of the community/projects) 20:20:49 the TC can still comment and participate. We can also be appealed to 20:20:51 since not all cross-project specs affect all projects, could we envision a percent? 20:21:05 in case people think the cross-project group is not operating correctly 20:21:09 but i don't see an issue with the cross-project team having more ownership 20:21:15 agentle: it's only the involved projects. last paragraph should talk about that 20:21:24 ok, another violent agreement ? 20:21:27 in fact.. i like it. 20:21:31 more ownership 20:21:41 ttx: Violent agreement is the best kind of agreement :) 20:21:46 mestery: ++ 20:21:48 one question though ttx, unanimous decision or majority? 20:22:07 that was a question some people had in the comments 20:22:18 thingee: current style is to rubberstamp consensus, so the chair determines if consensus is reached 20:22:24 unanimous could really hamstring you 20:22:29 thingee: ok 20:22:34 so current process is unanimous 20:22:37 thingee : i see a few comments there... 20:22:38 doesn't mean we can't change it 20:22:40 but 20:23:12 I think we should error on the side of asking for concensus 20:23:14 * morgan commented on the review. 20:23:19 sdague: ++ 20:23:33 and if we feel stuck, well the TC can always decide a thing 20:23:47 two ways of solving that -- you want agreement on all affected projects. If a project doesn't want that change, you could try to find common ground and worst case scenario apply the change to every other project and require consensus there 20:24:24 do you need consensus/unanimous? if project 1,2,3 like an idea, and project 4,5,6,7 don't, do you want to/can you block all the projects that said 'yay'? 20:24:38 or just have it come forward saying "the follow 2 projects object" but we think it's really important. And TC can say, yes, it's important we all do this thing. 20:24:53 sdague: ++ 20:24:56 seems like the cross project team basically owns deciding the best way to build consensus, and the appeal to the TC if no one can decide seems like a good safety valve 20:25:01 that should really be a very unlikely case though right? 20:25:07 sdague: seems like as ttx suggested the chair can determine that. 20:25:08 also is is a tacit approval/lazy consensus unanimity? 20:25:10 dansmith: i hope it's unlikely 20:25:13 gordc: so imagine a spec that affects ABCD. D disagrees. You should try to fix the disagreement. If that can't get done, you should limit the spec to ABC and require consensus there 20:25:14 gordc: I think the point is at the CPL level we're staying you all have the authority to come to concensus 20:25:16 and that's cool 20:25:17 if the chair is unsure, could ask the tc to weigh in 20:25:17 what sort of situation would need decree from the TC realistically? 20:25:19 if it is happening a lot, we have a difunctional team 20:25:29 ttx: +1 20:25:35 thingee: +1 20:25:42 dansmith: right, I'm just trying to say we lazy evaluate the conflict case 20:25:43 ttx: +1 20:25:45 ttx: ack. makes sense. 20:25:47 dansmith: so far we have not forced the issue on any of the times when a project has unilaterally just not done something 20:25:55 knowing we have a backstop if we need one 20:26:01 morgan: right, if a team refuses to play ball all the time it's grounds for removal, not to force them to merge that code 20:26:06 I think the only thing the TC has ever _forced_ over objections was the move to gerrit 20:26:12 ttx: exactly. 20:26:13 ttx: ++ 20:26:20 yeah 20:26:20 (and that as the ppb, not the TC) 20:26:26 this sounds like we're back to CP PTL determines if specs merge or not and the voting is irreleveant (or merely a feedback mechanism) 20:26:31 we can't force a project to accept code it doesn't want. That would not work 20:26:33 mordred: ah, memories 20:27:12 bswartz: i expect it to work like the TC tbh. if it isn't and the CP PTL is running wild, the TC can also step in. 20:27:16 so I guess I'd like to amend to the spec, if there is disagreement, the chair could merge it if he/she feels there are majority agreeing to it. 20:27:29 morgan : lol 20:27:30 * ttx has a big board with columns for each project team. Marks an X every time someone is being naughty and in the end if they get 10 crosses they don't get a present at Christmas 20:27:31 but if the chair can't make decision, could ask the tc to weigh in 20:27:48 dims: ;) 20:27:49 but also cp specs often don't apply to many (or even a majority) of projects, so asking for consensus across projects which don't have a stake in a particular spec could be problematic. but as long as discretion lies with the chair i suppose the definition of consensus can be considered flexible 20:27:54 ttx: ha ha ha 20:28:00 * johnthetubaguy thinks ttx might not be kidding 20:28:01 fungi: ++ 20:28:02 thingee: I guess my point is.. do we really need to say that? 20:28:17 johnthetubaguy : haha 20:28:19 johnthetubaguy: some projects failed to push their session descriptions in time. I added 2 crosses. 20:28:20 fungi: Right, I assume the definition of consensus is flexible 20:28:34 consensus is "affected projects" 20:28:38 dansmith: probably not 20:28:42 * johnthetubaguy nods at ttx 20:28:42 in this context 20:28:57 dansmith: right not it says unanimous decision. 20:29:09 "Assuming there is consensus with those that are involved" seems good enough 20:29:15 johnthetubaguy: ++ 20:29:16 We have majority votes on the proposal. Any opposition ? 20:29:17 johnthetubaguy: ++ 20:29:24 yep agree it's enough 20:29:26 johnthetubaguy: agreed 20:29:41 I'd substitute unanimous with consensus, personally 20:30:11 anteaya: so you'd advocate for "unnanimous" vs "consensus" 20:30:11 ttx: alright so I'll follow another update with johnthetubaguy's suggestion 20:30:14 I think it captrues the intent 20:30:16 it says consensnus now. 20:30:24 thingee: that's the current wording no ? 20:30:24 * morgan types badly today 20:30:30 consensus is better, IMHO 20:30:33 so I got the lines mixed up 20:30:35 dansmith: i agree 20:30:38 unanimous sounds like a jury convicting someone 20:30:41 line41 and 46 20:30:44 dansmith: GUILTY! 20:30:48 morgan: I advocate for consensous 20:30:48 dansmith: i mean... 20:30:50 current wording already says "Assuming there is consensus with those that are involved" 20:30:53 dansmith: only if there are 12 people 20:31:03 anteaya: it already says consensus in one loine, but unanimous in another 20:31:04 ttx: "in the cases where unanimous decision cannot be ..." 20:31:07 yeah, I cut and paste that, I guess line 46 is the sticking point 20:31:15 so.. thingee please make the consensus/unanimous lines agree 20:31:16 morgan: I'd remove unanimous 20:31:16 thingee yourcall, happy to pass it as is 20:31:38 thingee: if you cal edit that in-meeting, we can revote 20:31:42 * thingee clicks the edit button 20:31:55 I think something we need to be conscious of is the power for some of the larger projects (cough cough nova) to wield an implicit veto in cross project changes. 20:32:13 That's bad. 20:32:18 done 20:32:23 no, because we'd just be not part of the concerned parties right? 20:32:31 dansmith: exactly 20:32:32 please vote again https://review.openstack.org/#/c/306244/ 20:32:39 Right, if nova opts out, they['re note part of the consensus 20:32:43 And ttx can mark them on his list 20:32:47 check 20:32:48 yeah, let's not make this more combative :) 20:32:54 * cdent sighs 20:33:00 We've already seen this happen. 20:33:10 * anteaya frames dansmith's comment 20:33:16 anteaya: that one is free 20:33:22 thingee: thanks for the fix. 20:33:43 one more 20:34:01 please reapply votes 20:34:04 ttx: should be good now 20:34:19 indeed 20:34:20 cdent: lets see if we have progressed and have less "veto" happening, if it starts being a problem, we should absolutely revisit 20:34:21 approved 20:34:25 dansmith: thank you 20:34:27 cdent: i am well aware it has happened. 20:34:30 thanks, thingee 20:34:32 Thanks morgan 20:35:06 #topic Joint BoD/TC meeting agenda 20:35:07 cdent: but i think what we have now is solid and the right starting place.- 20:35:15 morgan : cdent : agree 20:35:18 morgan: agree 20:35:26 I pushed our ideas to Alan and that resulted in the following agenda for our Sunday meeting: 20:35:32 #link https://etherpad.openstack.org/p/6PuSKyUOHk 20:35:38 There may still be time to sneak another topic if you feel something is urgently missing 20:35:47 Otherwise it's easy to add a subpoint to one of the catch-all topics like "Newton tension points" 20:36:23 seems reasonable 20:36:24 the board members didn't exactly add much 20:36:35 but then I can do with a simple agenda 20:36:39 hm.. 20:36:40 Plenty of sheds to paint in that agenda ttx :) 20:36:50 mestery: good then 20:36:53 there was something i had someone ask me about... i don't remember what it was. 20:36:58 ttx: exactly :) 20:37:02 * morgan will try and remember and ping TTX 20:37:08 did I miss the discussion about why the product work group has 30 minutes in the board/tc slot? 20:37:45 ttx: the container/vm thing, should bare metal be included in that? 20:37:48 anteaya, roadmap, etc 20:37:50 anteaya: that was an item added by Alan (the only one) 20:38:00 ttx: okay thank you 20:38:02 jroll: i think that was part of the original convo 20:38:06 jroll: the more the merrier 20:38:08 jroll: i'd like to see it there. 20:38:08 ttx: it's really "does the nova api fit for different types of compute resources", right? 20:38:10 heh 20:38:12 agree 20:38:13 jroll : yep 20:38:29 jroll: added 20:38:33 thank you ttx 20:39:04 jroll: well, I think "does the nova api fit for different types of compute resources" is a possible outcome discussion for us 20:39:09 #topic Open discussion 20:39:10 anteaya, hmm. thanks for pointing out the prodwg thing. I would have missed it 20:39:20 ttx we often don't get fully through the whole board/tc agenda, can the product work group go last on this agenda? 20:39:31 mordred: fair enough 20:39:47 rocky_g: sure 20:39:53 anteaya: I'll make that suggestion 20:39:58 ttx: thank you 20:39:58 * Video with tips for design summit moderators 20:40:04 We shot & edited the video last week, then sent it to PTLs and session moderators 20:40:09 #link https://youtu.be/M4cDyM2s2bc 20:40:16 nice work! 20:40:22 yay 247 views we are YouTube stars 20:40:28 LOL 20:40:35 * dhellmann goes to watch it again 20:40:40 ttx: them them about your painting, I thought it was a mythical beast 20:40:42 half of those must be me and my sound checks 20:41:02 * Update reference list for Neutron projects (https://review.openstack.org/303026) 20:41:06 * docaedo loved that video - great work everyone involved :) 20:41:13 I wanted to draw attention to this review, which will be approved soon under our lazy approval rule unless someone objects 20:41:23 looks like adding it to agenda gave it some attention 20:41:31 It's a significant policy chnage in Neutron, so making sure everyone is aware of it 20:41:50 yay merge conflict 20:42:17 woot merge conflicts! 20:42:20 ttx: did he get an understanding of what it means for the release? (What does it mean?) 20:42:34 mestery : is the intent for those teams to ask for official status on their own? 20:42:59 dhellmann: they would likely not get it as non-testable using open source tools in ci 20:43:05 I've been moderating summit sessions wrong this whole time... 20:43:08 dhellmann: You'd have to ask armax, it's out of Neutron's hands once that merges 20:43:08 dhellmann: could they be, the list was all proprietary stuff 20:43:09 right, that's why I was asking 20:43:14 thingee: amazing! 20:43:20 But I imagine many of them may try (and likely fail) to apply 20:43:22 *for talking to proprietary stuff 20:43:26 agentle: what it means for the release ? 20:43:42 ttx: is this list for a particular release? 20:43:44 agentle: they become unofficial, so they are not part of "the release" 20:43:51 ttx: were they part of mitaka? 20:43:55 Right, once that merges, they are not openstack projects 20:44:01 Just projects using the openstack infrastructure 20:44:03 agentle: they were 20:44:07 considered part of mitaka, ok 20:44:15 which means release team is not on the hook to shepherd releases 20:44:20 except the ones using release:independent 20:44:26 hmm. 20:44:28 (which was most of them) 20:44:36 (those weren't part of mitaka, even though they were official during the mitaka cycle) 20:44:42 agentle: most of them weren't in mitaka 20:44:57 most/all 20:45:08 i think this is just reflecting the reality 20:45:10 I'd say all 20:45:12 so it actually won't change much 20:45:17 based upon what ttx and mestery just said 20:45:20 None of them had a mitaka release 20:45:24 so.. procedural mostly 20:45:27 They were all release:independent 20:45:32 well, welcome clarification 20:45:37 neutron core team couldn't vouch for them 20:45:44 ok yeah 20:45:53 we can put info in a blog post 20:46:07 I agree that if they were in mitaka the move would be more... significant 20:46:13 But we need to get ready for that 20:46:18 (cleanups of the tent) 20:46:27 Consider this a litmus test of sorts 20:46:35 if they had been in mitaka, i would have pushed this convo to the tent cleanup 20:46:40 Although much of the fury over this change has already happened 20:46:52 there will be things that were released in mitaka and will get thrown out in newton 20:46:56 but since they weren't i am not as concerned. 20:46:59 morgan: They were not released in mitaka, but their contributors got ATC, so halfway in mitaka? 20:47:06 ttx: ++ 20:47:17 mestery: leaving the ATC bit off the table. 20:47:22 yeah 20:47:24 morgan: thanks :) 20:47:24 ttx, is the BOD/TC meeting open to other attendees? I'd like to attend, especially the last line item on the agenda. 20:47:32 amrith: yes 20:47:45 thx ttx 20:47:53 amrith: got the location/date ? 20:48:00 no, am looking for it 20:48:03 it is sundday 20:48:05 i'll be there 20:48:06 amrith, the whole BOD meeting, not just the joint one with TC 20:48:19 except the private session 20:48:34 ttx, I don't have location/time 20:48:35 ttx, oops. Yeah. Thanks. Lunch. 20:48:45 * armax scrolls back 20:48:46 amrith: JW Marriott, Level 3, Salons G/H 20:48:50 amrith: https://wiki.openstack.org/wiki/Governance/Foundation/24Apr2016BoardMeeting#Joint_Board.2FTC.2FUser_Committee_Meeting 20:48:52 2:30pm Joint TC / UC Meeting 20:49:16 on Sunday 20:49:20 thanks ttx, will be there. 20:49:30 Anything else, anyone ? 20:49:56 there's remote access too - http://lists.openstack.org/pipermail/foundation/2016-April/002325.html 20:50:18 Happy to see you all next week 20:50:47 yay summit! 20:51:01 ++ we should get together more often than every 6 months 20:51:03 is there going to be a TC gathering? 20:51:11 safe travels everyone 20:51:12 dhellmann: of course! 20:51:22 even like the informalish bar thing last time, it was nice to happen 20:51:37 is there a second TC-only dinner this time 'round? 20:51:38 I'll be at the WOO event we can do something from there 20:51:49 agentle: no TC-dinner 20:51:49 ttx: that works 20:51:58 ttx: informal is good 20:52:07 we can all get the meat sweats together 20:52:10 sdague : ++ that would be good 20:52:13 I'll be at the Saturday Board/staff/TC dinner too, but I think a few members will miss that 20:52:22 agentle: ++ 20:52:23 yeh, I won't be there 20:52:23 yeah, I'm not coming in until sunday morning 20:52:26 * morgan will be around for Sat. 20:52:49 ttx: yeah, I'll be on a plane when that's scheduled 20:52:56 yeah, I fly in late ish saturday sadly 20:53:08 Sunday morning for me too 20:53:39 I'll see some of you Saturday evening then, and the others at the Board/TC meeting and at the WOO event and whatever comes next 20:54:37 safe travels everyone 20:55:00 alright, time to close this I guess 20:55:04 yeah, +1 to that, safe travels everyone 20:55:06 see you in a few days 20:55:14 * edleafe is driving up Sat afternoon 20:55:16 #endmeeting