21:02:04 <mestery> #startmeeting networking
21:02:05 <dougwig> o/
21:02:05 <openstack> Meeting started Mon Oct 13 21:02:04 2014 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:02:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:02:08 <openstack> The meeting name has been set to 'networking'
21:02:13 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:02:19 <mestery> #topic Announcements
21:02:31 <mestery> We released our second RC for Juno last week
21:02:33 <mestery> #link https://launchpad.net/neutron/+milestone/juno-rc2
21:02:37 <mestery> #link https://launchpad.net/neutron/juno/juno-rc2/+download/neutron-2014.2.rc2.tar.gz
21:02:45 <mestery> Thanks to all who helped with bugs near the end!
21:03:00 <mestery> At this point, I'm not aware of any RC issues which would cause a third RC to be released.
21:03:08 <mestery> If anyone knows of anyone, lets discuss during the bugs portion of the meeting.
21:03:26 <mestery> I would encourage folks to test out the RC2 release as it's likely to be the official 2014.2 release of Neutron.
21:03:49 <mestery> If anyone finds a release critical bug, please tag it with "juno-rc-potential" and make sure you email me or find me on IRC so I'm aware.
21:04:00 <mestery> Any questions on the state of Neutron in Juno?
21:04:43 <mestery> I also wanted to highlight the release notes for Neutron are being worked on actively now as well.
21:04:44 <mestery> #link https://wiki.openstack.org/wiki/ReleaseNotes/Juno#OpenStack_Network_Service_.28Neutron.29
21:04:55 <mestery> Feel free to suggest updates there as well.
21:05:22 <mestery> One final announcement: I've changed the format of the weekly Neutron meeting, per email to the list today:
21:05:23 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2014-October/048328.html
21:05:38 <mestery> The hope is this allows for more collaboration rather than a simple status report each week.
21:05:51 <marun> +100
21:05:55 <mestery> Thanks to carl_baldwin for updating a lot of wiki pages today on this front!
21:06:01 <markmcclain> +100
21:06:38 <mestery> OK, lets move along then.
21:06:42 <mestery> #topic Bugs
21:06:46 <mestery> enikanorov_: Here?
21:07:25 <mestery> I've been focused on RC candidate bugs for the past week, if anyone has any updates on other bugs which should be on our radar, please jump in here.
21:08:16 <matrohon> hi : lot of dicussions on this one : https://bugs.launchpad.net/neutron/+bug/1361540
21:08:17 <uvirtbot> Launchpad bug 1361540 in neutron "no mechanism driver calls for gateway port removal" [High,In progress]
21:08:31 <Sukhdev> mestery: How come all the ones with juno-rc-potential bugs did not make rc2?
21:08:32 <mestery> matrohon: Yes, we had spoken about this, and I had chatted with markmcclain the past Friday on this one.
21:08:57 <mestery> Sukhdev: A variety of reasons: Not being a release blocker, not being merged in master are the most likely ones.
21:09:04 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1361540
21:09:44 <mestery> matrohon: Are you still of the opinion that 1361540 is an RC candidate bug given our discussion last week?
21:10:20 <markmcclain> mestery: still would like to better understand armax's concern on that one
21:10:37 <regXboi> mestery: this is just the tip of the iceberg
21:10:41 <markmcclain> seems a simplified fix would be better
21:10:56 <regXboi> the whole external gateway code doesn't handle state on deletes correctly
21:11:14 <matrohon> mestery : this has backend side effects, garyk seems to agree that this is a huge bg
21:11:28 <regXboi> the order of operations is not correctly reversed before new state is applied - we've had to code around this issue internally
21:11:34 <mestery> regXboi: Is there another bug filed for this? I imagine you discovered this while looking at code recently?
21:11:54 <matrohon> markmcclain :i've tried to do it as simple as I could!
21:12:14 <regXboi> mestery: no on the bug filing - I've been trying to boil it down to the minimal fix needed
21:12:39 <mestery> regXboi: Ack. Can you file one to track the issue, especially if it affects 1361540 which is under review now?
21:12:48 <regXboi> and if by recently, you mean in this cycle, then yes
21:12:48 <rkukura> Isn’t the fix here to do deletion by calling the plugin?
21:13:06 <regXboi> mestery: give me an action and I'll file something
21:13:30 <mestery> #action rkukura to file bug for external gw code deletions
21:13:33 <mestery> #undo
21:13:34 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x32bff10>
21:13:41 <mestery> #action regXboi to file bug for external gw code deletions
21:13:57 <regXboi> mestery: ack
21:14:37 <amotoki> what about https://bugs.launchpad.net/neutron/+bug/1378525 ?
21:14:38 <uvirtbot> Launchpad bug 1378525 in neutron "Broken L3 HA migration should be blocked" [High,Fix committed]
21:14:47 <amotoki> woops wrong link.
21:14:48 <mestery> amotoki: Looking
21:14:53 * mestery waits
21:15:05 <matrohon> rkukura : markmcclain's cleanup  previous patch introduced more calls to _delete_port, bypassing core_plugin
21:15:30 <rkukura> matrohon: sounds like this needs to be fixed
21:15:34 <regXboi> rkukura: as I remember it, the issue is one of state
21:15:56 <regXboi> because the linear algebra of the operations is wrong
21:15:57 <amotoki> mestery: the link is correct.
21:16:16 <amotoki> mestery: The bug proposes to prohibit L3 HA attribute update
21:17:00 <markmcclain> mestery: +1 https://review.openstack.org/#/c/126706/ if RC3 opens
21:17:04 <amotoki> it is an API change and worth considered for RC.
21:17:05 <mestery> amotoki: This seems like a candidate, yes, but I don't know if it's a release blocker itself.
21:17:10 <mestery> markmcclain: Looking
21:17:22 <markmcclain> mestery: but it's not a release blocker
21:17:35 <markmcclain> I think that we can release note that there is an error in the API there
21:17:35 <mestery> markmcclain: Exactly. If we find something else, I'll cherry-pick that one in.
21:17:41 <amotoki> agree it is not a release blocker.
21:17:41 <mestery> markmcclain: Ack.
21:17:48 <markmcclain> we did that previously
21:18:08 <mestery> #action mestery to add release note for https://bugs.launchpad.net/neutron/+bug/1378525 indicating the error with the API.
21:18:10 <uvirtbot> Launchpad bug 1378525 in neutron "Broken L3 HA migration should be blocked" [High,Fix committed]
21:18:15 <mestery> Any other bugs for discussion?
21:18:19 <matrohon> pleasa have a look to : https://bugs.launchpad.net/neutron/+bug/1372438
21:18:21 <uvirtbot> Launchpad bug 1372438 in neutron "Race condition in l2pop drops tunnels" [Medium,In progress]
21:18:59 <matrohon> the patch is ready, it re introduce a previous merged patch, deleted by DVR stuff
21:19:19 <matrohon> https://review.openstack.org/#/c/123403/
21:19:27 <mestery> matrohon: Lets get that one into master by tomorrow so if we do roll an RC3 I can cherry-pick it back.
21:19:45 <mestery> Looks like carl_baldwin has some issues with that patch at the moment from looking at the review.
21:20:23 <carl_baldwin> Mostly surprised that no UTs are affected.
21:20:58 <mestery> These are all good fixes, but I don't think they are release blockers at the moment.
21:21:01 * marun is not so surprised
21:21:02 <matrohon> mestery : thanks, e and vivek are trying to addrees the UT issue, but i'ts really difficult to produce race conditions with UT
21:21:11 <mestery> matrohon: Ack
21:21:33 <carl_baldwin> marun: Not so much surprised as saddened.  :’(
21:22:08 <mestery> Any additional bugs anyone wants to bringup with the broader team here?
21:23:13 <mestery> #topic Docs
21:23:15 <mestery> emagana: Hi there!
21:23:16 <emagana> Hi!
21:23:20 <mestery> How are Juno docs looking?
21:23:31 <emagana> not sure how to answer that...
21:23:33 <emagana> lol
21:23:37 <mestery> lol
21:23:46 <emagana> well, I have a broader question
21:24:07 <emagana> Does Neutron team consider DVR and L3 HA stable features ready for production?
21:24:19 <marun> that is a very good question
21:24:49 <mestery> emagana: Is this in the context of how much we document or simply how we label them?
21:24:52 <marun> given the relative lack of comprehensive testing for these rather complicated features, I would be interested to hear arguments suggesting that they are ready for production.
21:24:59 <Swami> Do you have any concerns.
21:25:07 <emagana> Ok, that was the question from the Docs Folks
21:25:33 <emagana> The plan is to document what is stable and ready for production
21:25:47 <emagana> in the installation guide which is one of the top ones
21:26:20 <emagana> So, the point is these features will not be covered in the installation guide but will be covered in the networking guide
21:26:23 <Swami> emagana: we can help the documentation effort for the dvr.
21:26:46 <mestery> emagana: I think that sounds like a fair assessment.
21:26:52 <mestery> Swami: Does that sound ok to you?
21:27:05 <emagana> Swami: Thanks! I count with that help, but the question here is if NEUTRON team recommends to use these features yet??
21:27:20 <Swami> I need to understand what is blocking us from documeting or stating that the dvr is not production ready.
21:27:26 <marun> I think you can guess at my vote
21:27:33 <marun> Swami: how about some testing that it works?
21:27:59 <Swami> marun: what kind of test results are you expecting.
21:28:05 <carl_baldwin> Are there any known production deployments?
21:28:14 <emagana> Swami: Dont take this wrong but our experience with shinny good looking new features is not the best one once a bigger community start testing them
21:28:22 <marun> Swami: I'm expecting test plans for all major use cases and implementations of those test plans.
21:28:29 <markmcclain> carl_baldwin: none that I know of
21:28:40 <mestery> carl_baldwin: +1 to markmcclain's comments, especially given how new it is.
21:28:55 <emagana> carl_baldwin: for Neutron many!
21:29:10 <salv-orlando> I don’t even know what we are talking about.
21:29:15 <carl_baldwin> emagana: I meant deployments that use either new feature.
21:29:18 <emagana> carl_baldwin: using those features obviously none but they will consider to use them if we declare them stable enough
21:29:46 <salv-orlando> we’ve never ever in our craziest days suggested a feature or component was production ready in the 1st release where it appeared
21:29:50 <emagana> I want the team to vote how to declare those features
21:29:53 <marun> salv-orlando++
21:29:57 <emagana> mestery: What is your opinion?
21:29:57 <SumitNaiksatam> perhaps a chicken and egg quesion, how will people start using a feature if its not made available in the docs?
21:29:59 <amotoki> At least I think dvr and l3-ha are new featrues and they are not mature compared to other core plugins.
21:30:11 <mestery> I think it's hard to call a brand new feature production ready out of the gate.
21:30:20 <mestery> Now, we expect people to use it and deploy it and report issues.
21:30:21 <carl_baldwin> +1
21:30:27 <emagana> OK, The proposal is this:
21:30:28 <mestery> But if no one is using it, it's hard to say it's production quality
21:30:31 <mestery> My $0.02
21:30:36 <salv-orlando> folks - are we discussing if they are production ready or if they should be documented?
21:30:36 <marun> emagana: unless we've seen considerable usage from customers (and responded to the issues involved), or we have comprehensive testing, of course it isn't production-ready yet.
21:30:39 <Swami> SumitNaiksatam: yes I agree.
21:30:46 <mestery> SumitNaiksatam: It will be in the networking guide, just not the install guide.
21:30:48 <salv-orlando> to me both questions are no brainers honestly
21:30:56 <SumitNaiksatam> mestery: ah okay
21:31:12 <mestery> salv-orlando: A voice of sanity :)
21:31:25 <mestery> DVR is not production ready and needs to be documented.
21:31:26 <emagana> Declare that these features are new and certain amount of external testing is needed (This is going to be in the Install Guide)
21:31:27 <mestery> Do people agree?
21:31:35 <emagana> On the networking guide we will document them properly
21:31:37 <marun> ++
21:31:41 <markmcclain> emagana: +1
21:31:42 <mestery> Is that the gist of the argument here?
21:31:45 <amotoki> emagana: +1
21:31:48 <mestery> emagana: +1
21:31:53 <carl_baldwin> +1
21:32:01 <kevinbenton> so we agree to say it’s production ready and not to document it, right?
21:32:10 * mestery throws tomatoes at kevinbenton.
21:32:12 <mestery> :P
21:32:14 <Swami> +1
21:32:17 <marun> kevinbenton: +1 ;)
21:32:27 <glebo> emagana: +1
21:32:38 * pc_m incubated feature? proof of concept?
21:32:41 <emagana> so, install guide will be ready  :-)
21:32:55 <rkukura> Too bad we don’t have a preview subtree ;)
21:33:07 <emagana> Networking guide will take more time and will be completed during kilo release
21:33:22 <mestery> emagana: I figured as much there. :)
21:33:25 <glebo> kevinbenton: not quite. I heard: it's not production ready, it will be mentioned in install guide as shiny new, and will be documented in networking guide. Right?
21:33:48 <kevinbenton> glebo: +1
21:34:00 <carl_baldwin> glebo: +1 that is what I heard too.
21:34:19 <glebo> my "right" was meant for emagana
21:34:24 <glebo> emagana: right?
21:34:25 <Sukhdev> mestery emagana: Can you summarize the conclusion?
21:34:47 <mestery> Sukhdev: See glebo's response above.
21:34:48 <glebo> cut n paste my @kevinbenton
21:35:01 <mestery> emagana: An exciting doc's update this week!
21:35:01 <glebo> *cross talk*
21:35:05 <emagana> Sukhdev: Install guide will mention that DVR and L3 HA are new features and more testing is required to be declared stable
21:35:21 <Sukhdev> emagana: Thanks
21:35:29 <emagana> Sukhdev: Networking guide will describe both features
21:36:15 <markmcclain> install docs have always trailed the release of production features, so I think that emagana's proposal is following what we've done for cycles now
21:36:19 <emagana> If somebody wants to be part of the Networking-Docs discussions we meet every Frydat 9:00 pst
21:36:26 <Sukhdev> emagana: So, will I have enough documentation, if I wanted to play with these features and try them out, right?
21:36:26 <glebo> emagana: and probably ought to mention that they are <queue show host voice over> making their big debut
21:36:54 <emagana> glebo: Yes!
21:37:11 <mestery> markmcclain: ++
21:37:15 <emagana> Sukhdev: Not right away, ENtworking guide will take more time. All focus are on Install guide and Admin Guide
21:37:22 <emagana> ENtworking = Networking
21:37:54 <mestery> emagana: Any other doc updates for us today?
21:38:04 <emagana> mestery wants to suffer more today!
21:38:10 <mestery> emagana: :P
21:38:11 <emagana> mestery: No more!
21:38:13 <mestery> Thanks sir!
21:38:26 <mestery> #topic On-Demand Agenda
21:38:37 <mestery> So, per the new meeting format, we'll walk through today's On-Demand agenda
21:38:49 <mestery> First up, a new peer review process for core reviewers has been proposed:
21:38:50 <mestery> #link https://etherpad.openstack.org/p/neutron-peer-review
21:39:06 <mestery> Please see the etherpad page for the goals behind this process and for the format of the review process.
21:39:37 <mestery> We're going to try this out in Kilo and see how it goes.
21:40:12 * mestery notes everyone is likely reading now.
21:40:31 <regXboi> so I see two proposals on that page
21:40:42 <regXboi> *which one* will be tried in Kilo, or both :)
21:41:10 <marun> regXboi: I think that's up to the team to decide.
21:41:21 <mestery> regXboi: What marun said.
21:41:42 <regXboi> ok, that wasn't 100% clear from mestery's text
21:41:48 <marun> regXboi: It's a proposal, not a fait accompli, and everyone's input will be considered before we go forward.
21:42:31 <emagana> mestery: Is this process new for all OpenStack?
21:42:38 <Sukhdev> mestery: Good write up and makes a lot of sense
21:42:39 <marun> emagana: Neutron only at this point.
21:42:45 <mestery> emagana: No, we're the first ones to try it. :)
21:43:07 <emagana> mestery: My opinion is that brings a lot of overload to the review process but I could be understanding it wrong!
21:43:39 <mestery> emagana: That was my concern as well, but the idea is to collect relevant data around Neutron cores and provide valid feedback to people.
21:43:48 <marun> emagana: We definitely don't want to add process for its own sake, so the goal is balancing the benefits with the cost.
21:43:53 <mestery> emagana: Hopefuilly we'll try this out and adjust accordingly.
21:44:13 <glebo> while reading it, the first thing I thought of was a reputation system that people interacting with a reviewer can submit, with # of stars out of 5, and comments section, either with or without name attached. Not unlike rating an app in app store, or a seller in ebay
21:44:18 <marun> emagana: If you have suggestions for how to achieve some of the stated goals differently, that would be great to hear about.
21:44:39 <mestery> glebo: Lets hope contributors don't think of core reviewers as "apps in app store" :P
21:44:40 <marun> emagana: Also, the alternate proposal included might be a lower-cost way of achieving a similar result.
21:44:45 <emagana> mestery: I like better the second proposal but removing the anonymously part. We are all professional who can take feedback properly
21:44:54 <marun> emagana: I think you're wrong on that point.
21:45:02 <glebo> mestery: lmao!
21:45:37 <glebo> mestery: heavens, no! just trying to think of a very quick, painless way to begin collecting interaction-based data
21:45:53 <emagana> Besides, if I am not performing to the expected level, there should be a proper enhancement plan and if after that things dont change then bye bye
21:46:00 <marun> emagana: It's a common phenomenon that people are nice in public because they don't want to be mean or hurt someone's feelings.  Anon feedback is a way of leveling things.
21:46:07 <Sukhdev> Folks, I see an attempt is being made to make the process work better - but, have one concern/issue regarding the survey
21:46:18 <salv-orlando> mestery: I want to be candy crush saga
21:46:27 <markmcclain> salv-orlando: haha
21:46:36 <glebo> emagana: if history has shown us anything, it's that humans are absolutely not consistently "professionals who can take feedback properly", though I wish it were so
21:46:37 <Sukhdev> salv-orlando :_)
21:46:41 <mestery> salv-orlando: That's a good choice. :P
21:46:42 <marun> emagana: that is the intention here, to provide avenues for improvement if someone is not seen to be meeting consensus expectation.
21:47:11 <marun> emagana: and if any of us don't want to have to meet the expectations of our peers, it's probably the case that we don't want to be on core anymore.
21:47:27 <marun> Sukhdev: do tell!
21:47:46 <glebo> salv-orlando: ++ *lmao again*
21:48:03 <kevinbenton> marun: if it’s anonymous and only a subset of the cores, it makes their voice seem over-representative
21:48:37 <Sukhdev> Folks may have different openions about different core based upon their interactions - I may find one core very useful (in one situation to me) and may not find other core that useful - hence, my survey may be very skewed
21:48:47 <Sukhdev> and this will be true for most part, no?
21:48:56 <salv-orlando> I think the first iteration of this survey is more for assessigne the survey itself.
21:49:05 <marun> Sukhdev: That is certainly a fair point.
21:49:07 <mestery> salv-orlando: Yes, we're surveying the survey.
21:49:14 <markmcclain> salv-orlando: yeah and I think that is the right approach
21:49:17 <salv-orlando> once we address feedback and improve it, then the data set will be expanded
21:49:20 <emagana> mestery: So, core status is only attached to core reviews. Any contribution to community staff such as testing, mailing lists, docs is not considered?
21:49:26 <marun> salv-orlando: +1
21:49:29 <marun> emagana: erm
21:49:38 <mestery> emagana: That's in there (at least I recall it being there).
21:49:39 <marun> emagana: the survey questions should shed light on your question
21:49:43 * mestery goes to look
21:49:46 <mestery> emagana: What marun  said.
21:50:07 <marun> emagana: they encompass more than reviews, because core responsibility is definitely more than that.
21:50:12 <Sukhdev> So, my suggestion will be that cores should review cores - based upon their involvement in various parts…..not the general community
21:50:16 <emagana> marun: Go it!
21:50:30 <marun> Sukhdev: That's the intent.
21:50:31 <kevinbenton> Sukhdev: i thought that was already the intention
21:51:04 <marun> kevinbenton: The proposal is that the PTL will be responsible for choosing who reviews who, at least initially.
21:51:06 <mestery> As with most things, once we implement this, we'll iterate a bit and see how it goes, adjusting as necessary.
21:51:18 <emagana> emagana has one thing to make him sleepless!
21:51:27 <glebo> Sukhdev: if one of cores main roles is to do reviews for the main community, then the community is a HUGE customer base for the cores. And shouldn't the customer base of that sort have voice to the service being provided?
21:51:31 <marun> kevinbenton: It's unlikely that Kyle will assign reviewers where conflict or friction is present.
21:51:32 <Sukhdev> marun kevinbenton: thanks for clarifying that - I probably missed that :-)
21:51:44 <mestery> I'll make sure to wave my magic PTL wand gently.
21:52:01 <marun> kevinbenton: It's not perfect, but it's a starting point.  The goal here is useful feedback more than performance assessment anyway.
21:52:07 <kevinbenton> marun: a bad pairing could ruin the perspective of the entire community for a core and cause them to burn out, so we need to be really careful here
21:52:21 <marun> kevinbenton: I trust the PTL to be careful, as you say.
21:52:50 <mestery> I'd like to encourage folks to add notes to the etherpad
21:52:51 <marun> kevinbenton: and there is always the option of following up with a reviewer who is being really mean, without the person under review being involved or the results being public
21:53:01 <glebo> marun: if useful feedback is the goal, then the more feedback in total the better; the larger the sample set, the more accurate it is likely to be
21:53:07 <Sukhdev> glebo: good point - however, you may be pissed off because he was harsh on your code, while the other person may be very happy, as he found the comment very useful - so, how do you come up with true evaluation?
21:53:11 <markmcclain> again it seems the goal is to focus first on making sure the tool is right before
21:53:38 <markmcclain> hence a small sample should be ok for the first round… I hate to conduct a large survey to find out we asked the wrong questions
21:53:43 <marun> glebo: sure, but we're trying to put an upper-bound on the effort involved initially
21:54:03 <marun> glebo: once we've learned what works and what doesn't, but all means, involve more people
21:54:10 <mestery> marun: +100
21:54:12 <marun> glebo: this is documented in the proposal, btw
21:54:36 <marun> markmcclain++
21:54:41 <glebo> Sukhdev: if the purpose is to "get a good grade" then you it's very tough. If the purpose is to provide lots and lots and lots of very simply, quick data points and to thereby easily be able to see overall trends over time, then that's different
21:55:02 <glebo> reminder: open, transparent
21:55:02 <marun> glebo: The latter goal is definitely paramount.
21:55:09 <sweston> I think that a lot of folk's concerns here will be resolved once the team decides on the criteria which the reviews are based on ... after this happens a lot of the subjectivity will fade away
21:55:17 <glebo> marun: me thinks so 2
21:55:23 <mestery> I'm hopeful the community agrees with the direction here.
21:55:35 <markmcclain> I like that we're looking at ways to make us better
21:55:38 <Sukhdev> marun mestery: Cores are providing very valuable service - last thing I would want to do is to discourage them or demotivate them - so, be careful..
21:55:48 <glebo> marun: but the current process being proposed seems to contradict that. Closed, hidden, subjective, selective
21:55:49 <mestery> markmcclain: ++
21:55:50 <kevinbenton> the problem with specific checkboxes to fulfull is that it encourages fitting the model
21:56:16 <salv-orlando> Sukhdev: why should this discourage or demotivate someoby?
21:56:21 <kevinbenton> a person might be discouraged from spending a whole cycle fixing a really hard problem if it will come back to bite them in other categories
21:56:24 <glebo> markmcclain: +1. That's the most important part, and shows very well on the community
21:56:30 <marun> Sukhdev: It's a balancing act, for sure.
21:56:34 <mestery> kevinbenton: Fixing something hard should never come back to bite someone.
21:56:42 <marun> glebo: in what way?
21:56:48 <regXboi> kevinbenton: +1
21:56:50 <mestery> Folks, we have 3 minutes left.
21:56:56 <mestery> Lets continue this duscssion on the ML and on the etherpad.
21:57:01 <mestery> And next week in the meeting if need be.
21:57:04 <mestery> I have one more thing to bringup here
21:57:07 <mestery> At the close of the meeting.
21:57:08 <marun> kevinbenton: cores should be graded on intent as much as effort
21:57:11 <emagana> mestery: All this process will require more commitment time for core in Neutron.. Are we increasing the minimal expected one?
21:57:29 <mestery> emagana: No.
21:57:33 <salv-orlando> kevinbenton: I like to think that we still have common sense. It’s not like we would become stupid bureacrauts that just read a survey’s outcome and take action
21:57:37 <glebo> kevinbenton: if there is a closed door review by a select few, it might well do so. If everyone who saw, touched, intereacted on that project / issue gave a very quick little rating and a comment or two, it would not b so
21:57:39 <mestery> Per markmcclain, XML support is going away, and we mean it this time: https://bugs.launchpad.net/neutron/+bug/1380787
21:57:40 <uvirtbot> Launchpad bug 1380787 in neutron "remove XML support" [High,In progress]
21:57:43 <Sukhdev> salv-orlando: Once you start to label them or start to create whispers….those could be demotivating gestures…hence, extreme care should be used
21:57:49 <marun> kevinbenton: and if you read the questions, I think you'll find that constructive involvement is being evaluated.  I'm not sure how anyone would game it anymore than they would 'game' being a good developer.
21:57:50 <kevinbenton> salv-orlando: paperwork does bad things to people
21:58:15 <emagana> mestery: Can you set up a minimal commitment time in here: https://wiki.openstack.org/wiki/NeutronCore
21:58:17 <kevinbenton> marun: gaming was a bad term. ‘change their behavior to balance more than focus'
21:58:25 <mestery> emagana: I can yes.
21:58:34 <marun> kevinbenton: If you think the proposal can be improved, your suggestions are definitely welcome.
21:58:34 <mestery> #action mestery to look at core time commitments in https://wiki.openstack.org/wiki/NeutronCore
21:58:41 <emagana> mestery: Hopw much will that be?
21:58:43 <glebo> marun: if the PTL chooses the reviewers and its deal with discretely, then it's the opposite of open, transparent, etc.
21:58:46 <mestery> Folks, < 1 minute left.
21:59:03 * mestery notes he's yelling into a wind vortex now and will conclude the meeting.
21:59:11 * regXboi happily waves goodbye to XML
21:59:12 <mestery> I'm happy to see folks engaged in this peer review process.
21:59:13 <Sukhdev> mestery: Great discussion - thanks for brining it up
21:59:25 <mestery> And I hope everyone can see the goals it's trying to solve here.
21:59:28 <amotoki> +1 for dropping XML support
21:59:31 <mestery> Lets continue the discussion on ML and in channel!
21:59:31 <marun> glebo: I'd like to hear your useful alternative.
21:59:32 <mestery> #endmeeting