20:01:36 <EmilienM> #startmeeting tc
20:01:37 <openstack> Meeting started Tue Mar 28 20:01:36 2017 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:40 <openstack> The meeting name has been set to 'tc'
20:01:41 <ttx> thingee: they all decide to go to bed early
20:01:51 <ttx> decided*
20:01:53 <EmilienM> Agenda at:
20:01:54 <EmilienM> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:08 <EmilienM> let's start with the first topic:
20:02:10 <EmilienM> #topic Update diversity tags
20:02:14 <EmilienM> #link https://review.openstack.org/448667
20:02:34 <EmilienM> sounds like we had a negative feedback a few hours ago from Michael
20:02:46 <johnsom> I am here to answer questions
20:02:55 <johnsom> Give comments if asked for...
20:02:59 <thingee> johnsom: do you disagree with the script we use to produce these results?
20:03:06 * edleafe hopes no one sees him wandering in late
20:03:11 <ttx> johnsom: the ;etric at fault is core reviezs
20:03:18 <ttx> oops us keyboard
20:03:28 <ttx> the metric at fault is core reviews
20:03:34 <johnsom> I think it is a bit on the harsh side and penalizes a project for having the PTL at an active company.
20:03:42 <johnthetubaguy> johnsom: did you see the definition here: https://governance.openstack.org/tc/reference/tags/team_diverse-affiliation.html
20:03:54 <johnsom> Right, percent of core reviews from one company.
20:04:06 <johnthetubaguy> its two companies being more than 80% of something I thought?
20:04:12 <johnsom> I dug into the script when I heard about this.
20:04:23 <ttx> it's not single-vendor, but it's not diverse either
20:04:52 <ttx> johnthetubaguy: single company core review > 50%
20:04:54 <johnthetubaguy> right, diverse is a high-sh bar, and for a good reason
20:04:57 <johnsom> It was only the core metric we were over.
20:05:02 <johnthetubaguy> ttx: ah, OK
20:05:14 <ttx> johnsom: yes true, and not by far
20:05:38 <johnsom> Right.  We of course have been impacted my the musical chairs with developers.
20:05:50 * rockyg spies a slinking edleafe
20:05:55 <sdague> johnsom: which also means it's probably not hard to get back over that line as long as it's a team focus
20:05:56 <fungi> if the script isn't measuring what we intended, then i agree we should hold off updating tag application and fix that. if it's just that we're focusing on the wrong metrics entirely that's a separate discussion we should handle through a different proposal which shouldn't block the current one
20:05:57 <ttx> the issue is, I don't think we can make the rule subjective
20:06:00 <johnsom> https://www.irccloud.com/pastebin/jR9uwWyL/
20:06:05 * bswartz invokes Goodhart's Law
20:06:06 <bswartz> https://en.wikipedia.org/wiki/Goodhart%27s_law
20:06:12 <EmilienM> johnsom: tbh, I don't think it's a terrible news to loose this tag. you're close to have it again anyway
20:06:20 <thingee> fungi: ++
20:06:31 <johnsom> For those curious in the actual numbers.  (which might be nice on the commit message).
20:06:37 <EmilienM> johnsom: the most important is the health of your project and I haven't seen negative signs so far
20:06:49 <johnsom> These don't get automatically re-added right?
20:06:54 <EmilienM> fungi: yes, we can wait for sure.
20:06:58 <thingee> johnsom: no
20:07:06 <EmilienM> johnsom: we have a bot called ttx  :D
20:07:21 <mordred> he's a good little bot
20:07:22 <ttx> johnsom: they get readded whenever someone runs the script again
20:07:22 <thingee> can confirm he's a robot
20:07:26 <fungi> but they do get re-added without necessarily needing to request that it happen
20:07:31 <ttx> I try to do that every 2months-ish
20:07:39 <sdague> ttx: it would be nice if the numbers for the projects were in the commit message
20:07:40 <dims> i was just going to ask that ttx :)
20:07:44 <johnsom> This just seems like another thing that makes it hard for small teams to participate and grow momentum.
20:07:47 <sdague> just to make it concrete
20:07:58 <EmilienM> ttx: we could have a periodic job in governance (so we stop doing it manually?)
20:07:58 <thingee> sdague: ++
20:08:04 <ttx> sdague: aren't they ? you mean all the numbers ?
20:08:07 <johnthetubaguy> the 56 and 92 are there I guess
20:08:10 <sdague> ttx: yeh
20:08:11 <mordred> johnsom: well - in the past we've also talked about hopefully being able to use some of these to cajole folks in to contributing resources ...
20:08:14 <johnthetubaguy> ah, all
20:08:24 <ttx> sdague: ok, will copy more next time
20:08:25 <sdague> ttx: all of them, just as baseline
20:08:43 <johnsom> mordred Understand, it's a fine line I think we dance
20:08:54 <mordred> johnsom: other companies may not realize that it would be good to get more humans on a thing - I _know_ everyone is always interested in the topic of lbaas
20:08:55 <EmilienM> so do we agree to postpone it a little more until we discuss more about the script?
20:09:01 <mordred> johnsom: totally agree
20:09:09 <mordred> EmilienM: I'm good with postponing a bit
20:09:18 <ttx> sure no urgency
20:09:22 <zaneb> one problem with a hard threshold is that teams right on the threshold for one of the metrics will tend to bounce in and out
20:09:24 <sdague> can we set a time table though?
20:09:31 <dtroyer> This is an indicator, and it is doing its job in raising awareness in places not otherwise aware of the situation.
20:09:32 <zaneb> some hysteresis might help here
20:09:36 <fungi> zaneb: sort of a hysteresis?
20:09:37 <sdague> zaneb: yeh, that's going to be true anywhere
20:10:05 <dtroyer> zaneb: one reason for not running it weekly
20:10:06 <EmilienM> #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics
20:10:10 * mordred can provide hysteresis just by running around screaming, if it would help
20:10:31 <johnsom> Small teams, the cores are likely concentrated at a few organizations (we have three).
20:10:32 <sdague> EmilienM: can we give it a date where we're going to move forward regardless
20:10:34 <zaneb> yeah, so once a team has the tag, maybe give them a bit more leeway before losing it again
20:10:38 <fungi> mordred: i think you meant hysteria?
20:10:41 <johnsom> I will noodle and maybe propose something
20:10:51 <mordred> johnsom: ++
20:10:58 <ttx> johnsom: well it's sure it's harder for small teams to be diverse
20:11:08 <EmilienM> sdague: in 2 weeks max?
20:11:11 <ttx> doesn't mean the tag definition is inaccurate
20:11:12 <sdague> EmilienM: ++
20:11:14 <sdague> ttx: ++
20:11:16 <EmilienM> #undo
20:11:17 <openstack> Removing item from minutes: #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics
20:11:20 <johnthetubaguy> ttx: ++
20:11:31 <EmilienM> #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics - take decision on the patch in the next 2 weeks
20:11:50 <EmilienM> #undo
20:11:51 <openstack> Removing item from minutes: #action postpone https://review.openstack.org/#/c/448667 and start discussion on how the script computes the diversity metrics - take decision on the patch in the next 2 weeks
20:11:55 <EmilienM> #action postpone https://review.openstack.org/#/c/448667
20:12:07 <sdague> right, part of the reason for this tag to exist it for consumers to understand how robust the contributor field is behind a project, so that if one or more orgs close shop, what is the impact on the project
20:12:08 <EmilienM> #action start discussion about how we compute diversity metrics
20:12:15 <ttx> I think "diverse-affiliation" is a high bar and hard to reach. Was honestly surprised to see Octavia had it in the first place
20:12:16 <EmilienM> #action take decision for https://review.openstack.org/#/c/448667 in the next 2 weeks
20:12:22 <johnthetubaguy> sdague: +1 for keeping that in mind here
20:12:28 <sdague> because, we've totally had organizations actually close up shop
20:12:34 <dims> ++ EmilienM
20:12:38 <sdague> that's not a theoretical
20:12:44 <EmilienM> sdague: yes, agreed
20:12:47 <johnthetubaguy> although small teams are had to keep the diverse tag, they are also more likely to be affected by one company walking away
20:12:53 <johnsom> We were the #1 neutron sub-project based on the April 2016 survey....
20:12:53 <sdague> johnthetubaguy: ++
20:13:05 <sdague> johnsom: which is fine, that's a different axis
20:13:31 <johnsom> Agreed
20:13:35 <EmilienM> johnsom: again, you shouldn't take this one as a bad news tbh
20:13:38 <ttx> we could have some grace period
20:13:52 <EmilienM> johnsom: I haven't seen any sigh of octavia being in bad shape
20:13:55 <EmilienM> sign*
20:14:00 <mordred> or sigh
20:14:04 <johnsom> It is perceived as a path to getting booted from an official project.....
20:14:11 <sdague> johnsom: why?
20:14:18 <mordred> ah - well, we should work on changing that perception
20:14:20 <EmilienM> johnsom: not at all
20:14:23 <sdague> yeh, definitely not that
20:14:26 <ttx> johnsom: fwiw most teams aren't diverse
20:14:27 <mordred> that is definitely not the _intent_
20:14:53 <sdague> mordred: ++
20:14:58 <johnsom> I think it is confused with single vendor and it is part of the discussion to become a project
20:15:05 <mordred> and, for the love of all that is good and holy, I think the _last_ thing any of us want to do is boot LBaaS out
20:15:12 <EmilienM> we need to send a message that this tag doesn't make you a first class citizen
20:15:15 <johnsom> Hahaha
20:15:16 <EmilienM> it's just a number
20:15:36 <EmilienM> should we move on?
20:15:44 <ttx> yes
20:15:47 <mordred> if anything it should be a message to member companies that maybe they need to allocate a human to work on a thing if they care about it
20:15:47 <EmilienM> #topic Various repository moves
20:15:48 <dims> please
20:15:54 <EmilienM> * Move DIB from TripleO to Infra
20:15:54 <mtreinish> o/
20:15:57 <EmilienM> #link https://review.openstack.org/445617
20:16:11 <EmilienM> I didn't vote because I'm the author
20:16:15 <EmilienM> but with my TC hat, +1 :)
20:16:27 <EmilienM> (and TripleO PTL hat)
20:16:34 <greghaynes> I am guessing this is just a topic mistype but the intent is for us to not remove the repository fwiw
20:16:36 <dims> was there some discussion on this in the infra meeting earlier?
20:16:37 <fungi> yeah, we just re-discussed it in the infra meeting moments ago, so i'm good
20:16:38 <sdague> these should be pretty rote right? just let ttx slam them all in
20:16:39 <EmilienM> so far we have zero negative feedback until now
20:16:44 <greghaynes> er
20:16:45 <greghaynes> not move
20:16:58 <dims> :)
20:17:10 <ttx> good if both ptls are ok
20:17:10 <EmilienM> ttx: ship it please
20:17:15 <ttx> shipping
20:17:21 <EmilienM> * Remove Gnocchi from Telemetry
20:17:23 <EmilienM> #link https://review.openstack.org/447438
20:17:35 <EmilienM> gordc: any last word? :)
20:17:41 <EmilienM> (jd is offline)
20:17:55 <dims> gordc : are you moving out of openstack ci infra as well?
20:18:02 <EmilienM> dims: AFIK yes
20:18:13 <EmilienM> but I might have missed something
20:18:24 <thingee> according to the email, that was eventually happening
20:18:34 <fungi> i read it as "might eventuaklly be in the cards"
20:18:35 <dims> thanks EmilienM thingee - just curious
20:18:57 <fungi> it didn't sound like there were any immediate plans to relocate the repo
20:19:07 <thingee> http://lists.openstack.org/pipermail/openstack-dev/2017-March/114300.html
20:19:30 <thingee> "As a second step, the project will likely move out of the OpenStack infrastructure in the future."
20:19:43 <fungi> yeah, so no set timeline for that
20:19:50 <EmilienM> ttx: ship it please, no blocker afik
20:19:59 <dims> ++
20:20:00 <johnthetubaguy> just for clarity, we are not requiring them to stop using infra I assume?
20:20:08 <ttx> I guess the only auestion is, are we happy to see it go, or should we fork it in openstack.
20:20:10 <mordred> nope
20:20:22 <clarkb> no they would essentially be "stackforge' at that point
20:20:24 <ttx> I think I'm in the first camp
20:20:29 <mordred> johnthetubaguy: that was for you - we are certainly not requiring hem to stop
20:20:35 <dims> y happy to let go
20:20:40 <mordred> ttx: I am too - I do not see any need to
20:20:41 <fungi> for what it's worth, we did discuss a few weeks ago in boston that we need to take action to get rid of the perception that openstack is one monolithic thing you have to run all of
20:20:50 <EmilienM> why forking it?
20:20:52 <johnthetubaguy> mordred: clarkb: yeah, that was my hope, just wanted to make that clear
20:21:05 <mtreinish> fungi: yeah, that's something I'd like to figure out how to fix
20:21:12 <fungi> so the concern raised in that review will one day, i hope, no longer be
20:21:20 <ttx> EmilienM: well, if there were some people in openstack wanting to continue it... we'd be in a bind
20:21:34 <ttx> and would probably have to fork it
20:22:03 <johnthetubaguy> fungi: mtreinish: +1 talking more about constellations as sets of things that run together for particular use cases should help some, but thats a different discussion
20:22:04 <EmilienM> ttx: AFICT, "people in openstack" who worked / work on Gnocchi are part of Gnocchi team and are happy with this move
20:22:07 <ttx> (that's due to the "leave infra" part)
20:22:18 <mordred> yah, just because a team wants to go away doesn't necessarily mean OpenStack as a whole feels the same way - imagine if the nova cores decided they wanted to take nova elsewhere
20:22:22 <EmilienM> ttx: I never had the impression (unless I missed something) that someone wasn't happy and would eventually fork it
20:22:26 <ttx> EmilienM: indeed, which is why I said, no problem in this case
20:22:52 <mordred> I'm pretty sure we would _not_ just delete nova from infra and wash our hands of it - but in this case, I think there is no need for such a behavior
20:23:09 <mtreinish> johnthetubaguy: this is somewhat independent of that I think. It's more a general perception that if it's a git repo in openstack/ you can't use it outside of openstack
20:23:12 <ttx> but when am official deliverable leaves openstack infrastructure, I think it's good to check :)
20:23:14 <mordred> their reasons for making the change all make sense
20:23:26 <mordred> ttx: ++
20:23:30 <EmilienM> ship it!
20:23:48 <mtreinish> I'm not sure constellations will help with that (but they might, I really don't know)
20:23:51 <mordred> mtreinish: yah - we should also work on that perception
20:23:51 <ttx> shipping
20:24:03 <mordred> mtreinish: I  mean, I do not think that I can't run statsd just because I don't work on etsy :)
20:24:05 <gordc> EmilienM: sorry, you still need me?
20:24:09 <ttx> shipped
20:24:10 <EmilienM> gordc: too late :)
20:24:14 <mordred> gordc: nope! you're all set
20:24:17 <EmilienM> * Move castellan under Oslo governance
20:24:18 <fungi> johnthetubaguy: more the thing we discussed where we should make it possible to run services independent of one another
20:24:19 <EmilienM> #link https://review.openstack.org/449137
20:24:21 <johnthetubaguy> mtreinish: true, that is maybe wider
20:24:33 <gordc> dims: i think eventually yes. this is mainly for formality right now.
20:24:40 <dims> ack gordc
20:24:42 <johnthetubaguy> fungi: so thats possible today, and people do it, I guess its just not talked about a whole bunch
20:24:59 <fungi> johnthetubaguy: right
20:25:16 <ttx> dims: looks like that one could use last-minute additions
20:25:30 <johnthetubaguy> fungi: I was really suggesting we make those constellations (of maybe one), but that might be overkil
20:25:45 <EmilienM> gcb: any thoughts you want to share?
20:25:59 <ttx> dims: to please gcb
20:26:06 <EmilienM> it's worth mentioning this spec in progress: https://blueprints.launchpad.net/oslo.utils/+spec/adopt-castellan
20:26:38 <dims> ack ttx : will rev the patch and get ok from gcb
20:27:02 <ttx> ok, and with the TC approval I'll merge the result
20:27:17 <ttx> whenever it has gcb +!
20:27:20 <ttx> +1
20:27:26 <EmilienM> ttx: he already +1 fwiw
20:27:29 <dims> @action Dims to follow up with Oslo PTL on Castellan review
20:27:34 <dims> #action Dims to follow up with Oslo PTL on Castellan review
20:27:43 <ttx> yeah, but I think it's better to fix the patch and approve it
20:28:01 <dims> agree ttx
20:28:19 <EmilienM> moving on
20:28:22 <EmilienM> #topic Move shade into its own top-level team
20:28:23 <EmilienM> #link https://review.openstack.org/446426
20:28:36 <EmilienM> mordred: o/
20:28:41 <fungi> also just talked through this one in the infra meeting
20:28:42 <mordred> this one has had an update to the commit message since last you voted on it
20:28:48 <mordred> based on feedback in the infra meeting
20:28:52 <EmilienM> mordred: so we're moving a bug to another place? :P
20:29:05 <fungi> we're playing musical bugs
20:29:08 <EmilienM> mordred: where you are the PTL of this bug?
20:29:15 <EmilienM> sounds like a safe plan ;-)
20:29:17 <mordred> mmm. bug orchestras
20:29:26 <mordred> EmilienM: aren't I the PTL of all bugs? :)
20:29:28 <EmilienM> Hi, I'm PTL of a bug
20:30:02 <fungi> mordred: you're probably about to be at any rate
20:30:11 <mordred> fungi: indeed
20:30:24 <EmilienM> fungi: is the namespace still ok?
20:30:33 <EmilienM> I guess we don't want to mess with git migration?
20:30:36 * stevemar sneaks in
20:30:52 <mordred> yah - I'm concerned that would wind up breaking humans for no great reason
20:30:53 <fungi> EmilienM: repo renames are painful, but also doable separately later if we really decide it's causing a problem
20:30:57 <mordred> yah
20:30:57 <dims> EmilienM : we can leave it to the infra team if/when they want to do the git migration
20:31:07 <EmilienM> fair enough, just a random question
20:31:21 <EmilienM> we have the quorum, ship it
20:31:21 <dims> EmilienM : needed to be asked :)
20:31:33 <ttx> /me ships
20:31:33 <fungi> and as i mentioned in one of the review comments, it's not the first repo in the openstack-infra namespace which isn't an infra team deliverable
20:31:54 <EmilienM> fungi: good to know
20:31:56 <EmilienM> #topic Add tag assert:never-breaks-compat
20:31:58 <EmilienM> #link https://review.openstack.org/446561
20:32:00 <EmilienM> mordred: you again?? :)
20:32:14 <mordred> yah - this one I think people had more concerns with
20:32:30 <mordred> I think you all know I have extreme views on compatibility
20:32:47 <mordred> this is an attempt to create an opt-in assertion for anyone who starts sharing them with me :)
20:32:47 <EmilienM> I found the name weird tbh
20:32:59 <mordred> EmilienM: I'm also _very_ bad at naming things
20:33:18 <EmilienM> stevemar had a great proposal I think
20:33:37 <mtreinish> mordred: how does this relate to https://review.openstack.org/#/c/418010/ ?
20:33:47 <mordred> basically - as I was looking at the standard-deprecation tag and applying it to shade, I was dismayed that it laid out concepts around removal that shade did not, in fact, share
20:33:58 <EmilienM> I liked assert:fully-compatible
20:34:13 <mordred> mtreinish: it's very very similar
20:34:25 <johnthetubaguy> do we have a team to start adopting this one? was it swift?
20:34:29 <mtreinish> mordred: heh, that's what I was thinking as I started reading it
20:34:34 <jroll> johnthetubaguy: probably shade :P
20:34:41 <johnthetubaguy> jroll: heh
20:35:09 <fungi> timely given that novaclient has just stopped supporting some nova-net features which may still be in heavy use in the wild
20:35:13 <mordred> johnthetubaguy: swift as so far not broken anything, although notmyname wasn't sure they wanted to assert it
20:35:23 <sdague> mordred: ok, so before creating a wish list tag, is any team going to assert that?
20:35:23 <mordred> fungi: those, in fact, broke shade for a second
20:35:35 <mordred> sdague: I mean, shade is - but I konw that's only one team
20:35:38 <notmyname> I agreed with clayg's comments on the review (which in large part were due to the name)
20:35:46 <johnthetubaguy> mordred: do they know? the testing on this is really hard, I know you touch on that, did you want to include that
20:36:24 <ttx> I think we shouldn't create the tag until we want to encourage more projects to adopt it
20:36:38 <mordred> johnthetubaguy: well - there's intent and then there is perfection in reality
20:36:42 <notmyname> as of this point today, the swift team is not looking to assert this tag
20:37:05 <fungi> i feel like it's sufficient to declare that a project will try not to break backward compatibility and will consider any such breakage (even if not actively tested) an important bug worth fixing
20:37:06 <mordred> for now this is about intent - the team asserts its intent is to not release breaking changes to its api
20:37:12 <ttx> base question is, is that a behavior we ideally want all projects to have
20:37:15 <mordred> fungi: ++
20:37:39 <dtroyer> ttx: I'm not sure we need that, it is another indicator of intent/status
20:37:44 <sdague> I also think like it's a different story between a library and service, and the challenges of the 2 mean it's a little weird to lump them in
20:38:02 <johnthetubaguy> sdague: thats a very good point
20:38:11 <mordred> so - the reason I think they're the same, and that's it's valuable
20:38:20 <JayF> I would also wonder if having a "super" we-don't-break-compatibility tag will water down the value of a project that has standard-deprecation. For instance, I could see an external force (like someone in management) wanting to push for the more impactful tag.
20:38:32 <mordred> is that it's also entirely possible that teams value things like "cleaning things up" or "reducing maint burden"
20:38:48 <mordred> which are other points of view that are held, from time to time, by various people
20:39:38 <johnthetubaguy> never breaks requires basically infinite man power, at least feels that way as a service
20:40:02 <dims> notmyname : were there any things in that review that did not sit well with the swift team?
20:40:07 <mordred> johnthetubaguy: but if the service team doesn't do it- the end user has to
20:40:37 <johnthetubaguy> mordred: I keep thinking about cloud pipe VPN as the example
20:40:49 <mordred> the burden exists somewhere, because we aren't a single implementation of any of our services, but are instead a collection of differently versioned points in time of each service out in the world
20:40:59 <fungi> definitely runs counter to the interest in the joint board/tc/uc meeting for dropping rarely-used options, features and backends to simplify service complexity
20:40:59 <sdague> mordred: I definitely agree with you on the slider
20:41:07 <thingee> I'm ok with the idea. I like that there is something that encourages and asserts this value of a project.
20:41:14 <mordred> johnthetubaguy: yah - I mean, I don't thikn teams should start off with this
20:41:20 <sdague> where there are things where either the service handles it or externalizes to all the users
20:41:22 <notmyname> dims: in general, the absolute-ness of it. true, we do our best not to break clients. but sometimes it's a very fuzzy line to determine what "break" means
20:41:28 <sdague> but *never* is a really strong word
20:41:35 <johnthetubaguy> sdague: +1 on the slider, I am just not right up against the far end
20:41:35 <notmyname> to quote the gerrit review from clayg: 'there should be a thing here for security too - like "when faced with a mistake and given the choice that either the behavior of the api changes to include a new restriction or it's impossible to use safely prefer to fix it"'
20:41:37 <EmilienM> fungi: good point
20:41:50 <dims> ack notmyname
20:41:55 <sdague> notmyname: ++
20:42:04 <thingee> notmyname: agreed
20:42:05 <mordred> notmyname: yah - I mean, I thought I had that in there already
20:42:16 <notmyname> I think that's just one example where we do "break" compat, but it depends on what breaking means
20:42:16 <mordred> but I'll definitely take another stab at making that much clearer - beause I totally agree with that
20:42:19 <mordred> yup
20:42:33 <dims> may be this language goes somewhere else as projects should aspire to be doing this
20:42:40 <notmyname> another is when implementation is different than RFC. who's wrong? the client? the service? it's different at different times
20:42:44 <fungi> my main issue is that it doesn't seem like it can actually be meaningful. does applying it now mean the project has never broken backward compatibility in the past? or just promises not to do so from now on? and only until they choose to remove the tag? can it be re-added again after that? "247 days since last api backward-compatibility breakage"
20:42:52 <notmyname> and we've made different calls at different times (and sometimes reverted)
20:43:07 <sdague> fungi: right, past returns not indicative of future performance?
20:43:08 <mordred> fungi: zomg. we need that badge
20:43:31 <johnthetubaguy> mordred: so that API almost never worked on any cloud, probably has worked for years, no one dare test it, we can keep that behaviour today, but removing it might actually cause less user confusion... but I am agree its all about the users.
20:43:32 <dims> fungi : if we don't make any changes in the repo :)
20:44:06 <mordred> johnthetubaguy: yah. fair point
20:44:21 <thingee> mordred: badge/sticker idea for shade
20:44:26 <sdague> mordred: honestly, on the mission of helping more developers understand the cost of externalizing their API changes without compatibility, it feels like a description of the costs of that is maybe better than a tag
20:44:32 <johnthetubaguy> mordred: I mean I am totally on your side in terms of getting the slider in the right place though
20:44:40 <dims> ++ johnthetubaguy
20:44:43 <mordred> ++
20:44:44 <johnthetubaguy> sdague: thats a top idea
20:44:48 <mordred> to both of you
20:44:49 <sdague> I feel like a lot of the heatedness during the API WG sessions at the PTG were because people really hadn't thought through
20:45:08 <mordred> sdague: where should that go, do you think?
20:45:10 <sdague> like "oh, then you have to make this change to ruby sdk, this go thing, this nodejs thing, etc"
20:45:33 <sdague> mordred: that's a good question... api-wg repo maybe?
20:45:43 <mordred> sdague: yah - that's probablya good place
20:45:57 * johnthetubaguy remembers the Nova v3.0 API debates... its really not obvious as it seems after you have the "ah ha moment"
20:46:01 <fungi> also, time check. 15 minutes remaining with another topic before open discussion
20:46:19 <EmilienM> fungi: indeed
20:46:23 <EmilienM> mordred: can we move on?
20:46:30 <EmilienM> mordred: and re-iterate next week probably
20:46:45 <mordred> EmilienM: yup
20:46:47 <EmilienM> #topic Resolution on OpenStack's mission for cloud applications
20:46:50 <EmilienM> #link https://review.openstack.org/447031
20:46:58 <johnthetubaguy> mordred: sdague: that new API guidelines thing probably has 80/90% of that context thinking about it
20:47:11 <sdague> johnthetubaguy: maybe, I think there is more context here
20:47:13 <dims> kudos to zaneb
20:47:25 <mordred> zaneb++
20:47:29 <EmilienM> zaneb: any comment on this one?
20:47:32 <zaneb> dims: thanks for prompting me to do this :)
20:47:33 <johnthetubaguy> sdague: +1 for there being some missing, totally needs checking
20:48:08 <zaneb> EmilienM: not much to add really. if anyone has questions I can try to answer 'em
20:48:47 <EmilienM> I think we miss one vote to ship it
20:48:58 <dims> when we get this in, we should promote this mission statement heavily
20:49:00 <sdague> zaneb: I guess my only question is how does paragraph 4 turn into concrete things
20:49:01 <zaneb> I'm also interested in how we can get the whole community on board with this, not only the TC
20:49:24 <mordred> zaneb: there are other people?
20:50:05 <zaneb> sdague: it's a balancing act between getting too concrete and failing to say anything at all
20:50:13 <EmilienM> (I want to keep 7 min for open discussion fyi)
20:50:52 <mordred> zaneb: srrsly though - even just tweeting out the link to the published doc when it lands would be a good first step in folks seeing it / reading it / ingesting it
20:50:55 <johnthetubaguy> so I have been thinking about including this kind of discussion as part of the VM & BM working group thing, for the next PTG
20:50:56 <zaneb> sdague: feedback on the first draft was that it was too vague
20:51:08 <mordred> johnthetubaguy: ++
20:51:20 <dims> zaneb : the board and tc talked about adjacent communities which we turned around and running with it in the "go/containers" thread and actively finding people and proposals to expand on that. we need to do something similar
20:51:31 <sdague> zaneb: yeh, I guess it feels like a bunch of keystone related effort, and it would be nice to have keystone community members bought in before the TC declares this a thing
20:51:54 <sdague> I don't see any keystone folks in the the +1 list, right?
20:52:02 <mtreinish> lbragstad: ^^^
20:52:21 <zaneb> johnthetubaguy: that would be great. it might be worth discussing if there are any sessions we could organise at the Forum to get started too
20:52:25 <johnthetubaguy> sdague: thats a very good point, more keystone +1 around that would be good
20:52:45 <lbragstad> mtreinish o/
20:52:56 <zaneb> sdague: I agree, although it's not _just_ keystone that needs to be on board
20:53:07 <sdague> zaneb: sure
20:53:09 <EmilienM> lbragstad: we're running out of time but it would be great if your team could have a look at https://review.openstack.org/#/c/447031
20:53:12 <sdague> I just wouldn't want to land it without any keystone feedback
20:53:21 <johnthetubaguy> zaneb: possibly, I was getting the vibes we wouldn't have enough of those project developers present to have a good discussion
20:53:23 <EmilienM> sdague: +1
20:53:30 <sdague> EmilienM: can I propose we table until next week and make sure keystone folks throw in
20:53:35 <EmilienM> sdague: yes please
20:53:47 <zaneb> mordred: https://twitter.com/zerobanana/status/842763247543640064
20:53:50 <lbragstad> EmilienM sdague awesome - i'll review today
20:53:58 <dims> zaneb : let's throw this into general mailing list too and ask folks to vote
20:54:10 <EmilienM> #action Get Keystone team to review https://review.openstack.org/#/c/447031
20:54:15 <zaneb> dims: ack, will send a mail today
20:54:22 <sdague> zaneb: awesome
20:54:26 <EmilienM> #topic Open discussion
20:54:28 <dims> thanks zaneb
20:54:39 <EmilienM> * Forum topics: http://forumtopics.openstack.org/
20:54:57 * dims has to run. will catch up on the meeting log
20:54:58 <EmilienM> I sent an email to tc ML about the sessions I created on behalf of the authord in the etherpad we have
20:55:00 <ttx> Posted details about the TC+Board+UC meeting (and dinner) in Boston around summit
20:55:05 <EmilienM> #link https://etherpad.openstack.org/p/BOS-TC-brainstorming
20:55:26 <EmilienM> if anyone who wrote a topic on https://etherpad.openstack.org/p/BOS-TC-brainstorming wants to change the content on http://forumtopics.openstack.org/ - please let me know
20:55:42 <ttx> I was thinking about a "should Stackalytics die" session. Does that sound like a good idea ?
20:55:56 <EmilienM> floor is open to questions and feedback or any other topic!
20:56:06 <notmyname> ttx: yes. also, it's a good forum topic ;-)
20:56:07 <mtreinish> ttx: does anyone think we shouldn't kill it?
20:56:17 <johnthetubaguy> EmilienM: I did mean to reply to you, honest, just not had chance
20:56:18 <EmilienM> ttx: maybe not die, but evolve
20:56:25 <thingee> mtreinish: you'll have to attend the session to find out!
20:56:26 <EmilienM> johnthetubaguy: you don't have to worry
20:57:11 <ttx> EmilienM: all metrics used to compare performance will result in gaming amd incentivize bad behavior
20:57:24 <jroll> stackalytics is super nice for some quick information discovery, e.g. finding out if cores are pulling their weight and such. I do wonder if the downstream abuse outweighs those benefits
20:57:27 <ttx> so that evolution would need to be very close to death
20:57:28 <fungi> mtreinish: it fills the gap of having some sort of central statistics so that every member company doesn't feel obliged to publish their own conflicting community involvement metrics, at least
20:57:29 <jroll> I used it all the time as PTL
20:57:55 <EmilienM> jroll: same thing. Very useful to find out who in the team makes good progress on reviews, etc
20:57:57 <thingee> I still use russellb's stats
20:58:01 <thingee> even if it doesn't update
20:58:05 <lbragstad> thingee ++ same here
20:58:11 <ttx> fungi: we/Foundation would need to produce some official stats to compensate
20:58:19 <dtroyer> these are all uses that are great, but done by people who understand what they are looking at.
20:58:36 <jroll> thingee: sure, stackalytics can give you different views on the data though. especially when you have lots of projects under one umbrella (neutron, ironic,e tc)
20:58:42 <JayF> I'm not even sure I understand what the percieved value would be of killing Stackalytics. If downstream managers want to use bad metrics, they'll use bad metrics whether provided by stackalytics or not.
20:58:46 <ttx> OK, sounds like an interesting discussion, will propose
20:58:50 <fungi> ttx: yep. and i guess not outsource that stats collection to a third party like we tried in the past?
20:58:55 <johnthetubaguy> jroll: ++
20:58:59 <sdague> fungi: ++
20:59:03 <jroll> JayF: good point, I'd love to see more context
20:59:11 <clarkb> JayF: there is likely an argument that we shouldn't enable it though
20:59:22 <lbragstad> jroll ++ another data point doesn't really hurt
20:59:23 <EmilienM> fungi: agreed.
20:59:26 <JayF> I don't think removing stackalytics would change any downstream behaviors, honestly. And there are clearly upstream use cases for it (see comments made in here already)
20:59:33 <sdague> JayF: ++
20:59:33 <ttx> JayF: remove bad incentives, mostly
20:59:43 <EmilienM> I'm about to close the meeting
20:59:46 <jroll> it'll just make managers ask me to gather stats :P
20:59:50 <sdague> jroll: ++
20:59:51 <fungi> granted, openstack doesn't officially run stackalytics (yet anyway). it's not an official project and it's provided by one company
20:59:53 <JayF> ttx: I promise, management is creative enough to find new bad incentives
20:59:54 <EmilienM> thanks all for giving me the change to do it ;-)
20:59:54 <sdague> yeh, pretty much
20:59:55 <JayF> jroll: ++++
21:00:01 <EmilienM> #endmeeting