20:01:06 <ttx> #startmeeting tc
20:01:08 <openstack> 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 <openstack> 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 <openstack> The meeting name has been set to 'tc'
20:01:31 <sdague> o/
20:01:34 <ttx> Our agenda for today:
20:01:43 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:01:44 <thingee> o/
20:02:00 <ttx> (remember to use #info #idea and #link liberally to make for a more readable summary)
20:02:08 <ttx> #topic Update tags per the validate tags script
20:02:13 * Rockyg sneaks in a side door
20:02:14 <ttx> #link https://review.openstack.org/368086
20:02:18 <johnthetubaguy> o/
20:02:24 <ttx> Our semi-regular diversity tag updates
20:02:25 <dims> o/
20:02:36 <ttx> On the good side, OpenStack-Chef now has diverse-affiliation (thanks to WorkDay & CloudBau's involvement)
20:02:44 <ttx> and Murano is no longer single-vendor, thanks to 99cloud's involvement
20:02:54 <ttx> On the sad side, Telemetry lost its diverse-affiliation, and TripleO is now single-vendor
20:03:07 <ttx> We have enough votes and no objection to approve this now
20:03:14 <annegentle> #info  OpenStack-Chef now has diverse-affiliation (thanks to WorkDay & CloudBau's involvement)
20:03:20 <annegentle> #info Murano is no longer single-vendor, thanks to 99cloud's involvement
20:03:32 <annegentle> #info Telemetry lost its diverse-affiliation, and TripleO is now single-vendor
20:03:42 <flaper87> annegentle: NICE! thanks :D
20:03:46 * ttx approves
20:03:47 <annegentle> heh, copy/paste to success
20:04:14 <ttx> #topic Add Ocata goal split out tempest plugins
20:04:22 <ttx> #link https://review.openstack.org/369749
20:04:34 <ttx> mtreinish proposed this alternate goal for Ocata, I think it's a reasonable one
20:04:44 <ttx> The question is more, is the Ocata goal list still open at this stage
20:05:06 <ttx> 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 <ttx> Opinions ?
20:05:21 <flaper87> ttx: we probably don't need to be as strict with it as we just worked on this
20:05:23 <sdague> I think it's a good thing to do for sure
20:05:26 <dhellmann> yes, my only real concern with this is the timing
20:05:33 <anteaya> what is the consequence of not reaching the goal?
20:05:41 <flaper87> I mean, I'd be good to have it in Ocata if the plan sounds realistic for the Ocata timeframe
20:05:43 <ttx> dhellmann: what are the things taht are sticky to timing ?
20:05:57 <ttx> dhellmann: there is the cross-project workshop list
20:06:11 <ttx> and then there is the goal assessment deadline on the release schedule
20:06:16 <ttx> anything else ?
20:06:16 <sdague> 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 <dhellmann> 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 <amrith> 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 <mugsie> so, for most porject sthat have an in-tree plugin this should be simple enought to split out
20:06:55 <ttx> 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 <sdague> mugsie: yes, it's honestly all very mechanical
20:07:05 <mugsie> the issue is that it forces projects to make API changes compatible
20:07:12 <mugsie> which can slow down dev
20:07:16 <mugsie> but in turn helps users
20:07:18 <amrith> 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 <flaper87> 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 <sdague> mugsie: which is supposed to be a standard
20:07:29 <dhellmann> mugsie : right, that's a thing we want as a community
20:07:42 <mugsie> designate has it, and I think it is definitly the way forward
20:07:44 <ttx> anteaya: bad karma
20:07:46 <flaper87> mugsie: ++
20:07:53 <anteaya> ttx: okay, thank you
20:07:56 <annegentle> mugsie thanks for that
20:08:00 <mugsie> it has made us stop and think quite a few times
20:08:24 <sdague> jroll: tempest is a branchless model, so plugins in branches end up causing massive confusion
20:08:45 <mugsie> amrith: what weird tooling do you have for tempest?
20:08:51 <sdague> the plugin structions really need to mirror the consuming structure
20:09:04 <amrith> mugsie, read mtreinish' comment in the review
20:09:05 <sdague> 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 <johnthetubaguy> I like mtreinish's recent comments on why it needs splitting out
20:09:36 <mugsie> yeah, me too
20:09:45 <dougwig> 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 <johnthetubaguy> that was all news to me, and kinda makes sense
20:10:14 <dtroyer_zz> those comments need to be preserved, like johnthetubaguy pointed out, maybe added to the doc?
20:10:15 <ttx> ok, I don't think we can get to consensual state in the timeframe we have for Ocata goals
20:10:16 <mugsie> 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 <flaper87> dougwig: what about Depends-On, is that something projects are aware of and using ?
20:10:21 <jroll> sdague: yeah, I get it, I'm someone who has the plugin in-tree. not opposed, just not convinced yet
20:10:27 <johnthetubaguy> dtroyer_zz: yeah, I think it should be in the doc
20:10:39 <dhellmann> johnthetubaguy , dtroyer_zz : ++
20:11:04 <thingee> flaper87: +1
20:11:06 <dougwig> 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 <dhellmann> also the point about helping to ensure API compatibility is maintained should be added
20:11:11 <johnthetubaguy> depends-on is what makes this palatable I think
20:11:24 <sdague> dougwig: right, you can block on depends-on
20:11:30 <dougwig> depends-on doesn't work branchless, either.
20:11:42 <sdague> dougwig: yes it does
20:11:47 <dhellmann> it would be good to address the process questions dougwig is raising
20:11:51 <flaper87> dougwig: have you hit any issue?
20:12:03 <flaper87> dhellmann: perhaps something to also have as recommendation in the goal itself
20:12:06 <flaper87> mtreinish: ^
20:12:09 <dhellmann> flaper87 : yeah
20:12:12 <dhellmann> that's what I meant
20:12:14 <dougwig> oh?  my mind was just blown.  so a stable/mitaka commit can depend on a master commit?
20:12:19 <sdague> dougwig: yes
20:12:22 <dhellmann> dougwig : yes
20:12:23 <dougwig> oh, sweet.
20:12:53 <flaper87> dhellmann: a-ha, gotcha :D
20:13:07 <ttx> 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 <flaper87> I'm happy to help, fwiw
20:13:32 <flaper87> mtreinish: ^
20:13:35 <dhellmann> ttx: I'm skeptical, but I don't know how busy mtreinish is right now.
20:13:44 <ttx> I think that people like to resist goals and we need a /lot/ of time to pass them
20:13:47 <anteaya> he is at a sprint in germany this week
20:14:02 <johnthetubaguy> I was kinda expecting to approve a some goals post summit, it feels like this could be one of those
20:14:03 <mugsie> I think a lot of the work can be nearly coookie-cuttered
20:14:06 <dhellmann> we should make sure there's a cross-project session on this
20:14:23 <johnthetubaguy> dhellmann: in the goals session, or separate?
20:14:23 <dhellmann> mugsie : yeah, the work itself is going to be pretty mechanical. the bigger hurdle is convincing projects to actually do it.
20:14:30 <mugsie> dhellmann: yup
20:14:38 <ttx> johnthetubaguy: post-summit we'll start the process of approving Pike goals
20:14:43 <dhellmann> johnthetubaguy : if we need to dig into the details, it should have its own session
20:14:53 <dhellmann> johnthetubaguy : the goals session we have up now is supposed to be about the general process, right?
20:15:02 <annegentle> 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 <johnthetubaguy> dhellmann: yeah, I think thats the way I am leaning too, more just clarifying
20:15:14 <annegentle> and seems do-able by summit
20:15:18 <dhellmann> johnthetubaguy : ++
20:15:25 <annegentle> and at summit revisions as needed
20:15:31 <johnthetubaguy> #idea have a cross project session on tempest plugins and patterns
20:16:08 <jroll> 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 <ttx> 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 <flaper87> 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 <jroll> I agree easy to get done within a cycle, but it isn't trivial
20:16:36 <dhellmann> jroll : right, part of the pre-work for this will be to document a reliable process for the transition
20:16:50 <mugsie> ttx: I think Pike is a better goal, just based on timing
20:16:53 <annegentle> ttx part of the point of goals is to prioritize work
20:16:56 <dhellmann> ttx: unfortunately, I think that's the state we're in, yes.
20:17:03 <jroll> dhellmann: cool
20:17:04 <ttx> mugsie: yeah
20:17:07 <mugsie> for example I had no idea this was a thing until I ready the agenda this afternoon
20:17:08 <annegentle> ttx so if we think it's important enough, then we could prioritize it with discussion
20:17:12 <anteaya> the ocata goal could be to have this be a pike goal with documentation and process in place
20:17:26 <mugsie> so, ptls might like a longer heads up
20:17:34 <annegentle> yeah might be mugsie
20:17:35 <dims> ttx : yeah it probably late :(
20:17:40 <dhellmann> mugsie : ++
20:17:48 <ttx> mugsie: yeah, we can't just throw a new goal idea into the process so late
20:18:13 <ttx> #info A bit late to insert a new goal into the Ocata list (since Ocata just started)
20:18:17 <dhellmann> 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 <mugsie> but ++ for Pike
20:18:28 <dims> dhellmann ++
20:18:35 <sdague> so... another pike goal to think about for the list. All API services running under a non-eventlet webserver.
20:18:36 <ttx> #info let's make sure we discuss this in Barcelona in time for it to be a potential Pike goal
20:18:36 <amrith> 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 <annegentle> amrith yeah
20:19:05 <dims> amrith : reasonable to do that. +1
20:19:10 <dhellmann> 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 <mugsie> amrith: +1
20:19:14 <ttx> amrith: yes, that's part of the "too late" thing
20:19:17 <flaper87> amrith: I think this will be discussed in the ML anyway
20:19:21 <flaper87> what ttx said
20:19:23 <ttx> OK, I propose we move on
20:19:29 * flaper87 chose his words poorly
20:19:31 <dougwig> sdague: isn't eventlet py3 compatible now? i thought that was the only objection.
20:19:38 <amrith> thx flaper87 ttx.
20:19:59 <sdague> dougwig: no, it's not the only objection
20:20:01 <ttx> I think we have a way forward, and I'll summarize it on the review
20:20:09 <flaper87> ttx: thx
20:20:24 <ttx> #topic Update tc-approved-release application policy
20:20:27 <sdague> 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 <ttx> #link https://review.openstack.org/368240
20:20:50 <mugsie> #link https://review.openstack.org/#/c/368240/
20:20:57 <ttx> This change proposes to let anyone propose additions to the tc-approved-release tag
20:21:10 <ttx> 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 <ttx> 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 <ttx> Personally I see no reason to change that policy
20:21:41 <ttx> That said, this review raised interesting side-discussions.
20:21:52 <ttx> 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 <dhellmann> yes, we were careful to set this up to avoid lots of unnecessary discussion over this tag
20:22:04 <ttx> (as it overloads the tag meaning and makes it desirable outside of Defcore context)
20:22:12 <mugsie> Yeah, so bazsed on the discussion on the patch, I think I would be better capturing the discussion in the policy
20:22:20 <ttx> 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 <ttx> mugsie: would you like to propose a new change (or a new patchset) that would bring those clarifications ?
20:23:20 <mugsie> yeah, if there is agreement that there is confucsion, I will propose it
20:23:22 <ttx> I felt like the tag was sufficiently self-explaining, but it's easy to "improve"
20:23:37 <ttx> mugsie: where is the confusion, exactly ?
20:24:03 <ttx> around the usage of teh tag ?
20:24:05 <ttx> the*
20:24:16 <annegentle> yes, in the spirit of writing things down, what else do we need to write down?
20:24:18 <mugsie> 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 <ttx> It is the TC which approves additions
20:24:57 <ttx> (as a way to handle the communication with Defcore folks)
20:25:06 <mugsie> yup, approve
20:25:10 <dhellmann> someone on the tc might even technically submit the patch to add something, based on discussion with the defcore folks
20:25:10 <mugsie> not propose
20:25:35 <dhellmann> the point is that we don't want PTLs or project contributors to propose those sorts of patches
20:25:35 <mugsie> dhellmann: well, is that not in breach of the policy?
20:25:39 <ttx> There is basically no point in proposing something that defcore is not interested to add
20:25:52 <sdague> the previous working theory is that defcore / board knew what the market for trademark looked like
20:26:28 <sdague> 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 <fungi> or at least should be the ones responsible for figuring it out if not
20:26:36 <dhellmann> right
20:26:49 <dims> fungi : sdague : right
20:26:55 <ttx> sdague: also they add projects far less often than we do :)
20:27:03 <annegentle> that's my understanding as well ^^
20:27:10 <dhellmann> 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 <mugsie> 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 <dhellmann> 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 <mugsie> dhellmann: is that not what it says right now?
20:28:10 <ttx> 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 <dhellmann> 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 <dhellmann> mugsie : I don't think we anticipated anyone saying the TC could not modify its own git repo.
20:28:41 <sdague> ttx: I can give a shot at updating the document with the current understanding
20:28:49 <sdague> I'll submit a patch tomorrow
20:28:50 <dhellmann> obviously removing something from the list takes communication with defcore, too
20:29:08 <dhellmann> ttx: ++
20:29:09 <ttx> sdague: you mean iterate on the same change ?
20:29:17 <sdague> ttx: no, I'll do a new change
20:29:20 <ttx> ore some new change ?
20:29:25 <ttx> ok, so we can reject the current one
20:29:28 <annegentle> sdague thanks for doing that
20:29:47 <ttx> anyone disagreeing on rejection of 368240 ?
20:30:46 <ttx> #agreed https://review.openstack.org/#/c/368240/1 should be rejected, expecting another clarification to be proposed in the near future
20:31:03 <ttx> I'll process it after I slept
20:31:09 <ttx> #topic Mention where the metric rules are defined/used
20:31:14 <ttx> #link https://review.openstack.org/342225
20:31:17 <ttx> flaper87: want to lead this one ?
20:31:22 <flaper87> Sure
20:31:48 <flaper87> so, This patch should update these tags with what the teamstats script does
20:32:08 <flaper87> 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 <flaper87> There are proposals to update the current wording, land this patch and then do further improvements to the script
20:32:43 <flaper87> and there's another proposal to just revert the whole thing
20:33:05 <ttx> and a bunch of people who don't care enough either way to weigh in
20:33:09 <ttx> (including me)
20:33:10 <flaper87> 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 <flaper87> ttx: right
20:33:18 <dhellmann> we could also trim it down to just "This tag is applied based on the `tools/teamstats.py` script."
20:33:39 <flaper87> dhellmann: or that too, which I think was the first version of this patch
20:33:41 <dhellmann> 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 <ttx> dhellmann: maybe we should add that we review the changes proposed by the script to check if they are reflecting reality
20:33:51 <dhellmann> which is why I didn't want us to try to do that in english in the first place
20:33:58 <dhellmann> ttx: sure
20:34:04 <dtroyer_zz> which is why flaper87's suggestion is preferable to me
20:34:20 <johnthetubaguy> yeah, I quite like just referring to the script, and noting the human element
20:34:43 <ttx> johnthetubaguy: ++
20:34:44 <thingee> +1
20:34:44 <dhellmann> flaper87 : do you want to do that now?
20:34:51 <flaper87> dhellmann: doing it as we speak
20:35:04 <flaper87> if there are no objections, we can just move on and revisit this on Open discussion
20:35:09 <dhellmann> wfm
20:35:11 <ttx> ok
20:35:20 <ttx> #topic Write down OpenStack principles
20:35:26 <ttx> #link https://review.openstack.org/357260
20:35:34 <ttx> So... The new draft seems to have addressed most of the concerns around the "One OpenStack" principle
20:35:47 <ttx> 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 <ttx> 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 <ttx> 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 <ttx> Doesn't mean you can't represent/voice the interests of the company as well
20:36:40 <ttx> 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 <edleafe> Yeah, it's not "company never"
20:36:53 <ttx> I'll try to rewrite the last sentence so that it's clearer
20:37:02 <ttx> Hopefully that will solve it
20:37:12 <ttx> As TC members, is there anything in the current draft that you think does not accurately represent our principles ?
20:37:21 <ttx> Or something I should definitely try to catch on my next revision ?
20:37:29 <ttx> Or something that would prevent you from +1ing it ?
20:37:36 <eglynn> FWIW I think the hats analogy better captures the more nuanced balancing of interests that goes on in reality (IIUC)
20:37:40 <eglynn> (as opposed to a strict 1,2,3 ordering)
20:37:43 <annegentle> ttx I had comments that I'd like in a new revision around the software aspect vs. API implementation
20:37:50 <johnthetubaguy> 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 <ttx> eglynn: it's not as widespread as you think outside of Red Hat :)
20:38:13 <ttx> johnthetubaguy: yeah
20:38:30 <ttx> johnthetubaguy: precision which we can address in subsequent patchsets, too
20:38:38 <johnthetubaguy> ttx: thats a very good point
20:38:39 <eglynn> ttx: hmmm, I'll take that in jest
20:38:43 <annegentle> 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 <annegentle> (heh lots of use of it_
20:39:30 <anteaya> annegentle: you are your own grammar police
20:39:35 <johnthetubaguy> 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 <annegentle> what I mean is, do we stop Ceph implementing Object Storage API or do we not care?
20:39:50 <annegentle> and even can we stop anyone? :)
20:39:50 <mugsie> johnthetubaguy: I think it might be ...
20:39:56 <annegentle> anteaya some days I just can't English
20:40:02 <eglynn> johnthetubaguy: because all that rain :)
20:40:04 <anteaya> :)
20:40:06 <dhellmann> annegentle : we don't care what they do as long as they don't say it's OpenStack
20:40:15 <dtroyer_zz> 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 <johnthetubaguy> eglynn: heh
20:40:26 <flaper87> dhellmann: ++
20:40:32 <annegentle> dhellmann ok, that's fair enough then, maybe we should clearly state that as a principle "we don't care"
20:40:38 <dtroyer_zz> or that it only matters if it's a defcore-tested api?
20:40:46 <dhellmann> annegentle, dtroyer_zz: right, the point of this principle is to reiterate our defcore response about designated sections
20:40:47 <annegentle> dtroyer_zz good question, I'm not sure myself.
20:40:56 <ttx> annegentle: we don't care and can't do anything about what's done outside of openstack
20:41:00 <annegentle> ttx I put some suggested wording rather than just saying "no" at least :)
20:41:10 <anteaya> noone can stop third party implimentations
20:41:11 <annegentle> ttx I'd like that in before giving a +2
20:41:12 <dims> trademarks kick in for that right?
20:41:16 <johnthetubaguy> I like it because we say we ship software and not APIs, and its a nice expression of that
20:41:18 <dhellmann> annegentle : I just replied to you on the review
20:41:28 <johnthetubaguy> s/APIs/API specs/
20:41:38 <dtroyer_zz> annegentle: right, wanting to make sure I read the right questions :)
20:41:41 <ttx> 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 <annegentle> johnthetubaguy yeah me too
20:41:44 <sdague> I do feel like there is something missing here about do-acracy or something.
20:41:54 <dhellmann> johnthetubaguy : right, that was one of the fundamental arguments when openstack started, was whether we deliver code or specs.
20:41:59 <johnthetubaguy> sdague:oooo... you are right
20:42:07 <sdague> 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 <ttx> sdague: easy to propose as a subsequent patch too
20:42:15 <johnthetubaguy> dhellmann: +1
20:42:44 <annegentle> sdague so, such as "code or it doesn't count" Yeah I could see that is relevant
20:42:50 <ttx> sdague: though I could slip something about in in the representative democracy principle too
20:43:05 <johnthetubaguy> sdague: your spot on though, thats totally missing right now
20:43:13 <ttx> sdague: though I think it warrants its own thing
20:43:14 <sdague> 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 <dtroyer_zz> 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 <jroll> I'd say follow up patches, or we just keep adding to this patch every time we think of something
20:43:31 <dhellmann> ttx, sdague : yeah, that's worth it's own point
20:43:34 <annegentle> sdague heh I was remembering the same session I think
20:43:35 <dhellmann> dtroyer_zz : ++
20:43:39 <ttx> dtroyer_zz: yeah, definitely not looking forward a whole new one
20:43:45 <flaper87> ttx: sdague I'd probably leave it for a follow-up patch
20:43:46 <sdague> and that it was really important the voices that had weight were the ones doing work
20:43:47 <dims> +1 to follow up patches jroll
20:43:54 <flaper87> this one has enough content, in my opinion
20:44:00 <dims> sdague : totally
20:44:01 <flaper87> I do think it's worth mentioning it
20:44:02 <johnthetubaguy> jroll: yeah, I think we should do that, I like flaper87's proposed add (well its direction)
20:44:12 <flaper87> johnthetubaguy: :)
20:44:16 <jroll> ++
20:44:26 <ttx> 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 <annegentle> ttx sounds good
20:44:36 <ttx> and then we can start a subsequent patch fair
20:44:37 <flaper87> ttx: wfm
20:44:44 <dtroyer_zz> ++
20:44:50 <dims> sounds like a plan ttx
20:44:54 <ttx> we won't get it perfect the first time around. We never do
20:44:55 <johnthetubaguy> yeah, I think we need to get into iterate mode on this soon-ish
20:44:55 <flaper87> (shameless plug if ppl want to review the metrics patch https://review.openstack.org/#/c/342225/)
20:45:15 <ttx> OK, let's move to open discussion, quite a bit to discuss there too
20:45:25 <ttx> #topic Open discussion
20:45:34 <flaper87> #link https://review.openstack.org/#/c/342225/ Metrics patch
20:45:37 * flaper87 stfu
20:45:46 <ttx> no no I was about to say that :)
20:45:55 <dtroyer_zz> flaper87: looks good, I expect 'verify it matches reality' to receive some interpretation though
20:46:14 <flaper87> dtroyer_zz: English, I'll eventually stop trying and go with the flow :P
20:46:36 <ttx> Given the opposition on this patch, I don't feel comfortable approving it right away though
20:46:46 <ttx> unless we can get the -1ers to approve it
20:46:58 <dhellmann> that seems reasonable
20:47:00 <flaper87> it's fine, no need to rush it
20:47:24 <russellb> if people -1 this, we should all just pack up and go home
20:47:27 <russellb> :-p
20:47:28 <ttx> ok, so, next open discussion topic
20:47:33 <ttx> We have a load of missing PTLs: Astara, OpenStackSalt, OpenStack UX, Security
20:47:33 <amrith> ttx, did anyone on tc even -1 it?
20:47:36 <amrith> don't think so
20:47:39 <ttx> russellb: inorite
20:47:48 <flaper87> I also prefer waiting for -1ers to read this version
20:47:48 <dougwig> russellb: you did not just throw down that gauntlet.
20:47:52 <flaper87> russellb: :P
20:47:56 <ttx> 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 <anteaya> ttx technical issues?
20:48:12 <ttx> so the election repo UX failed the test
20:48:20 <annegentle> heh
20:48:22 <dhellmann> has he posted it since then?
20:48:26 <ttx> No news from the others though, which points to some significant level of disconnect with the community
20:48:27 <piet_> Yeah - we ran into an issue, but definitely want to continue as PTL
20:48:41 <annegentle> so is it only Astara and OpenStackSalt we need to find potential people for?
20:48:48 <Rockyg> There was an ML post by the Astara guy who got it in too late
20:48:49 <anteaya> I thought adam lawson posted to the mailing list about astara
20:48:49 <sdague> or just retire them
20:48:53 <ttx> usually when we publish the "oops you missed" list, people show up
20:48:55 <jroll> astara also had a late submission
20:49:05 <ttx> So, speaking of Astara
20:49:11 <ttx> markmcclain: around ?
20:49:20 <markmcclain> ttx: yes
20:49:30 <ttx> markmcclain: could you give us the state there
20:49:44 <anteaya> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/103943.html
20:49:57 <markmcclain> I've been chatting with a few folks the last few days about Astara
20:51:04 <markmcclain> 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 <sdague> I kind of feel like we should default to removing official status from projects that don't have PTLs show up
20:51:23 <ttx> if it's a completely different team, then yes, it makes sense
20:51:23 <sdague> and handle not doing that as an exception
20:51:46 <Rockyg> tough to remove security from governance
20:51:46 <jroll> sdague: I lean that way too
20:51:47 <sdague> UX would get an exception this time, but the rest we should just take out of the fold
20:51:57 <markmcclain> the main contributors have all scattered to different companies after Akanda wound down and I don't expect any holdovers
20:51:58 <ttx> sdague: for example, I'm not sure we can't have anyone leading Security since the VMT depends on it
20:52:07 <sdague> Rockyg: not really, it's basically just creating a couple of tools
20:52:10 <anteaya> Rockyg: they aren't the vulnerability management team, they are a different team
20:52:18 <sdague> ttx: in which way?
20:52:31 <sdague> I thought the whole point of them being different was they were different deliverables
20:52:34 <ttx> 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 <anteaya> ttx: ah sorry I missed that
20:52:50 <dhellmann> oh, they are, nevermind
20:52:55 <sdague> dhellmann: ish
20:53:05 <fungi> the vmt moved from release management to security for better alignment
20:53:06 <sdague> honestly, I would rather make VMT a top level team
20:53:18 <fungi> but the vmt still operates as a completely autonomous entity
20:53:25 <anteaya> sdague: me too
20:53:28 <dhellmann> I see
20:53:30 <sdague> I feel like their output is measurable, the security team... less so
20:53:43 <markmcclain> 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 <ttx> markmcclain: ++
20:53:55 <sdague> markmcclain: that sounds great, thank you
20:53:58 <dtroyer_zz> markmcclain: thanks
20:54:00 <dhellmann> markmcclain : what time-frame do you have in mind for that?
20:54:00 <fungi> 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 <dims> markmcclain : ++
20:54:14 <sdague> fungi: sure, as a point in time it made sense
20:54:25 <sdague> but I think we should just call the VMT an independent entity
20:54:28 <ttx> So, we save UX since Piet reached out. We remove Astara to enable a clean hand-off
20:54:30 <sdague> which is basically is
20:54:32 <markmcclain> I was thinking of proposing it this week with goal of making official during first meeting of new TC term
20:54:38 <ttx> Leaves us with Salt and Security
20:54:49 <jroll> sdague: yeah, +1
20:54:50 <markmcclain> that should give time for any community members to chime in
20:54:52 <ttx> FWIW Salt also missed all of the emails about Design Summit allocation
20:55:01 <fungi> 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 <ttx> and you know how many reminders I send
20:55:15 <sdague> fungi: release isn't any bigger
20:55:17 <anteaya> this is the second salt team that disappeared, the first has modules in retirement
20:55:20 <fungi> sdague: fair point
20:55:22 <annegentle> we once had the security team own/ review the Security Guide all the security, oh what are they called, reports?
20:55:29 <johnthetubaguy> +1 for a separate VMT team
20:55:47 <Rockyg> annegentle, audits?
20:55:47 <ttx> fungi: they co-publish on security.o.o, too
20:55:49 <dhellmann> is there someone who would lead the vmt team that wouldn't be willing to lead the security team?
20:55:54 <fungi> ttx: correct
20:56:09 <sdague> dhellmann: there was never really much overlap
20:56:11 <fungi> dhellmann: most of the vmt are not heavily involved in the rest of the security team's output
20:56:12 <ttx> Should we rather have someone from the VMT take over Security PTLship ?
20:56:16 <fungi> we're more... allied?
20:56:17 <dhellmann> fungi : ok
20:56:28 <ttx> that doesn't prevent them from doing their side of work
20:56:28 <annegentle> ah, OSSA, OpenStack Security Advisories.
20:56:30 <sdague> ttx: no, we should just split it off
20:56:33 <anteaya> ttx: I think salt should be moved out of governance and left to its own devices
20:56:35 <dhellmann> ttx: it sounds like no
20:56:42 <johnthetubaguy> +1 for the split
20:56:46 <annegentle> Nathaniel Dillon was who worked on the docs side
20:56:47 <anteaya> ttx: if someone picks up the work again, so be it
20:56:52 <sdague> anteaya: ++
20:56:55 <annegentle> (and prior PTL?)
20:56:56 <thingee> maybe put a call on the mailing list for someone in the vmt to step up
20:57:07 <flaper87> thingee: +1
20:57:14 <dims> thingee +1
20:57:20 <sdague> 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 <ttx> So, all those teams have design summit space
20:57:26 <piet_> what do you need from me re:
20:57:27 <johnthetubaguy> I would rather the VMT just became its own thing
20:57:34 <fungi> 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 <anteaya> sdague: ++
20:57:43 <ttx> would we just prevent those teams from meeting, too ?
20:57:48 <johnthetubaguy> ttx: oh, thats an interesting twist on the problem
20:57:55 <sdague> ttx: I think it's fair to give up their slots
20:58:08 <sdague> this is kind of fundamental failure to show up
20:58:08 <dhellmann> ttx: the astara team wanted a slot to coordinate the hand-off, iiuc
20:58:14 <ttx> or maybe reduce their allocation a bit
20:58:15 <dougwig> does the vmt as a separate autonomous team need a ptl?
20:58:26 <dhellmann> dougwig : yes, it would
20:58:28 <ttx> sdague: could be seen as the error of one person making a problem for a whole team
20:58:35 <fungi> 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 <anteaya> piet_: stand by, so far just your presence at the meeting and your prior communication with ttx
20:58:52 <mugsie> ttx: reduce slots for them
20:58:54 <dougwig> 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 <ttx> mugsie: yes, that was my idea
20:59:12 <ttx> Reduce slot allocation
20:59:26 <sdague> 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 <dhellmann> 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 <mugsie> if I flew in to BCN, and found no sessions I would be ... annoyed
20:59:31 <piet_> anteaya What does the TC need from me to make sure I stay UX PTL?
20:59:38 <ttx> 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 <anteaya> piet_: I think you have done it, stand by
20:59:48 <ttx> piet_: no, we'll make it happen
20:59:58 <anteaya> piet_: yay, congratulations
20:59:59 <piet_> ttx Sweet
21:00:00 <fungi> 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 <dougwig> fungi: right, if you want a PTL, go nuts. but it seems a heavyweight construct for one size fits all.
21:00:35 <fungi> 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 <piet_> ttx anteaya For the record, we're doing some good stuff these days
21:00:40 <ttx> 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 <dhellmann> 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 <ttx> and our time of off
21:00:51 <anteaya> piet_: awesome!
21:00:53 <ttx> is off
21:01:02 <flaper87> o/
21:01:05 <flaper87> bye everyone
21:01:07 <jroll> thanks ttx
21:01:09 <fungi> dhellmann: i'm pretty sure we're all already atc on a consistent basis, so you're probably right
21:01:15 <ttx> #action ttx to start a thread on retiring teams without PTLs (and reducing their summit allocation) and see how it falls
21:01:26 <dhellmann> fungi : yeah, that's what I expected
21:01:28 <ttx> #endmeeting