20:01:06 #startmeeting tc 20:01:08 Meeting started Tue Sep 20 20:01: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:01:09 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:11 * amrith wanders over to the back of the room 20:01:12 The meeting name has been set to 'tc' 20:01:31 o/ 20:01:34 Our agenda for today: 20:01:43 #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee 20:01:44 o/ 20:02:00 (remember to use #info #idea and #link liberally to make for a more readable summary) 20:02:08 #topic Update tags per the validate tags script 20:02:13 * Rockyg sneaks in a side door 20:02:14 #link https://review.openstack.org/368086 20:02:18 o/ 20:02:24 Our semi-regular diversity tag updates 20:02:25 o/ 20:02:36 On the good side, OpenStack-Chef now has diverse-affiliation (thanks to WorkDay & CloudBau's involvement) 20:02:44 and Murano is no longer single-vendor, thanks to 99cloud's involvement 20:02:54 On the sad side, Telemetry lost its diverse-affiliation, and TripleO is now single-vendor 20:03:07 We have enough votes and no objection to approve this now 20:03:14 #info OpenStack-Chef now has diverse-affiliation (thanks to WorkDay & CloudBau's involvement) 20:03:20 #info Murano is no longer single-vendor, thanks to 99cloud's involvement 20:03:32 #info Telemetry lost its diverse-affiliation, and TripleO is now single-vendor 20:03:42 annegentle: NICE! thanks :D 20:03:46 * ttx approves 20:03:47 heh, copy/paste to success 20:04:14 #topic Add Ocata goal split out tempest plugins 20:04:22 #link https://review.openstack.org/369749 20:04:34 mtreinish proposed this alternate goal for Ocata, I think it's a reasonable one 20:04:44 The question is more, is the Ocata goal list still open at this stage 20:05:06 I'm fine with it if we approve it ASAP, but it feels like the PTLs haven't seen that one yet, so we migth want to wait a bit, which may push us beyond acceptable time 20:05:19 Opinions ? 20:05:21 ttx: we probably don't need to be as strict with it as we just worked on this 20:05:23 I think it's a good thing to do for sure 20:05:26 yes, my only real concern with this is the timing 20:05:33 what is the consequence of not reaching the goal? 20:05:41 I mean, I'd be good to have it in Ocata if the plan sounds realistic for the Ocata timeframe 20:05:43 dhellmann: what are the things taht are sticky to timing ? 20:05:57 dhellmann: there is the cross-project workshop list 20:06:11 and then there is the goal assessment deadline on the release schedule 20:06:16 anything else ? 20:06:16 but, I thought the goals were supposed to be stuff everyone more or less agreed on, and there are some comments in there that make it sound like some projects don't fundamentally agree with it 20:06:22 yeah, and resolving whatever issues people felt we had with the goal process in general that kept us from being able to approve the python 3 goal 20:06:32 sdague ++ I thought that we'd agreed that we would have discussions on the ML before a goal was approved. I don't know that we have done that, I certainly have missed it if we did. 20:06:42 so, for most porject sthat have an in-tree plugin this should be simple enought to split out 20:06:55 argh, missed those recent objections 20:06:59 * jroll is not fully convinced on the usefulness of doing this, but not enough to -1 here 20:06:59 mugsie: yes, it's honestly all very mechanical 20:07:05 the issue is that it forces projects to make API changes compatible 20:07:12 which can slow down dev 20:07:16 but in turn helps users 20:07:18 mugsie, please note that there is some funny tooling for at least two projects (trove is one) as mentioned by matt in his comments. 20:07:23 FWIW, I don't think anyone has said we should approve when there's disagreement. At least I was not expecting it to be approved now. 20:07:26 mugsie: which is supposed to be a standard 20:07:29 mugsie : right, that's a thing we want as a community 20:07:42 designate has it, and I think it is definitly the way forward 20:07:44 anteaya: bad karma 20:07:46 mugsie: ++ 20:07:53 ttx: okay, thank you 20:07:56 mugsie thanks for that 20:08:00 it has made us stop and think quite a few times 20:08:24 jroll: tempest is a branchless model, so plugins in branches end up causing massive confusion 20:08:45 amrith: what weird tooling do you have for tempest? 20:08:51 the plugin structions really need to mirror the consuming structure 20:09:04 mugsie, read mtreinish' comment in the review 20:09:05 which is why this is different than devstack, where it has branches that match project branches 20:09:12 * ttx reads the comments he somehow failed to receive notifications for 20:09:16 I like mtreinish's recent comments on why it needs splitting out 20:09:36 yeah, me too 20:09:45 i get the impression that some of us have difference experiences with "drive by contributors" and follow-up patches, which is where multi-repo becomes a massive heartache, especially with non-fun follow-ons. 20:09:49 that was all news to me, and kinda makes sense 20:10:14 those comments need to be preserved, like johnthetubaguy pointed out, maybe added to the doc? 20:10:15 ok, I don't think we can get to consensual state in the timeframe we have for Ocata goals 20:10:16 there is a hack to make it work the way it should, and doing this removes the need for the hack, is what i am reading 20:10:18 dougwig: what about Depends-On, is that something projects are aware of and using ? 20:10:21 sdague: yeah, I get it, I'm someone who has the plugin in-tree. not opposed, just not convinced yet 20:10:27 dtroyer_zz: yeah, I think it should be in the doc 20:10:39 johnthetubaguy , dtroyer_zz : ++ 20:11:04 flaper87: +1 20:11:06 flaper87: certainly, but once "the code" is in, there's no way to force someone to finish the test commit. maybe that means the initial code shouldn't have landed, but we have problems there today with one repo. 20:11:06 also the point about helping to ensure API compatibility is maintained should be added 20:11:11 depends-on is what makes this palatable I think 20:11:24 dougwig: right, you can block on depends-on 20:11:30 depends-on doesn't work branchless, either. 20:11:42 dougwig: yes it does 20:11:47 it would be good to address the process questions dougwig is raising 20:11:51 dougwig: have you hit any issue? 20:12:03 dhellmann: perhaps something to also have as recommendation in the goal itself 20:12:06 mtreinish: ^ 20:12:09 flaper87 : yeah 20:12:12 that's what I meant 20:12:14 oh? my mind was just blown. so a stable/mitaka commit can depend on a master commit? 20:12:19 dougwig: yes 20:12:22 dougwig : yes 20:12:23 oh, sweet. 20:12:53 dhellmann: a-ha, gotcha :D 20:13:07 dhellmann: what's your take -- do you really think we can get fast enough ietartions/response to get that one in Ocata in a reasonable time ? 20:13:22 I'm happy to help, fwiw 20:13:32 mtreinish: ^ 20:13:35 ttx: I'm skeptical, but I don't know how busy mtreinish is right now. 20:13:44 I think that people like to resist goals and we need a /lot/ of time to pass them 20:13:47 he is at a sprint in germany this week 20:14:02 I was kinda expecting to approve a some goals post summit, it feels like this could be one of those 20:14:03 I think a lot of the work can be nearly coookie-cuttered 20:14:06 we should make sure there's a cross-project session on this 20:14:23 dhellmann: in the goals session, or separate? 20:14:23 mugsie : yeah, the work itself is going to be pretty mechanical. the bigger hurdle is convincing projects to actually do it. 20:14:30 dhellmann: yup 20:14:38 johnthetubaguy: post-summit we'll start the process of approving Pike goals 20:14:43 johnthetubaguy : if we need to dig into the details, it should have its own session 20:14:53 johnthetubaguy : the goals session we have up now is supposed to be about the general process, right? 20:15:02 yeah, I think revising to add the use cases and benefits up front could mean we can get this discussed by leading with the "why" 20:15:12 dhellmann: yeah, I think thats the way I am leaning too, more just clarifying 20:15:14 and seems do-able by summit 20:15:18 johnthetubaguy : ++ 20:15:25 and at summit revisions as needed 20:15:31 #idea have a cross project session on tempest plugins and patterns 20:16:08 mugsie: it's actually not a super easy transition to move from in-tree to out-of-tree, it involves project-config changes that aren't self tested, and a bunch of cross-repo commits. it's doable but is easy to break a gate or be running less tests for some time 20:16:12 OK, so maybe we should just consider the Ocata list closed and start the discussion in Barcelona for a potential Pike goal around tempest 20:16:28 fwiw, I think it's fine to have this in Pike too. I'd love to see it as part of Ocata but I don't want to rush things 20:16:32 I agree easy to get done within a cycle, but it isn't trivial 20:16:36 jroll : right, part of the pre-work for this will be to document a reliable process for the transition 20:16:50 ttx: I think Pike is a better goal, just based on timing 20:16:53 ttx part of the point of goals is to prioritize work 20:16:56 ttx: unfortunately, I think that's the state we're in, yes. 20:17:03 dhellmann: cool 20:17:04 mugsie: yeah 20:17:07 for example I had no idea this was a thing until I ready the agenda this afternoon 20:17:08 ttx so if we think it's important enough, then we could prioritize it with discussion 20:17:12 the ocata goal could be to have this be a pike goal with documentation and process in place 20:17:26 so, ptls might like a longer heads up 20:17:34 yeah might be mugsie 20:17:35 ttx : yeah it probably late :( 20:17:40 mugsie : ++ 20:17:48 mugsie: yeah, we can't just throw a new goal idea into the process so late 20:18:13 #info A bit late to insert a new goal into the Ocata list (since Ocata just started) 20:18:17 I do think this one is a strong contender for pike, though. with a little more detail added it'll be quite doable in that time-frame. 20:18:19 but ++ for Pike 20:18:28 dhellmann ++ 20:18:35 so... another pike goal to think about for the list. All API services running under a non-eventlet webserver. 20:18:36 #info let's make sure we discuss this in Barcelona in time for it to be a potential Pike goal 20:18:36 a request, could we discuss this on the ML as we agreed in https://governance.openstack.org/goals/index.html#identifying-goals 20:19:04 amrith yeah 20:19:05 amrith : reasonable to do that. +1 20:19:10 sdague : that's listed on https://etherpad.openstack.org/p/ocata-tc-goals (which we should probably move somewhere with a less cycle-specific name) 20:19:11 amrith: +1 20:19:14 amrith: yes, that's part of the "too late" thing 20:19:17 amrith: I think this will be discussed in the ML anyway 20:19:21 what ttx said 20:19:23 OK, I propose we move on 20:19:29 * flaper87 chose his words poorly 20:19:31 sdague: isn't eventlet py3 compatible now? i thought that was the only objection. 20:19:38 thx flaper87 ttx. 20:19:59 dougwig: no, it's not the only objection 20:20:01 I think we have a way forward, and I'll summarize it on the review 20:20:09 ttx: thx 20:20:24 #topic Update tc-approved-release application policy 20:20:27 for the API services being under a real webserver actually means much better scale up / down in resource usage instead of a fixed worker pool 20:20:41 * flaper87 notices that without his glasses ttx and thx just look the same 20:20:45 #link https://review.openstack.org/368240 20:20:50 #link https://review.openstack.org/#/c/368240/ 20:20:57 This change proposes to let anyone propose additions to the tc-approved-release tag 20:21:10 As a reminder, this tag is used to describe what should be considered "the TC-approved release" (a concept used in the Foundation bylaws) 20:21:24 Our current policy around this tag is that (since all projects would be interested in having that badge) we would wait for /some/ interest from the defcore committee before evaluating projects 20:21:34 Personally I see no reason to change that policy 20:21:41 That said, this review raised interesting side-discussions. 20:21:52 In particular mugsie raised that tc-approved-release is used outside of the Foundation bylaws context, which I think is generally a bad idea 20:21:59 yes, we were careful to set this up to avoid lots of unnecessary discussion over this tag 20:22:04 (as it overloads the tag meaning and makes it desirable outside of Defcore context) 20:22:12 Yeah, so bazsed on the discussion on the patch, I think I would be better capturing the discussion in the policy 20:22:20 In the QA case he raised (in-tree tempest tests), it may be some sort of full circle though, as tempest is required to maintain DefCore-related tests... 20:22:54 mugsie: would you like to propose a new change (or a new patchset) that would bring those clarifications ? 20:23:20 yeah, if there is agreement that there is confucsion, I will propose it 20:23:22 I felt like the tag was sufficiently self-explaining, but it's easy to "improve" 20:23:37 mugsie: where is the confusion, exactly ? 20:24:03 around the usage of teh tag ? 20:24:05 the* 20:24:16 yes, in the spirit of writing things down, what else do we need to write down? 20:24:18 well, the confusion (for me anyway) is that previous comments would indicate that it was the TC who could add/remove projects 20:24:44 It is the TC which approves additions 20:24:57 (as a way to handle the communication with Defcore folks) 20:25:06 yup, approve 20:25:10 someone on the tc might even technically submit the patch to add something, based on discussion with the defcore folks 20:25:10 not propose 20:25:35 the point is that we don't want PTLs or project contributors to propose those sorts of patches 20:25:35 dhellmann: well, is that not in breach of the policy? 20:25:39 There is basically no point in proposing something that defcore is not interested to add 20:25:52 the previous working theory is that defcore / board knew what the market for trademark looked like 20:26:28 so they would be the best ones to initiate "we want this thing in the trademark" because either their users, or their vendors, wanted products with that feature stamped openstack 20:26:31 or at least should be the ones responsible for figuring it out if not 20:26:36 right 20:26:49 fungi : sdague : right 20:26:55 sdague: also they add projects far less often than we do :) 20:27:03 that's my understanding as well ^^ 20:27:10 like I said, the point is not that a patch is invalid because the wrong person submitted it. the point is to avoid extra work from folks who want the tag but don't understand the process. 20:27:34 for me, the enitire process was murky. asking in def-core I was told one thing (which was later clarified, but the inital reading looked like defcore was waiting for the TC to update), and then the policy said another 20:27:42 if we have to make a hard rule that only defcore committee members can submit the patch, that's not ideal but I could live with it 20:28:10 dhellmann: is that not what it says right now? 20:28:10 OK, so I think we can reject this change as it stands, and we'll consider other clarifications in the wording in the future if they are submitted 20:28:14 mugsie : yes, I think you're the first project to go through this process so I'm not surprised it's not fully understood 20:28:28 mugsie : I don't think we anticipated anyone saying the TC could not modify its own git repo. 20:28:41 ttx: I can give a shot at updating the document with the current understanding 20:28:49 I'll submit a patch tomorrow 20:28:50 obviously removing something from the list takes communication with defcore, too 20:29:08 ttx: ++ 20:29:09 sdague: you mean iterate on the same change ? 20:29:17 ttx: no, I'll do a new change 20:29:20 ore some new change ? 20:29:25 ok, so we can reject the current one 20:29:28 sdague thanks for doing that 20:29:47 anyone disagreeing on rejection of 368240 ? 20:30:46 #agreed https://review.openstack.org/#/c/368240/1 should be rejected, expecting another clarification to be proposed in the near future 20:31:03 I'll process it after I slept 20:31:09 #topic Mention where the metric rules are defined/used 20:31:14 #link https://review.openstack.org/342225 20:31:17 flaper87: want to lead this one ? 20:31:22 Sure 20:31:48 so, This patch should update these tags with what the teamstats script does 20:32:08 we've invested quite some time arguing on what should be the next step as new things about the behavior of the script were found 20:32:32 There are proposals to update the current wording, land this patch and then do further improvements to the script 20:32:43 and there's another proposal to just revert the whole thing 20:33:05 and a bunch of people who don't care enough either way to weigh in 20:33:09 (including me) 20:33:10 I personally think we should go with the first one as it should reflect the current status while we work on improving the script forward 20:33:12 ttx: right 20:33:18 we could also trim it down to just "This tag is applied based on the `tools/teamstats.py` script." 20:33:39 dhellmann: or that too, which I think was the first version of this patch 20:33:41 trying to explain what the script does in english is where we keep getting tripped up, because of vague words like "patch" 20:33:50 dhellmann: maybe we should add that we review the changes proposed by the script to check if they are reflecting reality 20:33:51 which is why I didn't want us to try to do that in english in the first place 20:33:58 ttx: sure 20:34:04 which is why flaper87's suggestion is preferable to me 20:34:20 yeah, I quite like just referring to the script, and noting the human element 20:34:43 johnthetubaguy: ++ 20:34:44 +1 20:34:44 flaper87 : do you want to do that now? 20:34:51 dhellmann: doing it as we speak 20:35:04 if there are no objections, we can just move on and revisit this on Open discussion 20:35:09 wfm 20:35:11 ok 20:35:20 #topic Write down OpenStack principles 20:35:26 #link https://review.openstack.org/357260 20:35:34 So... The new draft seems to have addressed most of the concerns around the "One OpenStack" principle 20:35:47 The only principle that seems potentially controversial at this stage (beyond just choice of words) is the "OpenStack First, Project Team Second, Company Third" one 20:36:00 eglynn / jaypipes seem to prefer to say that it's OK to represent company opinion, as long as you disclose it (using the 'hats' analogy) 20:36:13 I don't see that as being orthogonal to what's in there though. This principle just says that as leaders you're supposed to put the interests of OpenStack first. 20:36:22 Doesn't mean you can't represent/voice the interests of the company as well 20:36:40 So you should definitely explain why your company would prefer it differently, but in your vote, you're supposed to make the choice that is beneficial to OpenStack in case of conflicts of interests 20:36:41 Yeah, it's not "company never" 20:36:53 I'll try to rewrite the last sentence so that it's clearer 20:37:02 Hopefully that will solve it 20:37:12 As TC members, is there anything in the current draft that you think does not accurately represent our principles ? 20:37:21 Or something I should definitely try to catch on my next revision ? 20:37:29 Or something that would prevent you from +1ing it ? 20:37:36 FWIW I think the hats analogy better captures the more nuanced balancing of interests that goes on in reality (IIUC) 20:37:40 (as opposed to a strict 1,2,3 ordering) 20:37:43 ttx I had comments that I'd like in a new revision around the software aspect vs. API implementation 20:37:50 I honestly think its more about wording to stop miss read of the intent, it feels like we are all trying to point towards the same thing 20:37:58 eglynn: it's not as widespread as you think outside of Red Hat :) 20:38:13 johnthetubaguy: yeah 20:38:30 johnthetubaguy: precision which we can address in subsequent patchsets, too 20:38:38 ttx: thats a very good point 20:38:39 ttx: hmmm, I'll take that in jest 20:38:43 ttx one reason for -1 for API implementation would be that we can't really do anything about projects outside of OpenStack that implement an API, is that not a concern? It's possible it's not a concern because they don't call it OpenStack? 20:39:01 (heh lots of use of it_ 20:39:30 annegentle: you are your own grammar police 20:39:35 I certainly wore many "hats" at Citrix in a closed sourced world, maybe its UK + Ireland thing, we must love hats or something 20:39:37 what I mean is, do we stop Ceph implementing Object Storage API or do we not care? 20:39:50 and even can we stop anyone? :) 20:39:50 johnthetubaguy: I think it might be ... 20:39:56 anteaya some days I just can't English 20:40:02 johnthetubaguy: because all that rain :) 20:40:04 :) 20:40:06 annegentle : we don't care what they do as long as they don't say it's OpenStack 20:40:15 annegentle: ok, that's what I was wondering … is it that we don't want 3rd party implementations? or that you can't call yourself OpenStack if you use one? 20:40:25 eglynn: heh 20:40:26 dhellmann: ++ 20:40:32 dhellmann ok, that's fair enough then, maybe we should clearly state that as a principle "we don't care" 20:40:38 or that it only matters if it's a defcore-tested api? 20:40:46 annegentle, dtroyer_zz: right, the point of this principle is to reiterate our defcore response about designated sections 20:40:47 dtroyer_zz good question, I'm not sure myself. 20:40:56 annegentle: we don't care and can't do anything about what's done outside of openstack 20:41:00 ttx I put some suggested wording rather than just saying "no" at least :) 20:41:10 noone can stop third party implimentations 20:41:11 ttx I'd like that in before giving a +2 20:41:12 trademarks kick in for that right? 20:41:16 I like it because we say we ship software and not APIs, and its a nice expression of that 20:41:18 annegentle : I just replied to you on the review 20:41:28 s/APIs/API specs/ 20:41:38 annegentle: right, wanting to make sure I read the right questions :) 20:41:41 ok, so it feels like as far as TC members go, you could LIVE BY the current set, I just need to make a few more wording tweaks 20:41:43 johnthetubaguy yeah me too 20:41:44 I do feel like there is something missing here about do-acracy or something. 20:41:54 johnthetubaguy : right, that was one of the fundamental arguments when openstack started, was whether we deliver code or specs. 20:41:59 sdague:oooo... you are right 20:42:07 because there isn't a lot said here about the fact that people doing the work are the ones that should be making the decisions 20:42:08 sdague: easy to propose as a subsequent patch too 20:42:15 dhellmann: +1 20:42:44 sdague so, such as "code or it doesn't count" Yeah I could see that is relevant 20:42:50 sdague: though I could slip something about in in the representative democracy principle too 20:43:05 sdague: your spot on though, thats totally missing right now 20:43:13 sdague: though I think it warrants its own thing 20:43:14 ttx: you could, but I know a concern that was widely raised when I first joined was the invasion of astronaut architects 20:43:22 Let's nail down what is there and tack that on? else we'll keep iterating on the rest of this too 20:43:30 I'd say follow up patches, or we just keep adding to this patch every time we think of something 20:43:31 ttx, sdague : yeah, that's worth it's own point 20:43:34 sdague heh I was remembering the same session I think 20:43:35 dtroyer_zz : ++ 20:43:39 dtroyer_zz: yeah, definitely not looking forward a whole new one 20:43:45 ttx: sdague I'd probably leave it for a follow-up patch 20:43:46 and that it was really important the voices that had weight were the ones doing work 20:43:47 +1 to follow up patches jroll 20:43:54 this one has enough content, in my opinion 20:44:00 sdague : totally 20:44:01 I do think it's worth mentioning it 20:44:02 jroll: yeah, I think we should do that, I like flaper87's proposed add (well its direction) 20:44:12 johnthetubaguy: :) 20:44:16 ++ 20:44:26 OK, so I'll do a new revision to catch the latest wording suggestions. Then we'll try to approve it at next week meeting 20:44:33 ttx sounds good 20:44:36 and then we can start a subsequent patch fair 20:44:37 ttx: wfm 20:44:44 ++ 20:44:50 sounds like a plan ttx 20:44:54 we won't get it perfect the first time around. We never do 20:44:55 yeah, I think we need to get into iterate mode on this soon-ish 20:44:55 (shameless plug if ppl want to review the metrics patch https://review.openstack.org/#/c/342225/) 20:45:15 OK, let's move to open discussion, quite a bit to discuss there too 20:45:25 #topic Open discussion 20:45:34 #link https://review.openstack.org/#/c/342225/ Metrics patch 20:45:37 * flaper87 stfu 20:45:46 no no I was about to say that :) 20:45:55 flaper87: looks good, I expect 'verify it matches reality' to receive some interpretation though 20:46:14 dtroyer_zz: English, I'll eventually stop trying and go with the flow :P 20:46:36 Given the opposition on this patch, I don't feel comfortable approving it right away though 20:46:46 unless we can get the -1ers to approve it 20:46:58 that seems reasonable 20:47:00 it's fine, no need to rush it 20:47:24 if people -1 this, we should all just pack up and go home 20:47:27 :-p 20:47:28 ok, so, next open discussion topic 20:47:33 We have a load of missing PTLs: Astara, OpenStackSalt, OpenStack UX, Security 20:47:33 ttx, did anyone on tc even -1 it? 20:47:36 don't think so 20:47:39 russellb: inorite 20:47:48 I also prefer waiting for -1ers to read this version 20:47:48 russellb: you did not just throw down that gauntlet. 20:47:52 russellb: :P 20:47:56 I received a private email from Piet (UX) saying he waited until the last minute and experienced some issues posting his candidacy 20:48:11 ttx technical issues? 20:48:12 so the election repo UX failed the test 20:48:20 heh 20:48:22 has he posted it since then? 20:48:26 No news from the others though, which points to some significant level of disconnect with the community 20:48:27 Yeah - we ran into an issue, but definitely want to continue as PTL 20:48:41 so is it only Astara and OpenStackSalt we need to find potential people for? 20:48:48 There was an ML post by the Astara guy who got it in too late 20:48:49 I thought adam lawson posted to the mailing list about astara 20:48:49 or just retire them 20:48:53 usually when we publish the "oops you missed" list, people show up 20:48:55 astara also had a late submission 20:49:05 So, speaking of Astara 20:49:11 markmcclain: around ? 20:49:20 ttx: yes 20:49:30 markmcclain: could you give us the state there 20:49:44 #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/103943.html 20:49:57 I've been chatting with a few folks the last few days about Astara 20:51:04 we think it makes sense to remove the project from governance and let anyone who wants to take reorganize do so after it is outside of governance 20:51:13 I kind of feel like we should default to removing official status from projects that don't have PTLs show up 20:51:23 if it's a completely different team, then yes, it makes sense 20:51:23 and handle not doing that as an exception 20:51:46 tough to remove security from governance 20:51:46 sdague: I lean that way too 20:51:47 UX would get an exception this time, but the rest we should just take out of the fold 20:51:57 the main contributors have all scattered to different companies after Akanda wound down and I don't expect any holdovers 20:51:58 sdague: for example, I'm not sure we can't have anyone leading Security since the VMT depends on it 20:52:07 Rockyg: not really, it's basically just creating a couple of tools 20:52:10 Rockyg: they aren't the vulnerability management team, they are a different team 20:52:18 ttx: in which way? 20:52:31 I thought the whole point of them being different was they were different deliverables 20:52:34 anteaya: the VMT is now a subteam of Security 20:52:42 * dhellmann is surprised to learn that security and vmt are not the same team 20:52:42 ttx: ah sorry I missed that 20:52:50 oh, they are, nevermind 20:52:55 dhellmann: ish 20:53:05 the vmt moved from release management to security for better alignment 20:53:06 honestly, I would rather make VMT a top level team 20:53:18 but the vmt still operates as a completely autonomous entity 20:53:25 sdague: me too 20:53:28 I see 20:53:30 I feel like their output is measurable, the security team... less so 20:53:43 I'm willing to handle proposing the patches to remove Astara from governance and then help handoff to those who might be interested in reorganizing 20:53:54 markmcclain: ++ 20:53:55 markmcclain: that sounds great, thank you 20:53:58 markmcclain: thanks 20:54:00 markmcclain : what time-frame do you have in mind for that? 20:54:00 basically teh release management team wanted to stop being a catch-all, and since the security team had newly formed the vmt agreed to relocate there 20:54:01 markmcclain : ++ 20:54:14 fungi: sure, as a point in time it made sense 20:54:25 but I think we should just call the VMT an independent entity 20:54:28 So, we save UX since Piet reached out. We remove Astara to enable a clean hand-off 20:54:30 which is basically is 20:54:32 I was thinking of proposing it this week with goal of making official during first meeting of new TC term 20:54:38 Leaves us with Salt and Security 20:54:49 sdague: yeah, +1 20:54:50 that should give time for any community members to chime in 20:54:52 FWIW Salt also missed all of the emails about Design Summit allocation 20:55:01 i wouldn't object to the vmt being an officially independent official team, but we only have four members (until recently it was only 3) 20:55:15 and you know how many reminders I send 20:55:15 fungi: release isn't any bigger 20:55:17 this is the second salt team that disappeared, the first has modules in retirement 20:55:20 sdague: fair point 20:55:22 we once had the security team own/ review the Security Guide all the security, oh what are they called, reports? 20:55:29 +1 for a separate VMT team 20:55:47 annegentle, audits? 20:55:47 fungi: they co-publish on security.o.o, too 20:55:49 is there someone who would lead the vmt team that wouldn't be willing to lead the security team? 20:55:54 ttx: correct 20:56:09 dhellmann: there was never really much overlap 20:56:11 dhellmann: most of the vmt are not heavily involved in the rest of the security team's output 20:56:12 Should we rather have someone from the VMT take over Security PTLship ? 20:56:16 we're more... allied? 20:56:17 fungi : ok 20:56:28 that doesn't prevent them from doing their side of work 20:56:28 ah, OSSA, OpenStack Security Advisories. 20:56:30 ttx: no, we should just split it off 20:56:33 ttx: I think salt should be moved out of governance and left to its own devices 20:56:35 ttx: it sounds like no 20:56:42 +1 for the split 20:56:46 Nathaniel Dillon was who worked on the docs side 20:56:47 ttx: if someone picks up the work again, so be it 20:56:52 anteaya: ++ 20:56:55 (and prior PTL?) 20:56:56 maybe put a call on the mailing list for someone in the vmt to step up 20:57:07 thingee: +1 20:57:14 thingee +1 20:57:20 honestly, our focus should be on the folks doing the work, and not spending a lot of time shepharding and safeguarding people that don't show up 20:57:21 So, all those teams have design summit space 20:57:26 what do you need from me re: 20:57:27 I would rather the VMT just became its own thing 20:57:34 annegentle: right, the vmt generates ossa. there are a set of editors on the security team who generate ossn, which are like security advisories but more in the vein of recommendations. probably getting off-topic for a tc meeting but i'm happy to explain in greater detail later 20:57:37 sdague: ++ 20:57:43 would we just prevent those teams from meeting, too ? 20:57:48 ttx: oh, thats an interesting twist on the problem 20:57:55 ttx: I think it's fair to give up their slots 20:58:08 this is kind of fundamental failure to show up 20:58:08 ttx: the astara team wanted a slot to coordinate the hand-off, iiuc 20:58:14 or maybe reduce their allocation a bit 20:58:15 does the vmt as a separate autonomous team need a ptl? 20:58:26 dougwig : yes, it would 20:58:28 sdague: could be seen as the error of one person making a problem for a whole team 20:58:35 fwiw the security team's efforts are pretty cool, and they're reasonably active. i just don't know what's up with nobody stepping up to be ptl for them 20:58:36 piet_: stand by, so far just your presence at the meeting and your prior communication with ttx 20:58:52 ttx: reduce slots for them 20:58:54 dhellmann: i guess i'm challenging the notion that every little cross project team should have a "ptl". do the members of that team need weekly meetings and summit space, e.g.? 20:59:02 mugsie: yes, that was my idea 20:59:12 Reduce slot allocation 20:59:26 ttx: it could be, but again, all the time we spend chasing teams not showing up is time we're not spending on / with projects that are working hard 20:59:28 dougwig : from a governance perspective the important function of the PTL is to be the single-point-of-contact when all else fails. 20:59:28 if I flew in to BCN, and found no sessions I would be ... annoyed 20:59:31 anteaya What does the TC need from me to make sure I stay UX PTL? 20:59:38 So Salt would be down to one slot (which is what we try to give to unofficial projects in the pipeline of becoming official 20:59:45 piet_: I think you have done it, stand by 20:59:48 piet_: no, we'll make it happen 20:59:58 piet_: yay, congratulations 20:59:59 ttx Sweet 21:00:00 dougwig: the vmt only has one git repo (at the moment), and is pretty constrained at being around 3-4 members most likely indefinitely. it could probably just be considered a cross-project effort and not need to be an official anything as far as i'm concerned 21:00:28 fungi: right, if you want a PTL, go nuts. but it seems a heavyweight construct for one size fits all. 21:00:35 but i won't speak for the other three vmt members who don't seem to be in here at the moment 21:00:40 ttx anteaya For the record, we're doing some good stuff these days 21:00:40 OK, so I'll start a thread on retiring teams without PTLs (and reducing their summit allocation) and see how it falls 21:00:43 fungi : we could designate it a working group if you'd rather. I don't know if it has any contributors who wouldn't otherwise get to vote in the tc elections. 21:00:49 and our time of off 21:00:51 piet_: awesome! 21:00:53 is off 21:01:02 o/ 21:01:05 bye everyone 21:01:07 thanks ttx 21:01:09 dhellmann: i'm pretty sure we're all already atc on a consistent basis, so you're probably right 21:01:15 #action ttx to start a thread on retiring teams without PTLs (and reducing their summit allocation) and see how it falls 21:01:26 fungi : yeah, that's what I expected 21:01:28 #endmeeting