20:03:04 <ttx> #startmeeting tc
20:03:05 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:09 <openstack> The meeting name has been set to 'tc'
20:03:13 <flaper87> o/
20:03:20 <ttx> Our agenda for today:
20:03:24 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:31 <ttx> #topic Half-cycle introspection on "things the TC should be working on"
20:03:34 <jaypipes> o/ :)
20:03:38 <ttx> (Timeboxing this to 30 minutes)
20:03:42 * Rockyg lurks 2
20:03:43 <ttx> So... we are at about half of Liberty
20:03:58 <ttx> 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 <ttx> 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 <ttx> So... what should we be working on ? And how to make any of it happen in the second half of Liberty ?
20:04:51 <ttx> 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 <ttx> 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 <ttx> (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 <ttx> We created workgroups to start addressing real issues, like the Project Team Guide workgroup to address the loss of common culture.
20:05:34 <ttx> jaypipes: you're special :)
20:05:38 * devananda recalls saying lots of aspiration things for others to do :)
20:05:44 <ttx> I'd say we should create more, hopefully as a result of this discussion
20:05:48 <russellb> 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 <sdague> the thing I'd really like to figure out how to make progress on is service catalog standardization
20:06:06 <ttx> 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 <annegentle> sdague: +1
20:06:10 <devananda> sdague: ++
20:06:15 <jaypipes> sdague: ++
20:06:19 <sdague> we had a CP session at summit, but it sort of petered out
20:06:25 <dhellmann> we have several cross-project specs that seem to be languishing
20:06:33 <ttx> #info we should figure out how to make progress on is service catalog standardization
20:06:46 <sdague> and there is a ton of weird code all the projects carry around because they barely acknowledge SC exists
20:06:49 <annegentle> are cross-project specs the "start addressing real issues" area?
20:06:52 <ttx> dhellmann: yes, we don't seem to have a good dynamic on that
20:07:10 <annegentle> or is a better example "help glance land code?" or?
20:07:20 <ttx> annegentle: not necessarily. For example to address culture issues we set up a workgroup to write the project team guide
20:07:42 <ttx> annegentle: yes, that would be a good example
20:07:48 <annegentle> ttx: ok, yep. And we set up communications working group.
20:07:53 <sdague> 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 <sdague> I think people are going to cp-spec first and just making a new bottleneck
20:08:25 <annegentle> sdague: I think they're useful for agreement/details, but yeah could be just a new place to argue?
20:08:40 <ttx> 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 <sdague> the whole cors thing probably didn't need to be a cp-spec, for instance.
20:08:47 <dhellmann> 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 <sdague> dhellmann: ok
20:08:54 <ttx> if people raised more random topics for the cross-project meetign we wxouldn't need them as much
20:08:55 <dhellmann> the request-id thing, for example
20:09:12 <markmcclain> ttx: agreed
20:09:34 <sdague> 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 <sdague> ttx: yeh, or that
20:09:51 <annegentle> sdague: there's soo much ML too though.
20:09:57 <russellb> annegentle: +1 ..
20:10:14 <dhellmann> sdague: that has been tried, too, and didn't really help either.
20:10:17 <ttx> sdague: Usually the cross-project meeting discussion is the escalation step when the thread goes nowhere
20:10:38 <ttx> but nowadays people give up on the thread and don't push for cross-project discussion
20:11:06 <sdague> ok, well, I guess that's a thing. How do we do actual cross project things?
20:11:06 <ttx> 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 <markmcclain> +
20:12:22 <ttx> 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 <annegentle> 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 <markmcclain> yeah cross project communication was one of the things I wanted to work on
20:13:02 <dhellmann> ttx, markmcclain : ++
20:13:12 <ttx> #info cross project communication (specs/meeting/discussions) is one of the things we should try to work on
20:13:36 <sdague> 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 <annegentle> task assignment, how does that work on cross project plans?
20:14:06 <ttx> 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 <annegentle> 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 <ttx> At least with the chair rotation I guess the project became more visible
20:14:26 <ttx> s/project/issue/
20:14:28 <dhellmann> yeah, I'm not convinced the meeting is going to solve that problem.
20:14:33 <sdague> dhellmann: agreed
20:15:05 <dhellmann> as annegentle and sdague were saying, we need some sort of ownership structure for these things
20:15:09 <ttx> 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 <flaper87> sorry, I had to step out a bit
20:15:20 * flaper87 quickly reads the backlog
20:15:21 <sdague> 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 <dhellmann> ttx: absolutely, I'm not saying get rid of it, just that it's not enough on its own
20:15:43 <sdague> service catalog might be a good thing to use as a unit test
20:15:48 <dhellmann> 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 <ttx> 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 <flaper87> 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 <sdague> dhellmann: yeh
20:16:10 <flaper87> And I feel bad about it but I get why it's that way
20:16:32 <dhellmann> 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 <ttx> 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 <ttx> dhellmann: sure, if ML is silent it's an easy call
20:17:15 <ttx> dhellmann: it's when the discussion doesn't reach consensus that we have a problem
20:18:09 <ttx> Technical discussions are like lasagna. You need to layer ML threads and IRC discussions to reach consensus
20:18:30 <Rockyg> ttx: ooh, nice analogy!
20:18:49 * flaper87 wants to bring the cinder HA thread as an example
20:19:01 <ttx> flaper87: I was hoping you would bring lasagna instead
20:19:13 <flaper87> ttx: I can do that
20:19:15 <flaper87> :D
20:19:16 <dhellmann> if we look at the open specs:
20:19:16 <dhellmann> "Uniform public methods for clietns" looks like we have consensus not to do this;
20:19:32 <dhellmann> "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 <dhellmann> "Return request ID to caller" has *finally* reached consensus, thanks to lifeless pushing on it
20:20:00 <annegentle> nice work lifeless
20:20:09 <dhellmann> "resource retrieving improvement: support change-since filter" has very little input
20:20:34 <russellb> dhellmann: that one doesn't seem like a good cp spec
20:20:38 <sdague> dhellmann: that last one also has api-wg thing bumping around on it which is confusing
20:20:45 <dhellmann> "Adds starting discussion spec for Service Catalog updates" has some approval, but some changes requested
20:20:58 <dhellmann> "Replace eventlet + monkey-patching with ??" has languished
20:21:05 <dhellmann> without clear consensus or work
20:21:29 <ttx> Another set of problems is when project teams go wrong in their silo and need an external intervention to be fixed
20:21:36 <dhellmann> "Add asynchronous user event support to OpenStack" looks like a new project someone should start and not a cp spec
20:21:38 <ttx> 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 <dhellmann> "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 <dhellmann> "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 <ttx> OK, so I #infoed two areas we could focus on during the second half
20:23:23 <dhellmann> "Cross-Project Policies" might be replaced by something newer
20:23:29 <sdague> I suspect that who showed up for osprofiler session was somewhat self selecting, which would explain that split
20:23:38 <ttx> Any other problems OpenStack is facing right now that we should be helping to fix ?
20:23:44 <ttx> sdague: yeah, that would be my take
20:23:52 <dhellmann> sdague: it wasn't a session, it was conversations throughout the week
20:24:09 <dhellmann> 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 <annegentle> 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 <sdague> 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 <sdague> so there is no where to synchronize
20:25:12 <russellb> no, i still think ML is best
20:25:18 <russellb> it's the most inclusive place to discuss
20:25:32 <annegentle> 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 <dhellmann> "most inclusive"?
20:25:37 <ttx> sdague: should definitely be discussed on ML first and a spec written only of necessary
20:25:37 <russellb> easiest to participate
20:25:44 <russellb> compared to irc meetings, where TZ is a problem
20:25:44 <ttx> if*
20:25:58 <annegentle> asynchronous is easier to participate in
20:26:00 <flaper87> The problem with the ML is that discussions *always* digress
20:26:12 <flaper87> keeping them on track is really hard
20:26:17 <ttx> flaper87: maybe we should push back on digressions
20:26:20 <sdague> flaper87: so, can we fix that problem, calling people out for going off topic?
20:26:26 <ttx> like off-topic, start your own thread
20:26:26 <clarkb> there are also too many of them to follow at one time
20:26:30 <jeblair> yes, it is hard, because everyone wants to have their say
20:26:37 <clarkb> its easier to be focused in a thing that looks like a meeting
20:26:42 <flaper87> sdague: I believe we do already but we're too many :P
20:26:47 <jeblair> and yeah, i think the only solution to that is to try to change the culture and push on digressions
20:26:55 <Rockyg> clarkb: ++
20:26:57 <flaper87> I don't see that issue as a blocker for using ML
20:27:01 <flaper87> but it's a real issue
20:27:05 <jeblair> it's a lot of work
20:27:29 <flaper87> it is
20:27:39 <dhellmann> 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 <annegentle> no no I think specs repo is super valuable
20:28:04 <ttx> dhellmann: I think we are suggesting people interested in discussing that should have a longer meetign about it
20:28:10 <sdague> dhellmann: honestly, I would suggest that
20:28:32 <annegentle> ttx: how do you ensure an outcome, have TC facilitators?
20:28:37 <russellb> i think specs are valuable for cases where clear project-wide consensus needs to be clearly documented
20:28:45 <annegentle> You need a decision maker otherwise people just flail for a while.
20:28:48 <flaper87> I would prefer doing both. We need a place where the final consensus gets written down and reviewed
20:28:52 <annegentle> russellb: agreed
20:28:53 <russellb> i need to be better at looking at them though ...
20:28:53 <ttx> annegentle: we coudl reuse the workgroup foirmat and have some cross-project comm workgroup
20:28:57 <russellb> sounds like that applies to several people
20:29:07 <sdague> russellb: right, but it's much easier to sketch on the list or in an etherpad
20:29:16 <russellb> yep
20:29:18 <flaper87> 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 <dhellmann> ttx: would it be better to have a wg per initiative?
20:29:33 <Rockyg> 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 <sdague> ttx: so I think the issue is that there are meeting people, and there are ML people.
20:30:08 <annegentle> sdague: stylistic preferences, yeah...
20:30:11 <sdague> 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 <ttx> I do both
20:30:25 <ttx> (lasagna)
20:30:25 <annegentle> sdague: but again points to a need for "final" decision making
20:30:43 <annegentle> arbitration, whatever it is.
20:30:56 <ttx> OK, time is mostly up, what's the next step on that ? Workgroup meeting ? ML thread ?
20:31:01 <flaper87> 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 <sdague> 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 <ttx> I want to make sure we discuss it again before mid-Mitaka
20:31:35 <flaper87> ML brings more attention and it's for async communications
20:31:47 <annegentle> sdague: yeah, service catalog is more about chasing the final outcomes
20:32:22 <sdague> 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 <dhellmann> 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 <annegentle> sdague: yeah, I feel like it should have been me, but I haven't chase
20:33:12 <annegentle> chased
20:33:24 <ttx> so.. keep using ML+Specs and cross-project meetings the way we currently do ?
20:33:30 <dhellmann> 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 <ttx> anyway, time is up. If someone has a suggestion for change, I guess step 1 is a ML thread
20:33:53 <sdague> 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 <flaper87> dhellmann: ++
20:33:55 <annegentle> ttx: I feel like there's something else about midcycles and inperson meetings
20:34:04 <sdague> because a group tends to assume someone else is doing it
20:34:12 <annegentle> sdague: ayup
20:34:13 <Rockyg> dhellmann, ++
20:34:18 <dhellmann> 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 <sdague> so I think basically anything we sanction out of the TC as important should have step 0, determine point person
20:34:34 <annegentle> 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 <dhellmann> sdague: definitely
20:34:50 <sdague> annegentle: honestly, I don't think so
20:34:55 <annegentle> sdague: ok, whew :)
20:35:01 <ttx> ok, moving on
20:35:09 <annegentle> timebox!
20:35:11 <russellb> needing a point person applies to just about anything anywhere
20:35:15 <ttx> we have a few items to cover
20:35:18 <ttx> #topic Adds Debian & derivatives packaging to OpenStack
20:35:26 <ttx> #link https://review.openstack.org/185187
20:35:31 <russellb> i had a mission statement concern, but generally +1
20:35:36 <ttx> This was recently updated
20:36:07 <russellb> not sure how baked this is, but whatever, the rpm one wasn't super baked either
20:36:58 <ttx> that mission statement concern is valid
20:37:01 <russellb> mission statement seems to encode a gating strategy that i'm not sure i agree with
20:37:07 <sdague> russellb: yeh, agree
20:37:26 <ttx> question is, do we require than it's changed to merge it, or should we just propose an adjustment
20:37:28 <annegentle> russellb: ah good point
20:37:30 <ttx> as a subsequent change
20:37:37 <sdague> 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 <russellb> i'd rather it be changed before approving
20:37:47 <russellb> personally
20:37:47 <ttx> that's fair
20:37:55 <jeblair> russellb, sdague: agreed
20:37:56 <jaypipes> zigo: here?
20:38:01 <jeblair> would +1 without the long-term goal
20:38:11 <jaypipes> russellb: yep, agreed. plus I think there's a typo in there.
20:38:27 <ttx> Let's move on and come back to this if zigo appears
20:38:28 <jaypipes> russellb: I don't think deb-mural is the right deliverable name ;)
20:38:35 <russellb> heh
20:38:38 <ttx> murallo
20:38:44 <jeblair> jaypipes READ the patch!
20:38:51 <russellb> jeblair: woah
20:38:55 <russellb> i read the top part :)
20:39:07 <ttx> #topic Kolla application for Big Tent
20:39:09 <ttx> #link https://review.openstack.org/206789
20:39:13 <ttx> This one looks pretty straightforward, especially with all the other packaging initiatives in
20:39:44 <russellb> i've followed the OSAD concerns
20:39:53 <jaypipes> jeblair: ?
20:39:53 <russellb> but i'm really not personally too concerned with overlap at this level
20:39:59 <russellb> jaypipes: past tense
20:40:04 <russellb> jaypipes: joking that you actually read it
20:40:07 <jaypipes> ahhh
20:40:10 <jeblair> jaypipes: oh wow sorry about that :)
20:40:13 <jaypipes> sorry, missed that :)
20:40:21 <jeblair> stupid enlish
20:40:21 <russellb> heh yeah, alternative reading was very different :)
20:40:38 <ttx> mainconcern raised is about duplication of scope with the OpenStackAnsible project
20:41:31 <ttx> Looks like we need to investigate that late conern a bit deeper
20:41:32 <sdake> ttx: it is true they are similar problems (deployment) but take radically different approaches to achieving the goal
20:41:37 <jaypipes> 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 <patchbot> jaypipes: https://review.openstack.org/#/c/1/
20:41:57 <russellb> this would not be the first deployment overlap
20:42:00 <jaypipes> ty patchbot.
20:42:01 <russellb> meh
20:42:06 <dhellmann> sdague: can you summarize the differences?
20:42:20 <sdake> yes I have a list of 11 items if you have time dhellmann :)
20:42:34 <dhellmann> sdague: well, is it written down somewhere I just might not have seen, yet? :-)
20:42:35 <russellb> sdake: i think it'd be good to put it on the review for the record
20:42:36 <sdake> 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 <flaper87> russellb: ++
20:42:51 <sdake> russellb yes I asked in the review if the tc would like to see it
20:42:55 <sdake> can add er in
20:42:58 <russellb> sdake: yes i'd like to see it :)
20:43:02 <annegentle> sdake: yes, please
20:43:08 <zaneb> 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 <sdake> will do
20:43:10 <dhellmann> ++
20:43:32 <ttx> OK, let's wait for that and we'll gather votes later
20:43:36 <jaypipes> zaneb: did you see my last comment on the review?
20:43:41 <sdague> yeh, for once, I'm 100% in agreement with zaneb  :)
20:43:53 <ttx> Although it already has 7 votes
20:43:56 <sdake> the containerization part is not tighly coupled
20:43:59 <zaneb> sdague: :D
20:44:11 <russellb> ttx: yeah, but i think we owe the concern a bit more air time
20:44:16 <sdake> my concern with separate repos is it would make dev harder
20:44:19 <sdague> I feel like we specifically opened up for a lot of deployement solutions
20:44:20 <sdake> since they are loosly coupled
20:44:28 <dhellmann> yeah, I'm not concerned about overlap, but I would like to understand the issue more
20:44:30 <sdague> and ansible doesn't get a global lock on a space there
20:44:45 <ttx> 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 <jeblair> this seems to be a good "don't pick winners" thing
20:44:54 <jaypipes> sdake: yeah, understood. it was more a brainstorming question than anything else..
20:44:55 <dhellmann> yeah
20:44:58 <ttx> jeblair: yes
20:45:04 <annegentle> it's a team definition to me as well
20:45:10 <jaypipes> sdague: since puppet and the chef cookbooks follow a separate repo pattern, IIRC.
20:45:16 <sdake> jaypipes I will answer in the review for permanent record ;)
20:45:21 <ttx> 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 <jaypipes> sdague: np :)
20:45:37 <russellb> i don't plan to retract
20:45:42 <ttx> I don't either
20:45:54 <ttx> if everyone is fine with their vote there, let's just approve it now
20:45:54 <annegentle> me neither
20:46:09 * flaper87 neither
20:46:11 <russellb> 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 <dhellmann> wfm, maybe sdake can still post that link though
20:46:19 <ttx> russellb: same here
20:46:29 <sdake> dhellmann I have to actions - answer jaypipes q and your q
20:46:32 <sdake> to/two
20:46:33 <russellb> let the deployment approach flowers bloom
20:46:39 <ttx> dhellmann: agreed, can be done async
20:46:39 <sdague> russellb: ++
20:46:41 <dhellmann> sdake: great, thanks
20:46:43 <jaypipes> russellb: I'm predominantly (only?) concerned about overlap on RESTful API functionality.
20:47:00 <russellb> jaypipes: *nods* another good way to look at it
20:47:03 <sdague> 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 <russellb> though i'm probably more concerned about some APIs than others
20:47:12 <ttx> #topic ATC: Add Cathy Zhang as Neutron ATC
20:47:15 <russellb> anyway
20:47:15 <ttx> #link https://review.openstack.org/207136
20:47:20 <ttx> I think this is straightforward, but we still require those to be voted on by the TC
20:47:24 <ttx> Last time I looked it was still missing a couple of votes
20:47:25 <russellb> this one seems harmless, though likely unnecessary
20:47:25 <jaypipes> russellb: http://foaas.com?
20:47:32 <jaypipes> :P
20:47:35 <ttx> actually missing 3
20:47:40 <russellb> jaypipes: the best API there is
20:47:42 <dhellmann> there was some question of whether it was needed, but I think we should approve it anyway
20:47:43 <jaypipes> hehe
20:47:53 <ttx> vote on it and I'll approve it. Object now if you disagree
20:48:01 <ttx> #topic Feature deprecation / config deprecation policy tags
20:48:08 <sdague> ttx: right, so she's author on - https://review.openstack.org/#/c/192933/
20:48:16 <ttx> #undo
20:48:17 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa3b8fd0>
20:48:20 <sdague> so I guess I'm confused why extra atc is needed
20:48:28 <ttx> sdague:oh, then we can abandon it
20:48:53 <ttx> sdague: ah hm. Co-authors still need to be added
20:48:54 <sdague> https://review.openstack.org/207136 references the reason for her being atc was working on that spec
20:49:11 <sdague> she's not the co-author, she's the author
20:49:18 <russellb> true
20:49:33 <russellb> maybe some previous rev she was co-author?
20:49:34 <sdague> that's what git will show
20:49:41 <russellb> there's 2 people that keep switching ownership of patches in that repo
20:49:43 <dhellmann> why did she approve her own spec?
20:49:45 <ttx> Hmm. do we look into authors or owners...
20:49:51 <dhellmann> is that the same cathy?
20:49:53 <annegentle> aren't spec patches showing up as ATC work?
20:49:55 <russellb> dhellmann: there was a thread about that, yes
20:50:04 <russellb> some people upset about it, but i think it's been discussed and addressed
20:50:20 <mestery> russellb dhellmann: Ack on that, we scolded her and she apologized. :)
20:50:29 <jeblair> ttx: i believe owner
20:50:29 <markmcclain> right should be as settled as it will be for now
20:50:33 <jeblair> fungi: ^?
20:50:40 <dhellmann> mestery, russellb : ok
20:51:02 <ttx> if we look at owners then probably should still be added manually
20:51:09 <ttx> and it doesn't hurt anyway
20:51:15 <sdague> jeblair: oh, it does gerrit owner query, not a git query?
20:51:21 <russellb> right, not git
20:51:26 <russellb> checks gerrit db
20:51:27 <sdague> oh, never mind then
20:51:44 <ttx> #topic Feature deprecation / config deprecation policy tags
20:51:49 <ttx> Those come from the "next tags" workgroup. The first one is about feature/API deprecation policies:
20:51:53 <ttx> #link https://review.openstack.org/207467
20:51:58 <ttx> assert:features-always-supported asserts that you won't deprecate anything ever
20:52:03 <ttx> assert:features-follow-deprecation asserts that you follow a predictable, reasonable deprecation policy
20:52:11 <ttx> The latter is designed to match the current "default" deprecation policy we had for integrated projects in the past
20:52:21 <ttx> 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 <ttx> start of the M cycle, or start of the N cycle ?
20:52:30 <dhellmann> is the former provided for completeness? it doesn't seem very realistic.
20:52:31 <russellb> does any project follow "always-supported" ?
20:52:48 <ttx> russellb: good question. I heard swift claim it
20:52:52 <russellb> bold claim
20:52:56 <annegentle> at the release of the N deliverable I believe?
20:53:07 <annegentle> (that is, it's a year I thought)
20:53:08 <ttx> maybe we could replace that with a longer deprecation policy
20:53:16 <russellb> seems like "always-supported" is just "follow-deprecation" without any plan to exercise the deprecation flow
20:53:21 <dhellmann> annegentle: "at" meaning "in" or "after"? :-)
20:53:30 <sdague> 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 <jeblair> stepping way back -- is this valuable as a choice?
20:53:44 <flaper87> jaypipes: ++
20:53:56 <jeblair> would it be better to establish a project-wide deprecation policy?
20:54:06 <annegentle> dhellmann: when cloud consumers could possibly use the API capability
20:54:12 <ttx> jeblair: some projects will prefer not to assert any deprecation policy and move fast
20:54:17 <annegentle> "in" the released release :)
20:54:29 <ttx> jeblair: but yes, that could be an option
20:54:30 <dhellmann> annegentle: so something added in M could be removed in N?
20:54:40 <annegentle> dhellmann: nope!
20:54:41 <ttx> please comment on the review, no time to solve it today
20:54:47 <ttx> The other review up is about config file options deprecation:
20:54:48 <sdague> so, honestly, I'm not sure this is going to work as a tag
20:54:51 <ttx> #link https://review.openstack.org/207584
20:54:55 <annegentle> something added in M, released in M, could not be removed until the release of O
20:54:58 <sdague> because there are a lot of specific situations
20:55:00 <jeblair> ttx: k, thanks.  even this brief discussion was helpful.  :)
20:55:05 <annegentle> but maybe I'm too conservative?
20:55:06 <ttx> (not sure we need to separate config file options from user-visible features/APIs)
20:55:10 <dhellmann> annegentle: we need to come up with a clear way to say that :-)
20:55:11 <sdague> and it feels like a guidance document might be better
20:55:21 <annegentle> dhellmann: ayup
20:55:24 <russellb> ttx: i think it's valuable, REST API changes are a bigger deal than config file stuff IMO
20:55:32 <ttx> russellb: ok
20:55:40 <annegentle> I have to head out, sorry, comms ideas in flaper87's capable hands
20:55:46 <annegentle> russellb: yeah
20:55:53 <russellb> REST API changes the most important to establish clear policy on
20:56:03 <dhellmann> 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 <ttx> please follow-up on review
20:56:30 <ttx> OK, skipping workgroup reports for today and jumping to open discussion
20:56:35 <ttx> #topic Open discussion
20:56:35 <sdague> dhellmann: maybe, honestly, for deprecation I'd expect a lot more guidance
20:56:43 <ttx> About topic tagging for governance reviews, I posted a question at:
20:56:48 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2015-July/001005.html
20:56:49 <zaneb> 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 <ttx> Any preference ?
20:57:10 <ttx> zaneb: ++
20:57:23 <ttx> Also.. next week I'll be coming back from vacation and won't be able to prepare for the meeting.
20:57:25 <jeblair> ttx: i like your inverted suggestion
20:57:26 <dhellmann> sdague: sure, maybe suggest some details to be added
20:57:31 <ttx> Does anyone want to pick it up and chair it, or shall we just skip for one week ?
20:57:41 <russellb> i think i may be traveling next week
20:58:14 <flaper87> There'll be a tc post this week
20:58:16 <ttx> 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 <sdague> zaneb: well from my experience from the tempest side, most of the projects don't deprecate in an orderly manner
20:58:28 <flaper87> There are enough topics for a new one
20:58:49 <ttx> OK, Cathy's extra atc review has enough votes on it, I'll approve it now
20:59:22 <ttx> Will approve the Kolla one as soon as Steve pushes his 11 point explanation
20:59:27 <dhellmann> ttx: I'd be ok with skipping if it doesn't seem like we have any pressing business.
20:59:29 <zaneb> sdague: heh, ok :) that's another issue to tackle I guess
20:59:36 <fungi> oops, sorry, stepped away... yes, it's gerrit change owner that we use for elections and summit passes
20:59:39 <flaper87> sdague: https://www.youtube.com/watch?v=EYKdmo9Rg2s :D
20:59:40 <sdake> ttx still typing :)
20:59:44 <ttx> dhellmann: no pressing things. Mostly tags that can be reviewed on gerrit
20:59:56 <russellb> thanks sdague
20:59:58 <russellb> err sdake
20:59:58 <ttx> and I won't be making new revisions this week
21:00:29 <sdake> ttx i was incorrect it is 9 points
21:00:39 <ttx> ok, let's tentatively skip it. Feel free to conspire into holding it while I'm away
21:00:41 <russellb> sdake: 9?! that changes everything
21:00:51 <ttx> and approved.
21:01:07 <sdake> ttx sorry 10 :)
21:01:07 <ttx> Alright, have a great week.
21:01:12 <ttx> #endmeeting