17:02:06 <NobodyCam> #startmeeting Ironic
17:02:06 <NobodyCam> #chair devananda
17:02:07 <NobodyCam> Welcome everyone to the Ironic meeting.
17:02:07 <openstack> Meeting started Mon Jan 26 17:02:06 2015 UTC and is due to finish in 60 minutes.  The chair is NobodyCam. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:11 <openstack> The meeting name has been set to 'ironic'
17:02:12 <openstack> Current chairs: NobodyCam devananda
17:02:19 <NobodyCam> Of course the agenda can be found at:
17:02:20 <NobodyCam> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:02:55 <NobodyCam> status of course can be found on the white board
17:03:11 <NobodyCam> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:03:40 <devananda> morning, all
17:03:47 <NobodyCam> morning devananda :)
17:03:53 <devananda> I'm sort of here (actually in a car right now, but not driving)
17:03:54 <NobodyCam> you are already a chair
17:03:55 <wanyen> good morning
17:04:23 <NobodyCam> was just about to jump into announcements
17:04:30 <devananda> carry on then :)
17:04:39 <NobodyCam> #topic announcements:
17:05:08 <NobodyCam> Lots of mid cycles and EE comming up
17:05:20 <devananda> only annoucement from me is about the midcycle sprints -- just that we're having them and such
17:05:24 <rloo> what is EE?
17:05:32 * naohirot EE?
17:05:33 <NobodyCam> FF
17:05:47 <Nisha> FF?
17:05:51 <devananda> feature freeze
17:05:52 <dtantsur> :D
17:05:53 <lucasagomes> feature freeze
17:05:54 <lucasagomes> yeah
17:06:07 <NobodyCam> yep
17:06:10 <NobodyCam> :-p
17:06:10 <jroll> lol
17:06:20 <rloo> feature freeze or feature spec freeze?
17:06:21 <wanyen> whenis ff?
17:06:27 <devananda> March 5th is the date when most projects, Ironic included, will stop accepting new features
17:06:28 <NobodyCam> march 5th
17:06:37 <devananda> it's all up on https://wiki.openstack.org/wiki/Kilo_Release_Schedule
17:06:46 <devananda> not really an announcement ...
17:06:55 <NobodyCam> however that does not give the coders a whole lot of time to land the code
17:07:15 <NobodyCam> but well cover that in a bit
17:07:21 <naohirot> NobodyCam: Is march 5th deadline of submitting a new bp?
17:07:30 <NobodyCam> naohirot: yes
17:07:55 <devananda> lets move on to the status check
17:08:09 <NobodyCam> #topic Status updates
17:08:10 <devananda> #topic subteam status reports
17:08:14 <NobodyCam> lol
17:08:32 <naohirot> NobodyCam: I think it's very difficult to go through review from Match 5th, right?
17:08:44 <NobodyCam> naohirot: yes
17:08:56 <NobodyCam> any questions on the status
17:08:56 <naohirot> NobodyCam: Okay
17:09:29 <NobodyCam> (As of Mon, 26 Jan 11:45 UTC) Open: 122 (0). 4 new (0), 32 in progress (+1), 1 critical (+1), 16 high (+2) and 6 incomplete
17:09:58 <NobodyCam> our bug list is growing
17:10:01 <devananda> looks like there is progress on both ilo and irmc drivers, but more reviews are still needed
17:10:28 <dtantsur> I'm not sure all 32 bugs are _actually_ in progress. probably I should start poking people again...
17:10:30 <rloo> wrt oslo. Doesn't seem like we've gotten anything there. It'd be useful to know 1. what oslo changes could be done, even if they aren't done yet.
17:10:45 <devananda> I'd like to also remind folks that, when reviewing code for third-party drivers, we need to trust the authors / maintainers of those drivers
17:10:53 <wanyen> yes. pls continue to review ilo specs.
17:10:55 <NobodyCam> did we ever got to have our bug scrub?
17:11:05 <devananda> I havent seen any updates from GheRivero on the oslo stuff in a while
17:11:12 <devananda> and afaik he is not coming to our sprint next week
17:11:29 <NobodyCam> do we know if he'll make the SF meetup?
17:11:31 <devananda> NobodyCam: yah. several folks worked on bugs for a day (I had to miss it, unfortunatey)
17:11:35 <devananda> NobodyCam: he will not
17:11:39 <NobodyCam> :(
17:11:49 <dtantsur> NobodyCam, we did :)
17:11:58 <NobodyCam> great I also missed it :(
17:12:06 <dtantsur> it's worth repeating from time to time anyway :)
17:12:06 <jroll> devananda: "we need to trust the authors / maintainers of those drivers" what do you mean by this?
17:12:42 <NobodyCam> devananda: do you want to save that for the review section
17:12:58 <devananda> i spoke with dhellmann last week briefly about the oslo.objects refactoring. it was/is bocked on something else in oslo, and at this point, doesn't seem like a priority for this cycle for anyone
17:13:18 <lucasagomes> :/
17:13:21 <devananda> jroll: let's come back to that in the next section ...
17:13:37 <jroll> ok
17:13:53 <NobodyCam> anything else on staus updates?
17:14:14 <devananda> not from me
17:14:28 <NobodyCam> if not I'm going to shuffel the oder listed on the agenda, for time.
17:14:35 <devananda> NobodyCam: do it :)
17:14:41 <NobodyCam> #topic IPMI retry timeout value
17:14:53 <NobodyCam> trown: that you
17:14:56 <trown> yep
17:14:58 <NobodyCam> :)
17:15:11 <trown> so, I picked up this bug as it was marked "low hanging fruit"
17:15:36 <trown> the change is pretty trivial, however, I need some help with determining what the "best" value is
17:15:36 <NobodyCam> #link https://review.openstack.org/#/c/131296/
17:15:55 * jroll is checking...
17:16:01 <trown> is there operator opinion/consensus on this?
17:16:12 <lucasagomes> yeah it would be good to get an operator opnion on that
17:16:24 <devananda> I'm not sure that a single default can cover all hardware
17:16:37 <devananda> as different hardware may have problems at different retry timings
17:16:50 <devananda> the current default is overly conservative IMO, though
17:17:06 <NobodyCam> could we half it to 30?
17:17:12 <devananda> 10?
17:17:24 <lucasagomes> right, also maybe as part of that bug we could put a NOTE at the deployer's doc
17:17:29 <jroll> we're using 60 at rackspace, it's been fine, though we're also vigilant at tracking down bad BMCs and putting them in maintenance mode
17:17:32 <devananda> I'd like some input from the tripleo rack as well, as they were the folks who originally filed / fixed that issue
17:17:38 <lucasagomes> to call attention to that option
17:17:43 <rloo> how would one go about getting operator opinion? wouldn't that be a good first step?
17:17:44 <trown> "Too low -> we can inadvertantly knock over some (fragile) BMCs and require a hard-reset of the BMC (not the node) to unbrick it. " <--- how low does this happen at?
17:17:45 <jroll> we also haven't played with different values
17:18:55 <devananda> trown: that totally depends on the hardware, unfortunately
17:19:08 <devananda> trown: I've definitely seen reports of that happening around 5 seconds
17:19:28 <trown> ah ok
17:19:36 <devananda> with older HP hardware
17:19:48 <trown> so 60 is really conservative then
17:19:53 <devananda> and I believe victor_lowther had pointed out his experiences on some hardware with that, a while back as well
17:20:04 <rloo> https://review.openstack.org/#/c/82668/ changed it from 10 to 60.
17:20:06 <jroll> fwiw, I'd rather have my power sync loop be slow than brick a bmc
17:20:19 <devananda> jroll: exactly
17:20:24 <NobodyCam> yes
17:20:27 <lucasagomes> right
17:20:35 <jroll> watch for slow bmcs and maintenance them as needed
17:21:02 <NobodyCam> so how about 30 and if that causes not issues than half it again to 15
17:21:20 <lucasagomes> so should we mark the bug as invalid? Or would be updating the deployer docs to call more attention to that option a valid "fix"
17:21:31 <rloo> this is a default value, so every time we change it, we could be breaking backwards compat.
17:21:46 <devananda> https://review.openstack.org/#/c/96558/ added the minimum time interval
17:21:57 <trown> I like the "update the deployer docs" approach
17:22:09 <trown> conservative defaults are not a bad thing
17:22:12 <devananda> in resposne to https://bugs.launchpad.net/ironic/+bug/1320513 filed by tripleo team
17:22:35 <jroll> I also like the documentation fix, maybe add more notes on it to the actual config optino as well
17:22:47 <NobodyCam> jroll: ++
17:22:49 <lucasagomes> yeah, since there's no best default
17:22:54 <jroll> right
17:22:58 <devananda> so 10 and doc changes?
17:23:01 <devananda> that would work for me
17:23:01 <jroll> no
17:23:07 <jroll> I think leave it at 60
17:23:10 <lucasagomes> I would say leave as-is
17:23:13 <devananda> ah, ok
17:23:15 <trown> ya ++
17:23:15 <lucasagomes> to be conservative, but update the docs
17:23:20 <devananda> sounds good
17:23:25 <NobodyCam> yea!
17:23:28 <jroll> fwiw, when we deployed initial production
17:23:30 <rloo> ++
17:23:32 <lucasagomes> put a NOTE or even a WARNING there
17:23:32 <devananda> who's going to do the doc patch?
17:23:40 <jroll> we didn't notice slow BMCs slowing things down until around 5-600 nodes
17:23:47 <trown> devananda: I can do the doc patch
17:23:48 <lucasagomes> trown, ? since he's the one assigned to the bug?
17:23:54 <lucasagomes> if he wants
17:23:55 <lucasagomes> ah ok
17:24:11 <devananda> #agreed keep the current default, but improve documentation
17:24:27 <NobodyCam> :)
17:24:28 <devananda> #action trown to add or improve documentation around ipmi retry timing options
17:24:57 <NobodyCam> in code (conf file) and wiki right?
17:25:31 <NobodyCam> any thing else on timeout
17:25:34 <trown> NobodyCam: that seems good
17:25:43 <NobodyCam> ok then
17:25:49 <NobodyCam> #topic Prioritize Spec and code reviews
17:25:53 <NobodyCam> oh thats me
17:26:28 <NobodyCam> Ok we are approching FF and still have a bunch of specs and code out that needs reviewing
17:26:49 <JayF> .
17:27:02 <NobodyCam> I've seen a trend of our reviews esp. on spec to be getting more and more nit picky
17:27:16 <wanyen> specs need to be approved by FF?
17:27:23 * devananda has seen this too
17:27:36 <devananda> and we already have many specs approved and blocked on other work
17:27:37 <NobodyCam> I think we all have trust in each other to be able to do the work we say we will
17:28:00 <devananda> and code reviews are taking an increasing amount of time, even for essential things (ie, patches that block feature work)
17:28:14 <JayF> Overall review bandwidth seems to be down over the last month
17:28:16 <NobodyCam> I am suggesting that we lossen the review criteria
17:28:18 <JayF> if you look at statistics
17:28:18 <devananda> NobodyCam: that's where my comment earlier about trusting driver authors comes in
17:28:25 <lucasagomes> JayF, yeah noticed that too
17:28:26 <jroll> do you notice this more with cores or non-cores or both?
17:28:27 <devananda> JayF: indeed it is
17:28:47 <devananda> jroll: both. but cores should be setting the better example
17:28:50 <rloo> loosen review criteria for both specs and code?
17:28:51 <NobodyCam> both, even I am guilty of this
17:29:05 <jroll> I'm sure I am too
17:29:13 <devananda> a few suggestions for us all (myself, too)
17:29:13 <NobodyCam> rloo: mainly for specs
17:29:29 <NobodyCam> but code needs to land faster
17:29:39 <devananda> - for code nits, just add a follow on patch yuorself,a nd +2/+A it if you would other wise +A the original patch
17:30:14 <devananda> like, if I spot a spelling ereror in a comment string, I will start +2/+A'ing my own patch, just so the original patch author doesn't have to do anothe rrev
17:30:20 <devananda> (and we dont have to wait for it)
17:30:43 <NobodyCam> I like that Idea
17:30:51 <wanyen> ++
17:30:54 <devananda> - for driver changes, if its from the driver maintainer, and you don't know that hardware, please give them teh benefit of the doubt
17:31:26 <wanyen> :)
17:31:53 <NobodyCam> as a little background I started the thread because I was reviewing a spec for a vendor passthru method
17:32:53 <dtantsur> NobodyCam, as you know I don't agree on _this_ particular one
17:32:54 <NobodyCam> If I recall the Vendor passthru is a area where vendors can add functions that they can perform with their hardware that the generic drivers can not do
17:33:13 <NobodyCam> dtantsur: thats why I wanted to chat about
17:33:14 <NobodyCam> it
17:33:39 <NobodyCam> all code has to go thru code review
17:33:56 <dtantsur> vendor passthru is an API, however we call it. that's why I think we should not be too easy about it...
17:33:59 <NobodyCam> so I would expect any glaring coding errors would be cought there
17:34:04 * lucasagomes I think I reviewed that spec... looks again
17:34:38 <dtantsur> I though the biggest point of the spec process was to agree on important things like API
17:34:48 <NobodyCam> when we came up with teh VP aPI it was to allow vendors to be able to dothere own thing
17:34:48 * devananda goes afk to walk into the nova meeting
17:34:53 <dtantsur> because once published, they're hard to change
17:35:15 <jroll> I mean, people weren't -1'ing the spec because there might be coding errors...
17:35:24 <jroll> #link https://review.openstack.org/#/c/149383/
17:35:26 <jroll> lucasagomes: ^
17:35:49 <lucasagomes> yeah... looking again, didn't recheck the replied
17:35:51 <lucasagomes> replies*
17:35:54 <NobodyCam> I recall us talking about reviewing the VP methods and if we found several drivers doing the same thing then we would look at moving that code to a standard api for all the drivers
17:36:06 <dtantsur> if we make exception about vendor passthru's, namely 1. allow to break backward compatibilty without warning, 2. allow it to screw everything including breaking hardware, we have to communicate it very clearly.
17:36:39 <jroll> dtantsur: nothing about that spec does either of those
17:36:43 <dtantsur> most concerning point for me about this spec is that it allows deploy to happen in the middle of bios update
17:36:51 <jroll> oh?
17:36:54 <dtantsur> jroll, how does it prevent ^^^
17:36:58 <NobodyCam> dtantsur: my thought behind this was that it is in the vendors best intress to ensure their code works
17:36:59 <jroll> I mean
17:37:02 <jroll> it could lock the node
17:37:04 <jroll> pretty simple
17:37:15 <jroll> I would assume it would lock the node while performing the firmware update
17:37:34 <NobodyCam> dtantsur: would that have been cought in a review of the code?
17:38:02 <dtantsur> maybe it's only me, but it's hard for me to watch both high-level and low-level things while looking at the code
17:38:09 <rloo> NobodyCam: not necessarily (caught in code review)
17:38:21 <dtantsur> NobodyCam, but again, why we have spec process at all? everything can be caught during code review :D
17:38:37 <dtantsur> I think spec is a chance to think about such corner cases
17:38:46 <lucasagomes> right, replies on that spec looks good to me. But idk... I don't think the reviews were nitpicky in that case
17:38:52 <lucasagomes> they were more suggestions and ideas
17:39:09 <jroll> sure, but the comments on that spec is "let's just do real zapping instead". when zapping has been bumped to L.
17:39:23 * dtantsur didn't know zapping was bumped
17:39:25 <NobodyCam> my goal is to imporve our volisity on reviews both code and spec
17:39:26 <jroll> so "just make zapping steps" doesn't solve the problem
17:39:42 <jroll> well, hardware capability stuff was bumped, which zapping kind of depends on AIUI
17:39:52 <lucasagomes> + I understand VP doens't need to be super "consistent" but, we depend on VP methods as today to deploy any machine with PXE for example
17:40:26 <dtantsur> jroll, I guess it should be an explicit decision, I didn't think we can't make zapping states _at all_ without capabilities
17:40:30 <JoshNang> yeah i think zapping will have to be bumped
17:40:36 <dtantsur> like in this case: we could call it zapping
17:40:53 <NobodyCam> my understanding is zapping did get bumped
17:41:02 <dtantsur> but I don't insist, I really didn't realize that it's pretty much decided, sorry for that folks :)
17:41:13 <rloo> when was it mentioned to the group that zapping got bumped?
17:41:31 <NobodyCam> on the nova side I think
17:41:33 <jroll> dtantsur: sure, we should talk about it, idk, maybe it isn't officially bumped
17:41:38 * devananda is back
17:41:52 <dtantsur> devananda, was zapping _officially_ bumped to L?
17:41:54 <lucasagomes> dtantsur, it's all good. I mean, we should say it if we think it's important... and you can have ur -1 there even if the spec is merged
17:41:56 <JoshNang> rloo: i don't think it's officially bumped yet.
17:42:15 <wanyen> I didn'tknow zapping is bumped.
17:42:22 * lucasagomes neither do I
17:42:23 <JoshNang> i could write and land most of the code, but doing zapping you can't schedule against seems...less useful
17:42:28 <wanyen> we need raid config
17:43:23 <dtantsur> JoshNang, the spec in question is a use case, raid stuff as well
17:43:36 <wanyen> scheduling does not depends on capability spec
17:43:42 <rloo> i admit that I don't always know when something is a nit or not. I like it when dtantsur and lucasagomes comment, so I would hate to dissuade them from doing so (or others). maybe gentle reminders or something? eg ping me if you disagree?
17:43:44 <devananda> dtantsur: I do not recall that zapping was bumped
17:44:10 <jroll> so look at it this way: do we actually think we can land a zapping spec and implementation, in time that victor_lowther could build the drac raid stuff on top?
17:44:17 <NobodyCam> some how I thought it was
17:44:26 <devananda> jroll: nope
17:44:30 <jroll> right.
17:44:35 <JoshNang> and zapping requires tne cleaning implementation
17:44:39 <lucasagomes> rloo, yeah, well I'm always in the channel and ppl can ping me to discuss whatever
17:44:39 <jroll> the VP api is for vendors to build things that aren't generic yet
17:44:40 <devananda> so without going into all the detail about specific state transitions
17:44:44 <jroll> zapping/raid is not generic
17:44:46 <devananda> which I'm the only one working on actually implementing
17:44:46 <jroll> yet
17:44:48 <rloo> we seem to be digressing...
17:44:57 <devananda> and which took a lot of time to get anyone to review
17:44:58 <jroll> rloo++
17:45:00 <devananda> and yes i'm frustrated about that
17:45:04 <devananda> we have totally gone off topic
17:45:16 <devananda> which was -- how do we improve OVERALL velocity
17:45:17 <NobodyCam> yep
17:45:19 <devananda> by not nit picking
17:45:30 <devananda> and then dtantsur brought up why we have specs at all
17:45:46 <devananda> which I'd like to decompose a bit
17:46:01 <rloo> i think the example (spec) given about 'nit picking' wasn't considered nit picking by others
17:46:03 <NobodyCam> 15 minuts btw
17:46:06 <devananda> dtantsur: do you feel that specs provide you, as a code reviewer, with any meaningful context?
17:46:45 <naohirot> I'm just wondering, in order to accelerate review process, can't we set a deadline for each spec review?
17:46:47 <dtantsur> devananda, I feel like it allows me to become acknowledged with high-level idea, before diving into (possibly a lot of) code
17:46:51 <devananda> rloo: NobodyCam also brought up the vendor_passthru question, which I agree, doesn't sound like a nit. but it IS related to how deeply we scrutinize drivers
17:46:52 <dtantsur> devananda, so yes
17:46:55 * Shrews forgot about the meeting... apologizes
17:47:18 <rloo> so how deeply do we scrutinize drivers?
17:47:33 <jroll> I've heard this often recently: "as a code reviewer, does this spec give you enough information to tell you if the implementation is done" and I don't think that should be the intention of specs because "tell you if it's done" means different things to different people
17:47:49 <dtantsur> I was assuming that API (and other use visible) changes are the most important to agree and be clear on
17:48:23 <devananda> dtantsur: cool. I'm glad. that's what I beleive specs should do (help to flesh out a high-level idea enough to agree on the direction)
17:48:40 <devananda> also, yes, changes to API (both external and internal) need more detailed review than other things
17:48:47 <devananda> when they are part of the core APIs
17:48:56 <devananda> vendor_passthru is vendor specific
17:49:07 <devananda> it's supposed to be an area for vendors to do new things
17:50:14 <NobodyCam> I have been thinking along the lines of "if the change impacts a common area or more then one driver."
17:50:14 <devananda> let me ask: what's teh impact to the project if a driver decides to break their vendor_passthru's backwards compatibility?
17:50:46 <lucasagomes> depend on the driver
17:50:51 <devananda> it's clearly a higher impact if that is IPA or the pxe/iscsi driver ... beacuse these are common drivers we all rely on
17:50:52 <lucasagomes> for the continue_deploy VP of the PXE driver
17:50:58 <lucasagomes> it can be problematic
17:50:58 <jroll> I guess it depends on the passthru api
17:51:02 <dtantsur> devananda, people coming to a channel asking us to fix it :)
17:51:07 <devananda> but iLO? DRAC? iRMC? -- if they break an experimental feature in vendor_passthru
17:51:11 <rloo> devananda: let me ask you, are we OK if a driver breaks their vendor_pasthru's backwards compatibility? cuz I personally don't care if it is a third-party driver, but... what would our users think?
17:51:33 <jroll> devananda: didn't nova-bm teach us that nothing is experimental? :)
17:51:48 <devananda> jroll: indeed. except when it is.
17:51:55 <dtantsur> I remember us arguing about backward compatibility of an ILO driver_info option between commits in the middle of cycle
17:52:08 <dtantsur> i.e. ilo_username vs ipmi_username vs username
17:52:22 <dtantsur> and we decided that we don't wanna break even this compatibility
17:52:24 <devananda> dtantsur: that's not venor passthru
17:52:38 <devananda> that is the basic interface for node.driver_info
17:52:43 <devananda> changing that would break the whole driver
17:52:57 <devananda> not just vendor_passthru/method=my_experimental_feature
17:53:03 <dtantsur> that's what people has much less chances to be broken by. now we're talking about API's
17:53:13 <NobodyCam> rloo: most of the vendor bmc's can also fall back to generic ipmi if the vendor driver was not working
17:53:13 <lucasagomes> yeah it's complicated... I think that we can be more soft on vendor passthru. But again, I'm looking at the comments on that spec, and I think that suggestions are valid. That's spec is all about adding VP methods
17:53:14 <rloo> devananda: so you are saying that vendor_passthru == vendor specific and as such, 'experimental'
17:53:16 <dtantsur> sorry, I don't recall us having notion of 'experimental' API
17:53:27 <lucasagomes> if we can't suggest, if it's totally up to the vendor then we don't need a spec
17:53:29 <lucasagomes> as NobodyCam commented
17:53:48 <devananda> perhaps we should have a separate /experimental section?
17:53:56 <dtantsur> e.g. in discoverd I have API's that are only enabled by a configuration option, saying that it's experimental
17:54:12 <lucasagomes> devananda, or just have the code itself adding methods to the VP methods
17:54:16 <dtantsur> devananda, ++ for anything clearly telling people: this can eat your laundry :D
17:54:18 <NobodyCam> devananda: or verdor contrib area
17:54:29 <NobodyCam> ++
17:54:31 <lucasagomes> if it's not touching any core parts, it's not impacting on DB or core API etc
17:54:36 <devananda> vendor_passthru is vendor contributed ...
17:54:46 <devananda> lucasagomes: that's exactly what vendor passthru should be doing ...
17:54:50 <lucasagomes> yeah
17:54:51 <NobodyCam> true
17:54:59 <lucasagomes> so maybe not requiring specs for vendor passthru bits?
17:55:03 <lucasagomes> just send code
17:55:05 <NobodyCam> ++
17:55:12 <NobodyCam> with a good commit message
17:55:24 <lucasagomes> in the code we can decide whether things simple like a return code for a vendor does make sense or not
17:55:37 <lucasagomes> and suggest something, but that's imlementation so it's even easier to do when reviewing the code
17:55:39 <lucasagomes> not the spec
17:55:40 <NobodyCam> how does that sound ^^^^
17:55:47 <NobodyCam> vote?
17:55:55 * devananda feels like this still strayed far afield from the original topic of review velocity
17:56:04 <naohirot> how did we prioritize the spec review?
17:56:25 <naohirot> why can't we set a deadline for each review?
17:56:50 <NobodyCam> naohirot: our reviewers are also very busy
17:56:51 <jroll> devananda: it seems we've managed to eliminate one source of slowness, at least
17:56:57 <rloo> review velocity == both reviewers (core or not) and committer doing their part. (apart from nits if we can clarify what nits are).
17:57:05 <dtantsur> NobodyCam, lucasagomes, -0 until we have way to distinguish experimental (might break and be broken) and normal ones...
17:57:28 <jroll> naohirot: what happens if deadlines are not met? pay cuts? :P
17:57:32 * rloo gets tired of asking why a comment in a previous revision wasn't addressed.
17:57:39 <dtantsur> rloo, ++
17:57:41 <devananda> rloo: me too
17:57:45 <jroll> yep
17:57:46 <NobodyCam> dtantsur: I like the invers of that.. tag drivers as production ready
17:58:00 <devananda> NobodyCam: who decides what's production ready?
17:58:07 <devananda> NobodyCam: the TC is getting out of that business ...
17:58:09 <naohirot> In order to proceed next step, a little by little, we need a little bit fine, small granularity schedule, I think.
17:58:13 <NobodyCam> ahh
17:58:30 <NobodyCam> two minutes
17:58:39 <devananda> #topic open discussion
17:58:40 <rloo> maybe we could get feedback from people submitting patches, if they have suggestions to speed things up.
17:59:20 <devananda> rloo: or perhaps rather than gathering more feedback, we could just all do code reviews, based on the project's priorities
17:59:26 <NobodyCam> anyting for OD?
17:59:46 <devananda> and if the priorities aren't clear, then that's my fault, and I'll put more effort into communicating them
17:59:51 * rloo been trying but /me wonders how to improve patches etc so fewer iterations
17:59:55 <NobodyCam> continue in channel?
18:00:13 <jroll> devananda: that TODO.rst helps, but I'd love if we got together and decided priorities for the rest of this cycle
18:00:15 <lucasagomes> yeah channel is it
18:00:17 <devananda> thanks, all. see (some of) you next week in Grenoble
18:00:18 <jroll> yeah
18:00:21 * jroll reposts there
18:00:22 <NobodyCam> htank you all
18:00:24 <lucasagomes> jroll, +1!
18:00:24 <naohirot> jroll: If review didn't ended by the deadline, then we have to go to the next step.
18:00:25 <devananda> #endmeeting