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