20:03:04 #startmeeting tc 20:03:05 Meeting started Tue Aug 4 20:03:04 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:03:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:03:09 The meeting name has been set to 'tc' 20:03:13 o/ 20:03:20 Our agenda for today: 20:03:24 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:03:31 #topic Half-cycle introspection on "things the TC should be working on" 20:03:34 o/ :) 20:03:38 (Timeboxing this to 30 minutes) 20:03:42 * Rockyg lurks 2 20:03:43 So... we are at about half of Liberty 20:03:58 I wanted us to take a step back from purely processing what's being thrown at us, and think a bit about things we should be working on fixing or improving 20:04:01 * geoffarnold lurks 20:04:12 Half of us posted eloquent threads to get elected a few months ago, but I don't feel we followed up with actions everywhere 20:04:29 So... what should we be working on ? And how to make any of it happen in the second half of Liberty ? 20:04:51 Personally I listed three goals: step out of the way, start addressing real issues, push towards both ends of the scale space 20:05:02 We did /some/ stepping out of the way by simplifying the project list reviews, delegating tag maintenance, and accepting project teams at earlier stages of development 20:05:12 (other suggestions on further improving on that is welcome) 20:05:16 * jaypipes was neither eloquent nor remembers self-assigning any action items 20:05:28 We created workgroups to start addressing real issues, like the Project Team Guide workgroup to address the loss of common culture. 20:05:34 jaypipes: you're special :) 20:05:38 * devananda recalls saying lots of aspiration things for others to do :) 20:05:44 I'd say we should create more, hopefully as a result of this discussion 20:05:48 i'd like to be further along with tags, but i'm just as capable as anyone helping with that, so i hope to be more active with the next tags WG for the 2nd half 20:06:01 the thing I'd really like to figure out how to make progress on is service catalog standardization 20:06:06 About pushing towards both ends of the scale space, I think defining the compute starter kit goes a long way to address the small end. 20:06:09 sdague: +1 20:06:10 sdague: ++ 20:06:15 sdague: ++ 20:06:19 we had a CP session at summit, but it sort of petered out 20:06:25 we have several cross-project specs that seem to be languishing 20:06:33 #info we should figure out how to make progress on is service catalog standardization 20:06:46 and there is a ton of weird code all the projects carry around because they barely acknowledge SC exists 20:06:49 are cross-project specs the "start addressing real issues" area? 20:06:52 dhellmann: yes, we don't seem to have a good dynamic on that 20:07:10 or is a better example "help glance land code?" or? 20:07:20 annegentle: not necessarily. For example to address culture issues we set up a workgroup to write the project team guide 20:07:42 annegentle: yes, that would be a good example 20:07:48 ttx: ok, yep. And we set up communications working group. 20:07:53 on cross project specs, honestly, I think we should tell folks to only come forward with one if they are running into resistance at the project level and need TC blessing on a thing 20:08:08 I think people are going to cp-spec first and just making a new bottleneck 20:08:25 sdague: I think they're useful for agreement/details, but yeah could be just a new place to argue? 20:08:40 sdague: tend to agree on that, but people don't discuss cross-project until we raise it at the cross-project meeting, and the spec was a conduit to do that 20:08:41 the whole cors thing probably didn't need to be a cp-spec, for instance. 20:08:47 sdague: well, in at least a couple of cases the projects pushed back asking for broader consensus 20:08:52 * Rockyg is going to finish next draft of Error Codes at Ops midcyle (have a working group session) 20:08:52 dhellmann: ok 20:08:54 if people raised more random topics for the cross-project meetign we wxouldn't need them as much 20:08:55 the request-id thing, for example 20:09:12 ttx: agreed 20:09:34 can we take them to the ML instead? because I feel like cp-specs are mostly a piece of gerrit I forget exists, because there is so much gerrit 20:09:49 ttx: yeh, or that 20:09:51 sdague: there's soo much ML too though. 20:09:57 annegentle: +1 .. 20:10:14 sdague: that has been tried, too, and didn't really help either. 20:10:17 sdague: Usually the cross-project meeting discussion is the escalation step when the thread goes nowhere 20:10:38 but nowadays people give up on the thread and don't push for cross-project discussion 20:11:06 ok, well, I guess that's a thing. How do we do actual cross project things? 20:11:06 at least when they write a spec, the meeting chair will give the idea some cross-project air time. It's more of a workaround than a solution 20:12:07 + 20:12:22 I had my hands full with the project team guide and next-tags workgroups, but I also wanted to brainstorm on how to make cross-project specs/meeting/discussions more efficient 20:12:28 sdague: for service catalog, the teams and people are willing to pick up tasks, it's the coordinating/timing that's tougher 20:12:35 yeah cross project communication was one of the things I wanted to work on 20:13:02 ttx, markmcclain : ++ 20:13:12 #info cross project communication (specs/meeting/discussions) is one of the things we should try to work on 20:13:36 annegentle: well, it doesn't feel like there is much of a game plan. I guess that's what it's missing, a point person. 20:13:46 task assignment, how does that work on cross project plans? 20:14:06 I don't have a magic bullet there, been iterating on various formats for the cross project meeting, and nothing was really successful 20:14:14 sdague: yeah, agreed. Sadly the etherpad going down was sort of to blame for not having more detail tasks lists out of the summit planning. 20:14:18 At least with the chair rotation I guess the project became more visible 20:14:26 s/project/issue/ 20:14:28 yeah, I'm not convinced the meeting is going to solve that problem. 20:14:33 dhellmann: agreed 20:15:05 as annegentle and sdague were saying, we need some sort of ownership structure for these things 20:15:09 dhellmann, sdague: I stil want to have a forum for projects to agree with each other without needing to call in the TC 20:15:12 sorry, I had to step out a bit 20:15:20 * flaper87 quickly reads the backlog 20:15:21 so, I'm not convinced there is a general solution. But maybe if we pick specific cross project things we want done, we could try to come up with a working pattern in the small based on what works 20:15:21 ttx: absolutely, I'm not saying get rid of it, just that it's not enough on its own 20:15:43 service catalog might be a good thing to use as a unit test 20:15:48 sdague: right, maybe if we pick one or two specs early in mitaka and focus on those we can see how we can get them done 20:15:48 i.e. if the ML discussion goes nowhere, what option do we have ? Waiting for the next cross-project track at the design summit is not really a fast way 20:15:56 With full honesty, I haven't been able to attend cp meetings. Time-wise, it's not a good fit for me 20:15:57 dhellmann: yeh 20:16:10 And I feel bad about it but I get why it's that way 20:16:32 ttx: we usually take ML silence as consent, no? the problem is the spec author isn't getting any sign-off from the TC, so they can't proceed 20:16:32 flaper87: and I'l admit that since I don't chair all of them anymore, I don't follow them as religiously as before, due to same timing issue 20:16:54 dhellmann: sure, if ML is silent it's an easy call 20:17:15 dhellmann: it's when the discussion doesn't reach consensus that we have a problem 20:18:09 Technical discussions are like lasagna. You need to layer ML threads and IRC discussions to reach consensus 20:18:30 ttx: ooh, nice analogy! 20:18:49 * flaper87 wants to bring the cinder HA thread as an example 20:19:01 flaper87: I was hoping you would bring lasagna instead 20:19:13 ttx: I can do that 20:19:15 :D 20:19:16 if we look at the open specs: 20:19:16 "Uniform public methods for clietns" looks like we have consensus not to do this; 20:19:32 "No global admin" looks like something that isn't a code change so I'm not sure why that's a spec 20:19:46 "Return request ID to caller" has *finally* reached consensus, thanks to lifeless pushing on it 20:20:00 nice work lifeless 20:20:09 "resource retrieving improvement: support change-since filter" has very little input 20:20:34 dhellmann: that one doesn't seem like a good cp spec 20:20:38 dhellmann: that last one also has api-wg thing bumping around on it which is confusing 20:20:45 "Adds starting discussion spec for Service Catalog updates" has some approval, but some changes requested 20:20:58 "Replace eventlet + monkey-patching with ??" has languished 20:21:05 without clear consensus or work 20:21:29 Another set of problems is when project teams go wrong in their silo and need an external intervention to be fixed 20:21:36 "Add asynchronous user event support to OpenStack" looks like a new project someone should start and not a cp spec 20:21:38 We are staffing up in my team at the Foundation and we hope to be able to spend time diving into specific project teams to assess their current state and suggest solutions 20:21:53 "OpenStack wide Error Codes for Log Messages" needs author input, which Rockyg has said she's going to do 20:22:20 * Rockyg yup 20:22:25 "Add OSprofiler spec" has mostly negative feedback on the spec, but I remember a lot of positive support for the idea from the summit 20:23:19 OK, so I #infoed two areas we could focus on during the second half 20:23:23 "Cross-Project Policies" might be replaced by something newer 20:23:29 I suspect that who showed up for osprofiler session was somewhat self selecting, which would explain that split 20:23:38 Any other problems OpenStack is facing right now that we should be helping to fix ? 20:23:44 sdague: yeah, that would be my take 20:23:52 sdague: it wasn't a session, it was conversations throughout the week 20:24:09 folks other than boris-42 seemed to think *something* like that was a good idea, if not exactly what he was proposing 20:24:32 honestly, for me, it's a couple of things: 1. sprawl causing difficulty figuring out where to focus, and 2. events like mid-cycles and 2 summits a year causing interruptions 20:24:37 so, I do get that people seem to not want stuff on the mailing list - but I feel like one of the reasons the cross project efforts get gummed up is we don't have a project wide discussion forum any more in any format 20:24:48 so there is no where to synchronize 20:25:12 no, i still think ML is best 20:25:18 it's the most inclusive place to discuss 20:25:32 so I have this gut feeling that the midcycles are valuable for teams but offset from summits, where cross-project discussions happen. 20:25:33 "most inclusive"? 20:25:37 sdague: should definitely be discussed on ML first and a spec written only of necessary 20:25:37 easiest to participate 20:25:44 compared to irc meetings, where TZ is a problem 20:25:44 if* 20:25:58 asynchronous is easier to participate in 20:26:00 The problem with the ML is that discussions *always* digress 20:26:12 keeping them on track is really hard 20:26:17 flaper87: maybe we should push back on digressions 20:26:20 flaper87: so, can we fix that problem, calling people out for going off topic? 20:26:26 like off-topic, start your own thread 20:26:26 there are also too many of them to follow at one time 20:26:30 yes, it is hard, because everyone wants to have their say 20:26:37 its easier to be focused in a thing that looks like a meeting 20:26:42 sdague: I believe we do already but we're too many :P 20:26:47 and yeah, i think the only solution to that is to try to change the culture and push on digressions 20:26:55 clarkb: ++ 20:26:57 I don't see that issue as a blocker for using ML 20:27:01 but it's a real issue 20:27:05 it's a lot of work 20:27:29 it is 20:27:39 so are we suggesting that we not use the specs repo any more and push all of these discussions back to the list? 20:27:49 no no I think specs repo is super valuable 20:28:04 dhellmann: I think we are suggesting people interested in discussing that should have a longer meetign about it 20:28:10 dhellmann: honestly, I would suggest that 20:28:32 ttx: how do you ensure an outcome, have TC facilitators? 20:28:37 i think specs are valuable for cases where clear project-wide consensus needs to be clearly documented 20:28:45 You need a decision maker otherwise people just flail for a while. 20:28:48 I would prefer doing both. We need a place where the final consensus gets written down and reviewed 20:28:52 russellb: agreed 20:28:53 i need to be better at looking at them though ... 20:28:53 annegentle: we coudl reuse the workgroup foirmat and have some cross-project comm workgroup 20:28:57 sounds like that applies to several people 20:29:07 russellb: right, but it's much easier to sketch on the list or in an etherpad 20:29:16 yep 20:29:18 but we shouldn't be using the CP repo to decided whether we should all go and drink tea together in tokyo 20:29:21 ttx: would it be better to have a wg per initiative? 20:29:33 I think what ttx means with *f* a spec is needed is that once the discussion brings out the key issues/approaches, if a spec is still needed for action, write it, but it will start more focused and be easier to get attention on it to complete its process 20:29:37 ttx: so I think the issue is that there are meeting people, and there are ML people. 20:30:08 sdague: stylistic preferences, yeah... 20:30:11 honestly, if we are talking about something that requires real feedback, I'm not going to be able to do much of that in an interactive meeting. It needs digestion 20:30:15 I do both 20:30:25 (lasagna) 20:30:25 sdague: but again points to a need for "final" decision making 20:30:43 arbitration, whatever it is. 20:30:56 OK, time is mostly up, what's the next step on that ? Workgroup meeting ? ML thread ? 20:31:01 I get there are meeting people but, as much as I hate emails, we need emails. We can't pretend folks interested are going to chase on IRC logs to know what's happening 20:31:10 annegentle: sure, if concensus doesn't emerge. But, honestly, the reason SC is stalled is not because it's controversial 20:31:14 * flaper87 sent a similar email referencing Glance a couple of weeks ago 20:31:27 I want to make sure we discuss it again before mid-Mitaka 20:31:35 ML brings more attention and it's for async communications 20:31:47 sdague: yeah, service catalog is more about chasing the final outcomes 20:32:22 annegentle: honestly, I don't know it's even that :) but maybe if we identify a point person it would be helpful. 20:32:43 ttx: ideally, the TC would identify some important initiatives and help push, if not drive, them, in whatever forum. I'm not convinced the forum is the problem, per se. 20:33:10 sdague: yeah, I feel like it should have been me, but I haven't chase 20:33:12 chased 20:33:24 so.. keep using ML+Specs and cross-project meetings the way we currently do ? 20:33:30 I think it's a much bigger issue that projects look at someone trying to do something across the whole community and say, "I'll wait for some other folks to sign on so I know that's something real I have to pay attention to." 20:33:51 anyway, time is up. If someone has a suggestion for change, I guess step 1 is a ML thread 20:33:53 so, vishy said a great thing in Atlanta, which is that anything that needs to get done needs 1 person in point 20:33:54 dhellmann: ++ 20:33:55 ttx: I feel like there's something else about midcycles and inperson meetings 20:34:04 because a group tends to assume someone else is doing it 20:34:12 sdague: ayup 20:34:13 dhellmann, ++ 20:34:18 sdague: sometimes the person with the idea isn't the right person to make that happen and needs help, and I think that's where we're failing right now 20:34:32 so I think basically anything we sanction out of the TC as important should have step 0, determine point person 20:34:34 such as, if you wanted to get attention for service catalog across projects you'd have to go to a half dozen midcycles 20:34:40 sdague: definitely 20:34:50 annegentle: honestly, I don't think so 20:34:55 sdague: ok, whew :) 20:35:01 ok, moving on 20:35:09 timebox! 20:35:11 needing a point person applies to just about anything anywhere 20:35:15 we have a few items to cover 20:35:18 #topic Adds Debian & derivatives packaging to OpenStack 20:35:26 #link https://review.openstack.org/185187 20:35:31 i had a mission statement concern, but generally +1 20:35:36 This was recently updated 20:36:07 not sure how baked this is, but whatever, the rpm one wasn't super baked either 20:36:58 that mission statement concern is valid 20:37:01 mission statement seems to encode a gating strategy that i'm not sure i agree with 20:37:07 russellb: yeh, agree 20:37:26 question is, do we require than it's changed to merge it, or should we just propose an adjustment 20:37:28 russellb: ah good point 20:37:30 as a subsequent change 20:37:37 I'm fine if the team wants to get there, but I don't think the TC should stamp that as approved direction 20:37:45 i'd rather it be changed before approving 20:37:47 personally 20:37:47 that's fair 20:37:55 russellb, sdague: agreed 20:37:56 zigo: here? 20:38:01 would +1 without the long-term goal 20:38:11 russellb: yep, agreed. plus I think there's a typo in there. 20:38:27 Let's move on and come back to this if zigo appears 20:38:28 russellb: I don't think deb-mural is the right deliverable name ;) 20:38:35 heh 20:38:38 murallo 20:38:44 jaypipes READ the patch! 20:38:51 jeblair: woah 20:38:55 i read the top part :) 20:39:07 #topic Kolla application for Big Tent 20:39:09 #link https://review.openstack.org/206789 20:39:13 This one looks pretty straightforward, especially with all the other packaging initiatives in 20:39:44 i've followed the OSAD concerns 20:39:53 jeblair: ? 20:39:53 but i'm really not personally too concerned with overlap at this level 20:39:59 jaypipes: past tense 20:40:04 jaypipes: joking that you actually read it 20:40:07 ahhh 20:40:10 jaypipes: oh wow sorry about that :) 20:40:13 sorry, missed that :) 20:40:21 stupid enlish 20:40:21 heh yeah, alternative reading was very different :) 20:40:38 mainconcern raised is about duplication of scope with the OpenStackAnsible project 20:41:31 Looks like we need to investigate that late conern a bit deeper 20:41:32 ttx: it is true they are similar problems (deployment) but take radically different approaches to achieving the goal 20:41:37 ttx: yes, though I raised that concern on patch 1, and sdake seems to have answered the question. the answer might not be amenable to kevin carter and justin shepherd, but it is an answer. 20:41:37 jaypipes: https://review.openstack.org/#/c/1/ 20:41:57 this would not be the first deployment overlap 20:42:00 ty patchbot. 20:42:01 meh 20:42:06 sdague: can you summarize the differences? 20:42:20 yes I have a list of 11 items if you have time dhellmann :) 20:42:34 sdague: well, is it written down somewhere I just might not have seen, yet? :-) 20:42:35 sdake: i think it'd be good to put it on the review for the record 20:42:36 Kolla manages the container configuration outside the container, whereas OSAD manages the configuration by connecting to the SSH process in a container to change the configuration. 20:42:46 russellb: ++ 20:42:51 russellb yes I asked in the review if the tc would like to see it 20:42:55 can add er in 20:42:58 sdake: yes i'd like to see it :) 20:43:02 sdake: yes, please 20:43:08 I personally don't care if it's a duplicate of the openstack-ansible deployment process, as long as the containerisation part is not tightly coupled to it 20:43:10 will do 20:43:10 ++ 20:43:32 OK, let's wait for that and we'll gather votes later 20:43:36 zaneb: did you see my last comment on the review? 20:43:41 yeh, for once, I'm 100% in agreement with zaneb :) 20:43:53 Although it already has 7 votes 20:43:56 the containerization part is not tighly coupled 20:43:59 sdague: :D 20:44:11 ttx: yeah, but i think we owe the concern a bit more air time 20:44:16 my concern with separate repos is it would make dev harder 20:44:19 I feel like we specifically opened up for a lot of deployement solutions 20:44:20 since they are loosly coupled 20:44:28 yeah, I'm not concerned about overlap, but I would like to understand the issue more 20:44:30 and ansible doesn't get a global lock on a space there 20:44:45 To me it's an openstack team. The fact that its container approach is not the same as OSAD is similar to DEB and RPM not being the same. 20:44:47 this seems to be a good "don't pick winners" thing 20:44:54 sdake: yeah, understood. it was more a brainstorming question than anything else.. 20:44:55 yeah 20:44:58 jeblair: yes 20:45:04 it's a team definition to me as well 20:45:10 sdague: since puppet and the chef cookbooks follow a separate repo pattern, IIRC. 20:45:16 jaypipes I will answer in the review for permanent record ;) 20:45:21 I'm fine with approving now. I just want to give everyone a chance to retract their vote based on recent developments 20:45:23 sdague: np :) 20:45:37 i don't plan to retract 20:45:42 I don't either 20:45:54 if everyone is fine with their vote there, let's just approve it now 20:45:54 me neither 20:46:09 * flaper87 neither 20:46:11 to reiterate, i'm *much* more concerned about overlap as we get closer to the core infrastructure, say, something in the compute starter kit 20:46:12 wfm, maybe sdake can still post that link though 20:46:19 russellb: same here 20:46:29 dhellmann I have to actions - answer jaypipes q and your q 20:46:32 to/two 20:46:33 let the deployment approach flowers bloom 20:46:39 dhellmann: agreed, can be done async 20:46:39 russellb: ++ 20:46:41 sdake: great, thanks 20:46:43 russellb: I'm predominantly (only?) concerned about overlap on RESTful API functionality. 20:47:00 jaypipes: *nods* another good way to look at it 20:47:03 I'm actually kind of disappointed in the ansible team for trying to throw that block in there 20:47:03 * ttx moves on to next topic while we wait for the info to be posted 20:47:10 though i'm probably more concerned about some APIs than others 20:47:12 #topic ATC: Add Cathy Zhang as Neutron ATC 20:47:15 anyway 20:47:15 #link https://review.openstack.org/207136 20:47:20 I think this is straightforward, but we still require those to be voted on by the TC 20:47:24 Last time I looked it was still missing a couple of votes 20:47:25 this one seems harmless, though likely unnecessary 20:47:25 russellb: http://foaas.com? 20:47:32 :P 20:47:35 actually missing 3 20:47:40 jaypipes: the best API there is 20:47:42 there was some question of whether it was needed, but I think we should approve it anyway 20:47:43 hehe 20:47:53 vote on it and I'll approve it. Object now if you disagree 20:48:01 #topic Feature deprecation / config deprecation policy tags 20:48:08 ttx: right, so she's author on - https://review.openstack.org/#/c/192933/ 20:48:16 #undo 20:48:17 Removing item from minutes: 20:48:20 so I guess I'm confused why extra atc is needed 20:48:28 sdague:oh, then we can abandon it 20:48:53 sdague: ah hm. Co-authors still need to be added 20:48:54 https://review.openstack.org/207136 references the reason for her being atc was working on that spec 20:49:11 she's not the co-author, she's the author 20:49:18 true 20:49:33 maybe some previous rev she was co-author? 20:49:34 that's what git will show 20:49:41 there's 2 people that keep switching ownership of patches in that repo 20:49:43 why did she approve her own spec? 20:49:45 Hmm. do we look into authors or owners... 20:49:51 is that the same cathy? 20:49:53 aren't spec patches showing up as ATC work? 20:49:55 dhellmann: there was a thread about that, yes 20:50:04 some people upset about it, but i think it's been discussed and addressed 20:50:20 russellb dhellmann: Ack on that, we scolded her and she apologized. :) 20:50:29 ttx: i believe owner 20:50:29 right should be as settled as it will be for now 20:50:33 fungi: ^? 20:50:40 mestery, russellb : ok 20:51:02 if we look at owners then probably should still be added manually 20:51:09 and it doesn't hurt anyway 20:51:15 jeblair: oh, it does gerrit owner query, not a git query? 20:51:21 right, not git 20:51:26 checks gerrit db 20:51:27 oh, never mind then 20:51:44 #topic Feature deprecation / config deprecation policy tags 20:51:49 Those come from the "next tags" workgroup. The first one is about feature/API deprecation policies: 20:51:53 #link https://review.openstack.org/207467 20:51:58 assert:features-always-supported asserts that you won't deprecate anything ever 20:52:03 assert:features-follow-deprecation asserts that you follow a predictable, reasonable deprecation policy 20:52:11 The latter is designed to match the current "default" deprecation policy we had for integrated projects in the past 20:52:21 I may have gotten the timeline wrong. If a feature is marked deprecated during the L cycle, when at the very minimum should we allowed to remove it under that policy ? 20:52:29 start of the M cycle, or start of the N cycle ? 20:52:30 is the former provided for completeness? it doesn't seem very realistic. 20:52:31 does any project follow "always-supported" ? 20:52:48 russellb: good question. I heard swift claim it 20:52:52 bold claim 20:52:56 at the release of the N deliverable I believe? 20:53:07 (that is, it's a year I thought) 20:53:08 maybe we could replace that with a longer deprecation policy 20:53:16 seems like "always-supported" is just "follow-deprecation" without any plan to exercise the deprecation flow 20:53:21 annegentle: "at" meaning "in" or "after"? :-) 20:53:30 annegentle: most projects have been doing single cycle deprecation 20:53:32 * jaypipes personally needs a bit more time to think on these. I like the idea behind them. just want to Gandalf-ponder on them a bit. 20:53:37 stepping way back -- is this valuable as a choice? 20:53:44 jaypipes: ++ 20:53:56 would it be better to establish a project-wide deprecation policy? 20:54:06 dhellmann: when cloud consumers could possibly use the API capability 20:54:12 jeblair: some projects will prefer not to assert any deprecation policy and move fast 20:54:17 "in" the released release :) 20:54:29 jeblair: but yes, that could be an option 20:54:30 annegentle: so something added in M could be removed in N? 20:54:40 dhellmann: nope! 20:54:41 please comment on the review, no time to solve it today 20:54:47 The other review up is about config file options deprecation: 20:54:48 so, honestly, I'm not sure this is going to work as a tag 20:54:51 #link https://review.openstack.org/207584 20:54:55 something added in M, released in M, could not be removed until the release of O 20:54:58 because there are a lot of specific situations 20:55:00 ttx: k, thanks. even this brief discussion was helpful. :) 20:55:05 but maybe I'm too conservative? 20:55:06 (not sure we need to separate config file options from user-visible features/APIs) 20:55:10 annegentle: we need to come up with a clear way to say that :-) 20:55:11 and it feels like a guidance document might be better 20:55:21 dhellmann: ayup 20:55:24 ttx: i think it's valuable, REST API changes are a bigger deal than config file stuff IMO 20:55:32 russellb: ok 20:55:40 I have to head out, sorry, comms ideas in flaper87's capable hands 20:55:46 russellb: yeah 20:55:53 REST API changes the most important to establish clear policy on 20:56:03 sdague: isn't the tag a guidance document, with the application of the tag indicating the projects that are following the guidance? 20:56:29 please follow-up on review 20:56:30 OK, skipping workgroup reports for today and jumping to open discussion 20:56:35 #topic Open discussion 20:56:35 dhellmann: maybe, honestly, for deprecation I'd expect a lot more guidance 20:56:43 About topic tagging for governance reviews, I posted a question at: 20:56:48 #link http://lists.openstack.org/pipermail/openstack-tc/2015-July/001005.html 20:56:49 sdague: but there is a point at which a project moves from 'we will break everything' to 'we will try to maintain orderly deprecation'. usually it's 1.0. but we need _some_ way of calling that out 20:56:53 Any preference ? 20:57:10 zaneb: ++ 20:57:23 Also.. next week I'll be coming back from vacation and won't be able to prepare for the meeting. 20:57:25 ttx: i like your inverted suggestion 20:57:26 sdague: sure, maybe suggest some details to be added 20:57:31 Does anyone want to pick it up and chair it, or shall we just skip for one week ? 20:57:41 i think i may be traveling next week 20:58:14 There'll be a tc post this week 20:58:16 I prefer to skip since I won't be around to babysit anyone to chair, but if someone wants it, they can run with it :) 20:58:25 zaneb: well from my experience from the tempest side, most of the projects don't deprecate in an orderly manner 20:58:28 There are enough topics for a new one 20:58:49 OK, Cathy's extra atc review has enough votes on it, I'll approve it now 20:59:22 Will approve the Kolla one as soon as Steve pushes his 11 point explanation 20:59:27