15:30:53 <mestery> #startmeeting neutron-drivers
15:30:53 <openstack> Meeting started Wed May 27 15:30:53 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:56 <openstack> The meeting name has been set to 'neutron_drivers'
15:31:01 <mestery> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers Agenda
15:31:16 <mestery> Anything I missed for the agenda folks?
15:31:26 <armax> no, it’s better to start small
15:31:31 <dougwig> wasn't there a discussing of meeting times awhile back?
15:31:44 <mestery> dougwig: Yeah, this is what we settled on, or did I get that wrong?
15:31:58 <dougwig> oh, ok, no worries.  i thought it was left hanging.
15:32:26 <mestery> OK
15:32:28 <mestery> lets get rolling
15:32:34 <mestery> #topic New Spec Template
15:32:39 <armax> do we wait for amotoki and marun?
15:32:39 <mestery> #link https://review.openstack.org/#/c/182905/
15:32:47 <marun> \o
15:32:52 <mestery> marun: Hello!
15:33:06 <marun> I'd like to see the spec template cut down to use case definition only.
15:33:22 <mestery> I kind of like the direction it's going
15:33:23 <marun> mestery: hello!
15:33:34 <mestery> marun: There is concern that for some things we do need a discussion on the API before the code merges (VLAN aware VMs for example)
15:33:49 <marun> mestery: there is nothing stopping that from happening...
15:33:49 <dougwig> or the high high high level design.
15:33:59 <marun> dougwig: there is nothing stopping that from happening
15:34:00 <mestery> marun: With a trimmed down spec?
15:34:06 <marun> but I don't think the spec is the place to do it
15:34:22 <marun> for the simple reason that it continues the trend of conflating problem statement with implementation
15:34:25 <mestery> marun: Fair enough
15:34:28 <marun> and that has caused us lots of trouble in the past
15:34:32 <armax> I think there are many places where that discussion can take place: the bug report or even the initial code patch that proposes the api/model changes
15:34:50 <mestery> So, given this, do we want dougwig to reformulate his patch one more time?
15:34:53 <dougwig> we're down to problem description, proposed change, assignee, work items, and references.   marun, are you suggesting that get trimmed to just problem description?
15:34:54 <armax> frankly I am a bit baffled by teh use of the spec in such a case
15:35:00 <marun> dougwig: yes
15:35:03 <marun> armax: use-case only
15:35:15 <marun> 'what problem are we trying to solve'
15:35:22 <armax> in the end we’d be replicating json blobs and fatty tables for nothing
15:35:24 <marun> I really think we need to think about that in isolation, at least at first
15:35:37 <dougwig> hang on.  who wants to have a design discussion in launchpad, or AFTER coding?  not me.
15:35:38 <mestery> marun: Documentation lands with implementation then
15:35:43 <armax> marun: use cases it is, and that’s what dougwig did
15:35:44 <mestery> And the spec is only the problem we're trying to solve
15:35:46 <marun> no, not suggesting that dougwig
15:35:53 <marun> high level design is post-use case discussion
15:35:55 <marun> and in-tree
15:36:00 <marun> we can link to it from the spec
15:36:03 <marun> (my suggestion, anyway)
15:36:21 <marun> I think the goal should be separating the decision of goals from strategy
15:36:24 <armax> however IMO it’s important to try and capture the amount of work required, hence the work items section
15:36:26 <marun> decision -> discussion
15:36:37 <marun> armax: so you're advocating mixing things up, still
15:36:39 <dougwig> i'm just pondering that as a dev, and it's kinda yuck.  i need to file in LP, file a spec, file a devref, and only then start coding?  that's hella latency.
15:36:42 <armax> how so?
15:36:44 <dougwig> just IMO.
15:36:47 <marun> dougwig: why?
15:36:56 <marun> dougwig: today, mixing those things means things are slow
15:37:07 <mestery> marun: I see dougwig's point about it being heavy handed at first, but maybe once we try it it won't be so bad?
15:37:13 <marun> dougwig: do things separately, there might be room for actually coming to agreement
15:37:23 <marun> dougwig: as opposed to bikeshedding for ever
15:37:40 <dougwig> marun: i like to use the spec to get everyone on the same page.  here's the feature, here's why, here's the basic gist of how, so i know i'm not wasting coding time.  making that at least two code reviews is going to take quite awhile of real time.
15:37:43 <marun> again, I'm not wedded to doing any one thing anywhere
15:38:06 <mestery> marun: You are mainly advocating separating goals from strategy?
15:38:15 <dougwig> i'm also not averse to having a short template and still putting N/A in half of it if you want to do it another way.
15:38:21 <marun> but I'm going to be pretty disappointed if we continue to confuse 'what' with 'how'
15:38:29 <armax> i am not sure latency is a problem exarcerbated by this proposal, actually
15:38:46 <marun> mestery: yeah
15:39:04 <dougwig> armax: put yourself in the shoes of someone that doesn't know a dozen cores to expedite things.
15:39:04 <armax> some of the things that we have discussed in the spec so far can be more effectively discussed in the code
15:39:15 <marun> I think that we tend to go deep in implementation before we've really firmed up what we're trying to do
15:39:17 <mestery> So, if the "what" is in LP as an RFE bug, and the "how" is in devref, why do we need a spec?
15:39:23 <marun> And it causes problems on a number of axis
15:39:25 <armax> and the result of the review cycle is that you already have code into shape
15:39:52 <mestery> I'm trying to wrap my head around what a spec is providing in this new world order.
15:39:57 <marun> mestery: I'd be ok with that approach - it's what we originally discussed - but it didn't seem to satisfy sdague from what I heard
15:40:00 <dougwig> so, we don't differ on letting folks write up a how if they want to before coding.  we're just talking about the cosmetics of where and to what audience we aim the writing, right?
15:40:11 <marun> dougwig: I think so, yeah.
15:40:18 <mestery> marun: I think in general the ops like specs, so moving away from it seemed challenging
15:40:30 <marun> dougwig: I think we want high level design before coding begins
15:40:31 <mestery> dougwig: ++
15:40:35 <dougwig> that comes down to, do we think we'll end up with better dev docs, at the cost of easier discoverability?
15:40:43 <dougwig> (waits for explosions.)
15:40:47 <armax> I think that the spec to me is about scoping
15:40:51 <mestery> dougwig: Good summary and ... BOOM!
15:41:05 <mestery> armax: Scoping in terms of how much work and how long?
15:41:10 <armax> yes
15:41:11 <marun> armax: why don't we scope post use-case?
15:41:28 <armax> you can scope by use case
15:41:34 <armax> and that’s feature or product scoping
15:41:40 <marun> dougwig: what's the discoverability cost? not doing everything in one place?
15:42:03 <marun> armax: I think we can only scope post use-case
15:42:04 <mestery> marun: That and not being consistent with where things are archived vs. other projects I guess.
15:42:12 <mestery> marun: Agree on scoping post-use case
15:42:16 <armax> the amount of use cases can give you a sense of how much it takes to implement the end-to-end solution
15:42:33 <dougwig> specs is easier to browse for reviews, especially for newer folks. i'm also fairly fond of the atomicity of specs for agreeing to consensus, but i can see that's personal opinion.
15:42:34 <armax> marun: but that happens in iteration while writing the spec!
15:42:36 <marun> mestery: if we link to dev docs in specs though?
15:42:53 <marun> dougwig: I think it's a pretty huge cost review-wise
15:43:06 <marun> armax: *sigh*
15:43:08 <mestery> marun: That solves it, but adds another layer (the filing of the spec)
15:43:21 <marun> armax: we're reinventing project management, badly.
15:43:33 <armax> marun: no need to be sorrow…I am happy to back down
15:43:42 <dougwig> marun: how so?  we're talking maybe 5-10% of RFE's *needing* specs, it's not mandatory unless requested, and how is reviewing in -specs different than in devref/ ?  in most cases, it just happens as an RFE and code.
15:43:43 <mestery> :)
15:43:56 <marun> dougwig: I'm simply burned out.
15:43:57 <armax> marun: there is no single way of doing this
15:44:14 <marun> The bottom line for me is that I'm tired of wasting effort.
15:44:36 <marun> It's my feeling that conflating use cases with implementation with scoping with work items is just too messy.
15:45:00 <mestery> I think separating use cases out using RFEs is good
15:45:01 <marun> But if I'm the only one that feels that way, maybe my view shouldn't be considered.
15:45:12 <dougwig> i'm not sure how to respond to that. we're either reviewing designs for big stuff in devref or specs.  we're not adding a hoop here, unless i'm missing something.  it's still gone for most stuff.
15:45:14 <armax> but no-one is mentioning implementation, afaik
15:45:22 <marun> dougwig: it's separation of concerns
15:45:34 <marun> dougwig: put everything in one big pile, and it's pretty hard to do anything well.
15:45:35 <armax> work items != design or implementation
15:45:50 <dougwig> \n\n <-- separation.   (sorry, morning humor.)
15:46:10 <marun> again, it appears that I'm the only one that feels this way so I'm going to suggest consensus rules and we can move on.
15:46:25 <mestery> OK, lets collect comments on dougwig's patch then
15:46:30 <mestery> And he can re-roll as needed
15:46:34 <mestery> Sound fair?
15:46:42 <dougwig> alright, we've got a process that is heavily stream-lined, uses RFEs for almost everything, and we're down to what i think amounts to personal preference for where the larger conversations happen. how do we resolve this?
15:46:47 <armax> the only reason I think that work items could be useful to capture in teh spec is because they can give us a sense of how big and impactful the feature is, perhaps any feature worth of a spec is big and impactful and on that basis it can be ignored as it gives us no more information
15:47:22 <mestery> armax: I'm with you on that, I guess the sticky point is where we capture that stuff.
15:47:25 <marun> dougwig: it's resolved. I'll stop complaining.
15:47:28 <dougwig> armax: that was my basic reply to your comments.  if i have to comment on models and rpc and such, it's more detailed than i wanted, and is basically back to the old spec template.
15:47:31 <armax> so I am ok if we only had description and proposed change
15:47:43 <armax> and that should happen by clarifying the use cases being addressed
15:47:55 <armax> if this doesn’t work, we’ll revisit 6 months from now
15:48:20 <armax> dougwig: that’s ok
15:48:52 <mestery> dougwig: Do you have enough info to move forward now? Have we resolved the concerns raised here?
15:48:54 * mestery isn't sure yet
15:49:19 <dougwig> i have enough to chop it down further, yes. i didn't hear consensus yet, but i'll see how close we can get.
15:49:23 <armax> I think we do, let’s have dougwig respin and marun review
15:49:39 <armax> and mestery and I will follow
15:49:40 <mestery> #action dougwig to re-spin the patch and everyone to review again
15:49:48 <mestery> Lets move on to the next item here. Sound ok?
15:49:49 <armax> shortly after
15:50:08 <mestery> #topic RFE Bug Review
15:50:10 <mestery> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe
15:50:16 <mestery> We have 9 RFE bugs filed now
15:50:25 <mestery> Shall we walk through them?
15:50:32 <mestery> This entire process is new, so lets see what we can come up with here
15:50:47 * armax wishes that list stayed so small
15:50:53 <mestery> OK
15:50:53 <mestery> First one
15:50:56 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1459030
15:50:56 <openstack> Launchpad bug 1459030 in neutron "Add dns_label to Neutron port" [Wishlist,Confirmed] - Assigned to Miguel Lavalle (minsel)
15:51:18 <mestery> First off
15:51:25 <mestery> Is this the type of use case we envisioned with this new process?
15:51:52 <marun> filing a spec first?
15:51:54 <marun> no
15:52:02 <mestery> marun: In this case, I think carl_baldwin filed the spec before the RFE process started
15:52:10 <mestery> I think he was just trying to comply post-fact
15:52:17 <mestery> I recall a discussion with him 2 weeks ago
15:52:37 <dougwig> this feature is tiny enough that i wouldn't expect a spec was needed.
15:52:38 <mestery> So, marun, please comment on the bug that we wan to tease out the use case more here, and less on the spec
15:52:43 <mestery> dougwig: Honestly, yes.
15:53:14 <marun> is the spec even matching up with the rfe?
15:53:19 <marun> the spec is 337 lines
15:53:35 <marun> that's probably a diversion
15:53:38 <mestery> I think the use case is simple here: We need a way to integrate Designate with Neutron
15:53:54 <armax> may I be pedantic?
15:54:06 <mestery> armax: I expect nothing less
15:54:08 <mestery> ;)
15:54:09 <armax> :)
15:54:18 <carl_baldwin> mestery: This is more about allowing nova to feed its hostname to Neutron for eventually integration with Designate.
15:54:27 <armax> I think it’s going to be hard to get people to write good RFE
15:54:41 <mestery> At first, yes, but after a while, the RFEs will be awesome armax, just wait and see.
15:54:43 <mestery> I'm serious
15:54:45 <armax> the bug report is more about the how than the what
15:54:47 <mestery> Look at specs last year, same thing.
15:55:12 <mestery> carl_baldwin: Cool! And please, we're not picking on you or your RFE, this is the first attempt at this process so we're all a little green as we go through this. :)
15:55:16 <armax> carl_baldwin said it correctly now IMO: allowing nova to feed its hostname to Neutron for eventually integration with Designate
15:55:34 <armax> the how is ‘Add dns_label to Neutron port’, but that can be just one of the how’s
15:55:43 <armax> mestery: +1 indeed
15:55:47 * carl_baldwin knows when he’s being picked on
15:55:49 <mestery> :)
15:55:58 * armax does not pick
15:56:01 <mestery> carl_baldwin: Any chance you could update the description to more of a "What" then the "how"?
15:56:15 <marun> So, action item to provide examples/docs around use-case definition?
15:56:28 <marun> Not something heavy and formal, but emphasizing the 'what'?
15:56:32 <dougwig> is this only about designate, or is it also fixing the bug of dnsmasq not setting the hostname?
15:56:47 <mestery> dougwig: I *think* the latter is a separate issue
15:57:01 <marun> that's what use cases are supposed to let us figure out
15:57:14 <marun> if something isn't in the use case, it's out of scope unless the use case gets updated
15:57:18 <marun> that friction is intentional
15:57:26 <carl_baldwin> dougwig: dnsmasq can set the hostname if nova gives it to Neutron.
15:57:31 <marun> so that we don't creep at every step
15:58:04 <carl_baldwin> Both are in the description.  It isn’t very long.
15:59:50 <dougwig> the spirit of this process is getting folks quickly on the same page and getting things rolling, right?  we can either go retro-edit the RFE to be exactly what the process wants, and or just say, "go", since the info is there in some form, and the process is new, and this isn't terribly complicated.  i'd vote "go".
16:00:02 <armax> one question I have a process
16:00:11 <marun> sure, 'go'
16:00:28 <armax> what does moving to ‘confirmed’ mean?
16:00:30 <marun> I'm not trying to hold carl up.  I'd just like to see us learn from this.
16:00:53 <mestery> marun: ++, we're learning as we go here.
16:00:55 <armax> that the RFE is blessed to happen?
16:01:04 <mestery> armax: enikanorov_ spoke to me and we agreed that we had to mvoe them out of new so confirmed seemed appropriate.
16:01:15 <mestery> armax: No, just so it's not new and it doesn't cause our stats to look awful :)
16:01:22 <mestery> Open to another state if it makes more sense
16:01:28 <mestery> Triaged would also work once we've looked at these.
16:01:45 <dougwig> or targeting it to a milestone.
16:01:54 <armax> mestery: ok
16:02:06 <mestery> dougwig: Yes.
16:02:11 <mestery> So, we're all +1 on this RFE?
16:02:19 <carl_baldwin> That brings up a question.  Does it make sense for Eugene to triage rfe bugs?  He set importance and status which may have different meanings in this context.
16:02:38 <armax> the only reason why I am asking is that as a neutron driver I’d want to see how that list varies over time and what new stuff I need to review
16:02:52 <armax> and I don’t want to necessarily rely on my email notifications to know what’s going on
16:02:57 <mestery> I think it makes sense for hte drivers team to triage these ones
16:03:02 <mestery> armax: Me either
16:03:08 <marun> carl_baldwin: I don't think it does.  Having things tagged rfe should be the only thing necessary to bring it to feature triaging.
16:03:17 <armax> I’d like to have a filter I can use to see the ‘unvetted’ RFE's
16:03:55 <mestery> armax: You're always asking for more :)
16:03:58 <armax> an initial ‘confirmed’ state is fine, so does this mean that as soon as one driver look and comment on the change, the bug goes to triaged?
16:04:16 <mestery> armax: I think we'd need some sort of consensus perhaps, but maybe that's not right either
16:04:28 <enikanorov_> carl_baldwin: probably i've set importance to a few 'bugs' before guessing that it is a new process
16:04:28 <mestery> OK
16:04:39 <mestery> 25 minutes left
16:04:42 <mestery> Lets circle back here
16:04:49 <mestery> And decide what to do with this particular RFE
16:04:57 <mestery> So we close the loop on the process for our first RFE
16:05:02 <armax> ship it?
16:05:05 <mestery> :)
16:05:06 <armax> :)
16:05:38 <marun> ship it
16:05:41 <mestery> :)
16:05:55 <mestery> I thought perhaps I'd involve the Lt. for the area it's touching, to ensure resources exist, etc.
16:05:59 <mestery> But given that hasn't merged yet
16:06:03 <mestery> For this one, I agree, ship it.
16:06:06 <dougwig> +1
16:06:12 <mestery> carl_baldwin: Do you have someone who is working on this? Is it you?
16:06:25 <mestery> carl_baldwin: Looking for guidance on a milestone to assing this one to. Liberty-1 is in 3 weeks, is that doable?
16:06:37 <marun> mestery: +1 to delegating when possible
16:06:48 <mestery> marun: Yes, that's the approach I'll take once the Lt. patch merges
16:06:50 <carl_baldwin> mlavalle is going to drive this one with the help of some Designate guys.
16:07:03 <mestery> carl_baldwin: Does Liberty-1 seem feasiable?
16:07:05 <carl_baldwin> I’m not going to be very hands-on at all here.
16:07:19 <dougwig> i'm hoping/praying that as the process is refined, a driver or lt can just move the rfe along in the process without needing to hold a meeting.  :)
16:07:49 <armax> so, we said the spec here is not required, right?
16:07:50 <mestery> dougwig: The one missing piece is ensuring resources are available, but yeah, less meetings.
16:07:54 <mestery> armax: Yes
16:07:56 <carl_baldwin> mestery: I’m not sure L-1 is feasible for full designate integration.
16:08:27 <mestery> carl_baldwin: I've moved it to L1 for now, we'll move it out if it's not done
16:08:27 <armax> however, do we take some of the design considerations in the devref itself?
16:08:38 <mestery> carl_baldwin: But this lets mlavelle at least start pushing patches
16:08:39 <armax> It looks like there were a few backs and forths on the spec itself
16:08:43 <carl_baldwin> But, if we treat this as just the work to add dns_label field and the associated validation, then L-1 is feasible.
16:08:45 <mestery> armax: Yes, that's right.
16:09:12 <dougwig> armax: or the code, if it hits in parallel.
16:09:19 <armax> ok
16:09:38 <mestery> OK, shall we move on and try another one of these?
16:09:55 <mestery> We have an example from the other side of the spectrum now
16:09:57 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1450617
16:09:57 <openstack> Launchpad bug 1450617 in neutron "Neutron extension to support service chaining" [Undecided,In progress] - Assigned to cathy Hong Zhang (cathy-h-zhang)
16:10:00 <mestery> Service chaining
16:10:05 <armax> dougwig: to me most of the spec content would be candidate for a devref doc that says ‘dns resolution in Neutron'
16:10:07 * mestery reads the "use case"
16:10:48 <armax> mestery: I think that this is not a neutron extension
16:10:49 <dougwig> the third rfe is a dup, right?
16:10:58 <mestery> dougwig: I hope so
16:11:08 <mestery> armax: This, as written, is a LOT of things
16:11:24 <armax> the scope of this is so broad that it’s an entirely new system
16:11:26 <dougwig> this, to me, is either a bunch of RFE's, or a spec, or both.
16:11:28 <mestery> armax: Crisply put, the RFE is right: Neutron does not support service chaining. But I don't see enough about the "why" here
16:11:36 <mestery> dougwig: ++
16:11:49 <dougwig> back up, is this something that has to be in neutron, or started outside?
16:11:57 <armax> I’d rather see RFE’s that tells me what you need from Neutron to support integration with an SFC system
16:12:18 <mestery> There is no reason this needs to be in Neutron
16:12:28 <mestery> It could be outside as an extension API of some sort
16:12:41 <armax> yes
16:12:53 <mestery> dougwig: You mentioned multiple RFEs, I think you're right.
16:13:00 <mestery> Splitting this into finer use cases would help
16:13:07 <armax> I can go over the bug report and advise cathy
16:13:15 <mestery> marun: Curious on your thoughts on this one, given it's at the opposite side of the previous one in the spectrum of RFEs
16:13:17 <armax> if you guys trust me, we can move on to the next bug
16:13:22 <mestery> armax: I trust you :0
16:13:24 <mestery> I'm good to move on
16:13:33 <armax> I mean, we can continue discussing
16:13:36 <dougwig> armax: i trust you, but i wonder, if this should start outside, does it need to go through our process?
16:13:40 <armax> but it most likely take us all day
16:13:40 <marun> mestery: I think the idea should be to file rfe's for capabilities required to do this out of the tree.
16:13:46 <armax> dougwig: indeed
16:13:55 <mestery> marun: ++, armax is in agreement as well I think
16:14:02 <mestery> ok lets move on
16:14:06 <mestery> and skip the next one too
16:14:14 <armax> dougwig: my point is that I am going to work on cathy to steer her in the right direction
16:14:16 <mestery> armax has that one covered too
16:14:24 <mestery> Which leads us here
16:14:24 <dougwig> armax: +1
16:14:26 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1453906
16:14:26 <openstack> Launchpad bug 1453906 in neutron "Implement Routing Networks in Neutron" [Undecided,New]
16:14:30 <mestery> Another carl_baldwin RFE! :)
16:14:41 * carl_baldwin has been busy.
16:14:52 <mestery> carl_baldwin: Indeed ;)
16:15:16 <carl_baldwin> Actually, we may want to discuss this a bit more and how it fits with the one mestery filed yesterday about segments.
16:15:38 <mestery> There is interest in this sort of thing, thus the one I filed: https://bugs.launchpad.net/neutron/+bug/1458890
16:15:38 <openstack> Launchpad bug 1458890 in neutron "Add segment support to Neutron" [Undecided,Confirmed]
16:15:42 <carl_baldwin> Also, I don’t have anyone to delegate this to yet.  Hope to soon.
16:16:02 <mestery> carl_baldwin: This is clearly an L3 thing, so we'll need to find someone there, I'll work with you
16:16:06 <carl_baldwin> We should probably take this one offline, mestery.
16:16:07 <mestery> to help if you want it
16:16:12 <mestery> carl_baldwin: Ack
16:16:43 * mestery notes all the remaining RFEs are from carl_baldwin :)
16:16:48 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1453921
16:16:48 <openstack> Launchpad bug 1453921 in neutron "Implement Address Scopes" [Undecided,New]
16:17:03 <carl_baldwin> I guess others just haven’t caught on yet.  ;)
16:17:23 <mestery> carl_baldwin: I may use you as an example at next week's neutron meeting if you're ok with it :)
16:17:23 <mestery> In a good way ;)
16:17:50 <dougwig> process question, do we all need to parse the fine details and agree, or is it enough to read enough to be able to say, "yes, this fits, the subject matter expert should definitely proceed" kind of deal?
16:17:54 <carl_baldwin> Sure, good or bad, I’m happy to be an example.
16:17:59 <armax> it sounds some of these bugs are just placeholder :(
16:18:22 <mestery> dougwig: Ideally we just review this on our own time, comment in the bug, and use this meeting for contentious things.
16:18:23 <mestery> Make sense?
16:18:28 * armax goes to read the spec :(
16:18:30 <carl_baldwin> armax: I’m not sure what else they should be.  Until I know what is wanted, I hesitate to add much detail.
16:18:52 <armax> carl_baldwin: yes, we’d need an RFE bug template :)
16:18:52 <mestery> armax: We're working through the new process yet, I applaud carl_baldwin for being the first into the water :)
16:19:02 <dougwig> mestery: define reviewing.  in a waterfall model, it'd need to be near perfect before work begins.  in a more agile model, the rough cut has to be right, and is refined as it goes.  i prefer the latter, but am checking.
16:19:03 <mestery> armax: o_O
16:19:27 <mestery> dougwig: I just meant reviewing the high-level RFEs, all we're agreeing by reviewing and saying "yes" is we agree the use case is compelling, we'll review the design later.
16:19:37 <armax> mestery: true, but if we don’t try harder, the way RFE’s are filed is useless
16:19:50 <mestery> armax: I agree completely, but we'll sort this out.
16:19:51 <armax> it’s just a checkmark
16:20:37 <armax> perhaps it makes sense to mandate RFE only for ‘new’ ‘new’ stuff?
16:20:46 <marun> I do think having guidelines around rfe description makes sense
16:20:50 <armax> and deal with the backlog the way we used to until it drains?
16:21:00 <mestery> marun: Would you be up for adding an RFE template into devref somewhere? That way we can point people there.
16:21:01 <armax> marun: +1
16:21:16 <mestery> If not, I can take a crack, but you have some distinct ideas here which are worth putting down.
16:21:27 <armax> marun: where would we capture it? In the blueprints.rst that Kyle modified?
16:21:45 <mestery> armax: Yes.
16:21:58 <marun> that sounds reasonable
16:22:00 <mestery> I think it makes sense there for this RFE bug template to live, it can provide guidance.
16:22:07 <dougwig> we should file an RFE about making an RFE template.  but, without the template...   segfault.
16:22:10 <armax> as for existing specs, I am leaning to think that we should probably not ask them to map to RFE’s
16:22:15 <armax> it’s work for work’s sake
16:22:22 <mestery> #action marun to add an RFE template into blueprints.rst in devref
16:22:25 <marun> I don't know about a template, I just want expectations to be clear
16:22:33 <mestery> marun: Some sort of guidance
16:22:34 <armax> especially if people file bugs like https://bugs.launchpad.net/neutron/+bug/1453921
16:22:34 <openstack> Launchpad bug 1453921 in neutron "Implement Address Scopes" [Undecided,New]
16:22:35 <armax> carl_baldwin: not picking
16:22:44 <mestery> armax: I get you
16:22:50 <mestery> And in fact, note the last item on our agenda today
16:22:55 <armax> and asking them to ‘redo’ the work isn’t that going to get latency down either
16:22:56 <mestery> Discuss migrating existing proposed specs into RFEs
16:23:06 <armax> mestery: see? I am ahead of you ;)
16:23:14 <mestery> armax: It's just that great minds think alike :)
16:23:25 <mestery> But yeah, lets not make people do work for work's skae
16:23:26 <mestery> *sake
16:23:34 <armax> what do others think?
16:23:37 <mestery> So, existing specs, I'm inclined to leave them as-is and review them there.
16:23:53 <marun> I think the point of migrating to rfe is rejecting things before in-depth review if we don't want to do them.
16:24:02 <armax> anything new => RFE, we need RFE guidelines fast
16:24:14 <armax> and dougwig’s new shiny spec template
16:24:22 <carl_baldwin> I thought that rfes and specs served different purposes.
16:24:23 <dougwig> i agree with armax.  if the process is about cutting down make-work, then adding make-work to conform to the new process, when we have enough info to proceed, is ... inconsistent.
16:24:40 <armax> carl_baldwin: they do
16:24:53 <armax> carl_baldwin: but only when done properly
16:25:19 <armax> carl_baldwin: for stuff that’s already in-flight, I am not sure we’re gaining much
16:25:27 <carl_baldwin> armax: So, use it to provide constructive feedback.
16:25:32 <armax> carl_baldwin: I am
16:25:53 <carl_baldwin> Are we not gaining anything from it?
16:25:54 <armax> carl_baldwin: I am saying let’s not ask exsiting specs to go through the rfe process
16:25:58 <mestery> I think we're all in agreement here. Focus on the end goal.
16:26:08 <armax> carl_baldwin: it’s artificial
16:26:10 <mestery> And try to minimize the churn for folks submitting things
16:26:16 <armax> as your bug report demonstratd
16:26:22 <mestery> But new things, unsbumitted, need to be RFEs first.
16:26:34 <armax> so I’d say let’s be ready first: get guidelines and spec template first
16:26:43 <dougwig> armax: what are you wanting to see in RFE's that carl didn't have?  i saw enough to see what he wanted to build, and form an initial opinion of, 'yes ,that fits', or 'no, not really', or 'jeez'.  what was missing?
16:26:46 <armax> and ask people to follow the new model for new stuff
16:27:04 <dougwig> armax: or i'll wait to see what marun writes up.
16:27:11 <mestery> 3 minutes left
16:27:19 <armax> dougwig: I’d be keep to see what marun’s ideas are
16:27:26 <carl_baldwin> There’s a lot of old stuff.  How long do you want to perpetuate the old model, until they’re all gone?  Or will there be some cutoff?
16:27:33 <mestery> I think we can summarize as this: 1) marun writes up guildeines. 2) review existing things as-is. 3) new things need RFEs (following marun's guidelines)
16:27:34 <armax> all I am trying to say: let’s save process if process can be save
16:27:34 <armax> d
16:27:46 <armax> carl_baldwin can be commended for taking the time for filing bugs etc
16:27:52 <armax> but that can be a pain for some folks
16:27:54 * mestery gives carl_baldwin a gold star
16:28:30 * carl_baldwin doesn’t have any use for gold stars.  Just wants a clear path forward.  He’s not the only one who is going to be confused by this.
16:28:56 * carl_baldwin is also sorry he wasted 3.5 minutes filing https://bugs.launchpad.net/neutron/+bug/1453921 and making you all read it.
16:28:56 <openstack> Launchpad bug 1453921 in neutron "Implement Address Scopes" [Undecided,New]
16:28:58 <armax> carl_baldwin: indeed, there has not been much clarity, that’s what we’re trying to figure out
16:29:30 <carl_baldwin> I personally don’t think that specs for old stuff and rfes for new stuff is clear.
16:29:41 <carl_baldwin> There will be old specs around for years.
16:30:06 <carl_baldwin> And to know what’s in scope for Liberty?  Where do I check?
16:30:09 <mestery> We're out of time
16:30:13 <mestery> carl_baldwin: all godo questions
16:30:15 <mestery> And we need answers
16:30:22 <mestery> And I'm on the hook to provide them
16:30:24 <mestery> Thanks folks!
16:30:26 <mestery> #endmeeting