17:00:05 <jroll> #startmeeting ironic
17:00:06 <openstack> Meeting started Mon Oct 19 17:00:05 2015 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:08 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:10 <e0ne> hi
17:00:11 <openstack> The meeting name has been set to 'ironic'
17:00:13 <jroll> hi all, who's here for the ironic meeting?
17:00:17 <NobodyCam> o/
17:00:28 <krtaylor> o/
17:00:31 <TheJulia> o/
17:00:33 <gabriel> I am <o
17:00:36 <thiagop> o/
17:00:44 <devananda> o/
17:00:47 <dtantsur> o/
17:01:14 <jroll> #topic Announcements
17:01:17 <betherly> o/
17:01:28 <jroll> the summit is next week \o/
17:01:28 <mjturek2> o/
17:01:29 <BadCub> hiya folks
17:01:36 <jroll> design summit schedule is here:
17:01:38 <jroll> #link http://mitakadesignsummit.sched.org/overview/type/ironic
17:01:41 <NobodyCam> oh so much packing to do
17:02:03 <jroll> I've also created a general etherpad for ironic folks during the summit; links to other pads, dinner info, etc. that is here:
17:02:05 <jroll> #link https://etherpad.openstack.org/p/summit-mitaka-ironic
17:02:35 <jroll> the openstack liberty release went out last week and includes ironic 4.2.0
17:02:43 <rloo> o/
17:02:46 <jroll> we will release 4.2.1 with a couple fixes tomorrow
17:02:47 <e0ne> we've got cinder session which will be interesting for ironic too
17:03:01 <jroll> and last but not least, our gate is broken again \o/
17:03:08 <NobodyCam> :(
17:03:12 <jroll> e0ne: got links to those specifically?
17:03:22 <jroll> does anyone else have announcements or reminders?
17:03:30 <e0ne> i'm trying to find
17:03:43 <NobodyCam> jroll: we're just waiting on the revert to land to fix the gate... its already beeen +a'd
17:03:45 <e0ne> i'll add it to the etherpad
17:03:46 <NobodyCam> ?
17:04:04 <jroll> NobodyCam: afaik yes
17:04:09 <jroll> e0ne: ty much
17:04:09 <NobodyCam> :)
17:04:24 <mariojv> \o
17:04:33 <e0ne> https://www.openstack.org/summit/tokyo-2015/schedule/design-summit
17:04:45 <e0ne> https://mitakadesignsummit.sched.org/event/7527f39cf51d1eed383d6d890571d589?iframe=yes&w=&sidebar=yes&bg=no#?iframe=yes&w=i:100;&sidebar=yes&bg=no
17:04:50 <dtantsur> NobodyCam, jroll, neutron fix was merged, waiting for confirmation
17:05:03 <NobodyCam> dtantsur: awesome ++
17:05:03 <dtantsur> aka I've rechecked a couple of things
17:05:10 <e0ne> ooops, ^^ it's not my session
17:05:12 <gabriel> any confirmation on when the 4.3 will be cut?
17:05:14 <jroll> cool, thanks dtantsur
17:05:21 <jroll> gabriel: not at this time, no
17:05:58 <jroll> if there's nothing else...
17:06:03 <jroll> #topic subteam status reports
17:06:10 <jroll> as always, these are located on our whiteboard:
17:06:16 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:06:21 <jroll> I'll give folks a few minutes to review
17:06:30 <gabriel> jroll: might it be this week, or are you more for after the summit?
17:06:44 <rloo> there are 2 critical bugs?
17:06:47 <jroll> gabriel: after summit, thinking sooner than later
17:06:51 <thiagop> gabriel: I think there is an item on the agenda to discuss that
17:07:01 <gabriel> OK
17:07:05 <gabriel> thanks folks.
17:07:10 <jlvillal> Sorry I'm late. Had to reconfigure IRC client to use new ZNC host :(
17:07:20 <thiagop> or not...
17:07:25 <rloo> what does critical mean. ironic doesn't work?
17:07:35 <jroll> rloo: yeah, one is gate break, and one has a patch up
17:07:49 <jroll> the latter is probably 'high' but it's really nasty if it's there
17:08:08 <rloo> jroll: just looked.
17:08:12 <rloo> #link https://bugs.launchpad.net/ironic/+bug/1506657
17:08:12 <openstack> Launchpad bug 1506657 in Ironic "Ironic conductor Hash ring reset needs to be independent of sync_local_state periodic task" [Critical,In progress] - Assigned to Zhenguo Niu (niu-zglinux)
17:08:52 <dtantsur> I would say it's High, but yeah, pretty nasty
17:08:52 <thiagop> I've read 'release' instead of 'meeting'. I think I'm a little anxious... :P
17:10:06 <devananda> jroll: fwiw, I don't consider that one Critical
17:10:18 <jroll> devananda: sure, but it got people writing patches :)
17:10:34 <jroll> I agree
17:10:35 <NobodyCam> :p
17:10:37 <devananda> heh
17:10:42 <jroll> betherly: krotscheck: who is the question in the webclient section directed at?
17:10:48 * rloo changes all bugs to critical
17:10:52 <dtantsur> rloo++
17:10:52 <jroll> devananda: rloo I changed it to high
17:11:07 <rloo> thx jroll
17:11:11 <devananda> rloo: lol :)
17:11:40 <jroll> betherly: I'm fine with a horizon panel short term, having any upstream web UI is better than nothing
17:11:46 <krotscheck> jroll: That's a betherly question
17:11:52 <betherly> jroll: apologies to not be specific on that. generally yourself/cores of ironic/anyone with strong opinions on the matter
17:11:54 <NobodyCam> jroll: ++
17:12:09 <betherly> jroll: ok great thanks
17:12:24 <jroll> does anyone disagree there?
17:12:28 <rloo> betherly: does it mean we/you will have to support both versions later?
17:12:32 * jroll wants to keep moving, lots to talk about today
17:13:57 <jroll> betherly: rloo: maybe take this to the mailing list? :)
17:13:57 <betherly> rloo: the long term plan is to have a replacement that can replace the horizon panel ultimately but until that is sustainable a horizon panel is required. so longer term no, short term yes
17:14:16 <devananda> betherly: krotscheck: any sense how "long term" that is?
17:14:23 <devananda> i mean, are we talking more than one full cycle?
17:14:50 <krotscheck> devananda: Well, horizon has halted all angular development until they can figure out what the "standards" are.
17:15:13 <rloo> so yes, could be more than one cycle.
17:15:22 <devananda> krotscheck: that's ... great
17:15:28 <betherly> indeed devananda
17:15:44 <krotscheck> devananda: My best guess? they'll argue about it for a couple of weeks until their internal PM's start asking about shipping features, and then everything will fizzle out and nothing will come of it.
17:15:56 <devananda> krotscheck: yup
17:16:09 <devananda> krotscheck: end result of that will be they continue on with the current architecture
17:16:12 <jroll> can we take this one to the list?
17:16:33 <jroll> as I suspect it won't be an easy answer, and we're at 10m cap on subteam topics
17:16:36 <rloo> jroll: sure, take it to the list
17:16:50 <jroll> betherly: could you please bring this to the mailing list? thanks in advance! :)
17:16:50 <devananda> jroll: I'd love to get feedback for krotscheck / betherly re: whether we (the ironic community) want them to continue on a horizon panel or an angular panel
17:17:11 <jroll> devananda: I would too, I'd also like to get to the other 5 topics :/
17:17:16 <devananda> *nod*
17:17:24 * jroll timeboxes
17:17:34 * krotscheck has an obvious and easily guessed stance on that.
17:17:36 <jroll> #topic When is the next meeting?
17:17:44 <jroll> rloo: that's you
17:17:51 <rloo> that's my question :)
17:17:53 <jroll> heh
17:18:00 <jroll> so clearly we should cancel next week's meeting
17:18:03 <rloo> i'm thinking we don't want a meeting next monday or the monday after?
17:18:10 <NobodyCam> rloo: ++
17:18:11 <jroll> do folks want to cancel the one after?
17:18:15 <devananda> we usually skip the monday meeting right after summit because travel & recovery
17:18:17 <jroll> I think we should
17:18:24 <jroll> anyone disagree?
17:18:31 * jroll counts down from 30
17:18:35 <jlvillal> lazy consensus says ....
17:18:48 <thiagop> nope
17:18:52 <NobodyCam> I'm good with canceling
17:18:53 * krotscheck is not travelling, so he'll be fresh and ready to go!
17:18:56 <dtantsur> I'm on PTO a week after
17:19:06 <jroll> cool, easy one.
17:19:08 <jroll> #agreed next meeting will be nov 9
17:19:09 <rloo> that decides it. no dtantsur, no meeting!
17:19:14 <dtantsur> ^_^
17:19:17 <NobodyCam> :)
17:19:24 <jroll> #topic Review Lenovo driver spec proposal
17:19:26 <jroll> #link https://review.openstack.org/#/c/208319/
17:19:32 <jroll> huangkai: that's you
17:19:34 <huangkai> Thanks
17:19:39 <jroll> I'm not sure what the question here is
17:19:50 <huangkai> The driver ran for several review
17:20:01 <huangkai> no more coming comments tiil now
17:20:15 <rloo> huangkai: there's a -1. was it addressed?
17:20:23 <jroll> that's a fresh -1 fwiw
17:20:24 <huangkai> Hope everyone can look at it and rate if that's not too hard
17:20:35 <jroll> huangkai: ok, is there something to be discussed in this meeting?
17:20:41 <jroll> meeting topics shouldn't be used to ask for reviews
17:20:47 <huangkai> Not really, just a reminder
17:21:00 <huangkai> Pending for quite a while
17:21:03 <jroll> ok, let's save that for open discussion next time
17:21:04 <jroll> thanks
17:21:08 <jroll> #topic Ironic and cinder integration proposal
17:21:12 <huangkai> ok
17:21:14 <jroll> #link https://review.openstack.org/223217
17:21:16 <jroll> e0ne: you're up
17:21:51 <e0ne> jroll: thanks
17:22:17 <e0ne> I've just want to inform ironic community on our (Cinder) initiative
17:22:41 <e0ne> we're working on attachement w/o nova blueprint
17:22:54 <e0ne> all API is already present in cinder
17:23:04 <jroll> excellent :D
17:23:10 <e0ne> we want to inplement lightweight client for it
17:23:20 <e0ne> and we need your feedback
17:23:55 <e0ne> we'll have some session on summit for it, unfortunatlely, I can't find a link now:(
17:24:26 <jroll> great
17:24:35 <sambetts> e0ne: attachment inside a tenant instance?
17:24:37 <e0ne> #link https://review.openstack.org/#/c/224124/ - here is a spec
17:24:41 <NobodyCam> e0ne: can you add the link to the sessions etherpad when you find it
17:24:57 <NobodyCam> nm
17:24:58 <e0ne> sambetts: attachment to any instance or a baremetal host
17:24:59 <NobodyCam> :)
17:25:03 <jroll> AIUI, tl;dr for this is run something like "cinder volume-attach" from within an instance, it will make the correct API calls and such and attach it
17:25:10 <e0ne> NobodyCam: sure, I'll do it
17:25:34 <thiagop> wow, that's sounds awesome work
17:25:35 <jroll> I'd love some ironic eyes on that, it's an important one. previously the APIs used here were "private" so to speak
17:25:45 <e0ne> jroll: we don't want to do it in a cinderclient
17:25:53 <e0ne> jroll: to not confuse anyone
17:25:55 <thiagop> that sounds like awesome work*
17:26:04 <jroll> e0ne: oh, neat, I was judging by the POC patch :)
17:26:04 <rameshg87> jroll: in the proposed nova spec, however we took help from nova in "attaching" the cinder volume
17:26:05 <e0ne> jroll: it would be a python-brickclient
17:26:17 <e0ne> jroll: it's an old PoC
17:26:20 <sambetts> yeah, that looks really cool :D
17:26:21 <jroll> rameshg87: that spec is boot from volume though, right?
17:26:26 <rameshg87> people even have code for changes with ironic virt driver in review
17:26:28 <e0ne> here is a new one: https://github.com/e0ne/python-brickclient
17:26:30 <rameshg87> jroll: yes
17:26:51 <jroll> rameshg87: yeah, this is just for attaching an existing volume to an existing instance
17:26:52 <rameshg87> fyi, https://review.openstack.org/#/c/215385/
17:26:58 <rameshg87> jroll: oh okay :)
17:27:41 <jroll> does anyone have questions/comments/concerns here?
17:27:56 <devananda> e0ne: sounds awesome for ironic and more generally useful to anyone using cinder volumes, too. thanks!
17:28:06 <e0ne> thanks for feedback!
17:28:25 <e0ne> please, review spec and comment it. any feedback is needed and welcome
17:28:50 <e0ne> you (ironic) will be a primary user of this feature, so we need to colloborate with each other
17:29:03 <jroll> ++
17:29:22 <jroll> alright, I'm gonna move on now, thank you much e0ne :D
17:29:30 <jroll> #topic Brainstorm on mid-cycle locations and possible dates
17:29:32 <e0ne> jroll: thanks
17:29:38 <jroll> jlvillal: this is you, 10 minutes enough time?
17:29:47 <jlvillal> jroll: I would think so.
17:29:54 <jroll> cool
17:29:57 <jroll> gopher it
17:29:59 <jlvillal> Just wondering if people had ideas on locations and dates for the mid-cycle.
17:30:05 <jlvillal> I don't think we need to come to a decision.
17:30:19 <jlvillal> But it would be good to get some ideas to propose.
17:30:28 <NobodyCam> I hear Palm Springs is nice that time of year
17:30:37 <BadCub> lol
17:30:39 <jroll> so, we talked about north america vs europe last week a bit
17:30:41 * NobodyCam *ducks*
17:30:42 <jlvillal> Seems like there was some interest in Europe. And then of course are typical USA location.
17:30:45 <TheJulia> please, somewhere slightly warm
17:30:55 <BadCub> I hear anywhere that I do not have to do the planning is nice that time of year *wg*
17:31:02 <jroll> heh
17:31:15 <jroll> so what do folks think is the best way to do this, some sort of poll?
17:31:20 <jlvillal> Maybe we should think about a good date frame first?
17:31:29 <BadCub> do we want it state-side or ??
17:31:34 <jroll> my open questions are: 1) what dates work for people, and 2) US vs europe vs either
17:31:35 <jlvillal> Or location first?
17:31:45 <devananda> last year, I held the "winter" midcycle in europe -- that got rather poor attendance from US companies. not that past experience is a good predictor of future ...
17:31:55 <rloo> how about asia?
17:32:03 <huangkai> ++
17:32:05 <dtantsur> for me: 1. not overlapping with FOSDEM, 2. not US/UK
17:32:05 <rloo> did anyone ask the Asians?
17:32:09 <devananda> jroll: I'd recommend talking with potential host companies
17:32:36 * jroll hears NobodyCam has plenty of room to host in his house if we do palm springs
17:32:45 <dtantsur> lol
17:32:53 <NobodyCam> lol
17:33:03 <NobodyCam> yep all 948 sq ft of it
17:33:05 <rloo> might be able to host in toronto canada but not going to check unless we are serious :)
17:33:22 * dtantsur has an open Canada visa till spring
17:33:34 <jlvillal> I could see an Asian mid-cycle in addition to a non-Asian one.  I think attendance from outside of Asia would be sparse.
17:33:35 <rloo> it is cold in toronto in jan-feb.
17:33:48 <NobodyCam> I did hear that HP Galway was looking to host.. but I have nothing concrete on that
17:34:06 <devananda> where it is held depends a fair bit on what company wants to sponsor hosting it ...
17:34:06 <TheJulia> NobodyCam: but... that will be cold :(
17:34:15 <BadCub> I *could* talk to my overlord, but cold it would be
17:34:22 <devananda> though those conversations may be better done offline
17:34:23 <NobodyCam> yea
17:34:33 <jroll> right
17:34:43 <jroll> so I'm going to start a couple of polls here:
17:34:45 <jroll> #link https://etherpad.openstack.org/p/ironic-mitaka-midcycle
17:34:52 <NobodyCam> maybe we can get a date range here?
17:34:53 <jroll> and we can go from there after the summit?
17:34:54 <devananda> and last time I took a poll of "who wants it in europe" the response was much mor epositive than the actual travel funding
17:34:55 <jroll> yeah
17:34:58 <rloo> if you guys want CA, i suspect yahoo sunnyvale can host it again :)
17:35:18 <NobodyCam> rloo: that is a great location
17:35:24 <NobodyCam> :)
17:35:26 <BadCub> yeah, taht is an awesome location
17:35:31 <BadCub> s/taht/that
17:35:33 <rloo> NobodyCam: just no free cookies this time!
17:35:39 <NobodyCam> :(
17:35:41 <NobodyCam> lol
17:35:43 <jroll> rloo: as long as there's free coffee :)
17:35:47 <BadCub> *frowns*
17:35:54 <rloo> jroll: that, we have
17:35:58 * BadCub like cookies
17:36:16 <jroll> I'll circulate the poll on the mailing list, talk with some folks about venues, and go from there, sound good?
17:36:18 <krtaylor> I've done these things before at IBM Austin, but Austin mid then Austin for summit = meh
17:36:25 <jlvillal> jroll: Sounds good to me.
17:36:42 <NobodyCam> jroll: ++
17:36:43 <krtaylor> ++
17:36:47 <BadCub> ++
17:36:48 <NobodyCam> dates first then location
17:36:49 <rloo> jroll: also, do we want to colocate midcycle with another project?
17:36:52 <jroll> krtaylor: yeah, agree, that's why I'm not pushing for rackspace venue either
17:36:55 <jroll> rloo: good question :)
17:37:06 <jroll> I'll see what nova is doing and make a note, that may be valuable
17:37:07 <devananda> FYI, Jan 21 is the M2 milestone
17:37:14 <dtantsur> neutron and cinder are candidates
17:37:17 <jroll> ditto for neutron/cinder
17:37:22 <devananda> ++ to colocating
17:37:47 <jlvillal> Nova is: http://doodle.com/poll/88sbzgcv28rww2n3
17:37:50 <devananda> jroll: I've had some discussions with the foundation staff previously about them helping to coordinate / arrange a multi-project midcycle
17:37:58 <NobodyCam> two of ten minutes left
17:38:08 <jroll> devananda: interesting
17:38:29 <jroll> thanks jlvillal
17:38:32 * dtantsur confirms that gate is fixed
17:38:38 <jroll> \o/
17:38:42 <NobodyCam> dtantsur: w00t
17:38:47 <sambetts> \o/
17:38:49 <jlvillal> :D
17:38:52 <jroll> alright, I'll shoot a mail out later today, everyone good with moving on?
17:38:59 <NobodyCam> jroll: +
17:39:01 <jlvillal> Works for me. Thanks.
17:39:13 <jroll> cool, thanks for bringing it up jlvillal
17:39:18 <jlvillal> :)
17:39:43 <jroll> #topic Driver documentation
17:39:46 <jroll> #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/077132.html
17:39:50 * rameshg87 is here half sleepy
17:39:51 <jroll> rameshg87: you have the floor
17:39:53 <jroll> :)
17:39:57 <rameshg87> i don't want to take too much time. if people prefer discussing this outside meeting, i have no objections moving on.
17:40:01 <rameshg87> here are the concerns re-iterated:
17:40:06 <rameshg87> 1) documentation patches take longer time to merge, obviously treated just like other code patches.
17:40:11 <rameshg87> 2) don't want to take time from other reviewers for hardware specific documentation
17:40:14 <rameshg87> 3) it is almost impossible to update the documentation on stable branches
17:40:29 <rameshg87> stable branches information is important to be updated because it is kilo documentation that people ask right now (in beginning of mitaka)
17:40:38 * rameshg87 is done with copy-paste :)
17:40:58 <rameshg87> thoughts anyone ? feel free to reply to mailing list
17:41:07 <jroll> so my biggest question: one concern is docs take "too long" to merge. what timeframe is expected/desired?
17:41:26 <jroll> (this was also asked in the thread)
17:41:28 <rameshg87> probably 1 day or two unless there are pending concerns from reviewers ?
17:41:31 * rloo already replied to mailing list
17:41:38 <rameshg87> I just saw the reply just before the meeting
17:41:39 <rameshg87> sorry
17:41:47 <rloo> rameshg87: no worries :)
17:42:04 <jroll> rameshg87: what's the need for a one day turnaround time?
17:42:17 <rloo> rameshg87: don't the doc patches typically take 1-2 days unless there are pending concerns?
17:42:49 <rameshg87> jroll: no strict requirements, but why keep it open for so long :)
17:42:59 <rloo> rameshg87: it just seems to me that there are usually pending concerns
17:43:00 <jroll> rameshg87: I mean, that goes for all patches then right?
17:43:05 <dtantsur> your proposal still requires at least one core...
17:43:34 <rameshg87> rloo: not necessarily.
17:43:40 <dtantsur> when you have one +2, gaining the 2nd is not that hard. I personally try to prioritize patches with good feedback
17:43:40 <jroll> I'm 100% against the wiki, and mostly against a separate repo. multiple sources of truth for docs makes for a horrible user experience
17:44:06 <jroll> I'd also love to see examples of problematic patches that are driving this desire
17:44:06 <krtaylor> how do other projects handle vendor driver documentation? wouldn't putting it in the wiki instead fix this?
17:44:09 <rameshg87> jroll: rloo: I agree talking about timeframe when it should be merged is a hard thing
17:44:34 <rameshg87> rloo: jroll: another thing is stable branches (which I missed in the email)
17:44:47 <rloo> krtaylor: i'm for wiki so vendors can document what they want and as long as we aren't responsible for their documentation
17:44:49 <rameshg87> dtantsur: yes, thanks, I think most people do that.
17:44:52 <jroll> krtaylor: 1) anyone can edit the wiki, someone could come replace the entire doc with "throw your ilo server away and buy xxx instead"; 2) no quality control, at all; 3) two sources of truth
17:45:01 <rloo> rameshg87: the stable branch thing is a different issue
17:45:06 <jroll> rameshg87: the stable thing should be taken up with stable maintenance folks
17:45:18 <krtaylor> jroll, true, but it doesn't happen in practice
17:45:32 <jroll> krtaylor: 2 and 3 do
17:45:56 <krtaylor> agreed, but then vendors control the docs
17:46:00 <rloo> jroll: wrt 2, that's what they're basically asking for. not much/no quality control except by themselves.
17:46:29 <jroll> rloo: right, I think that's going to make for a poor user experience, in addition to multiple sources of truth
17:46:34 <krtaylor> sources are a good point, but maybe that can be a link pointing to the specific driver docs?
17:46:47 <dtantsur> FWIW I see a lot of useful comments on the vendor docs each time, so I believe moving it to wiki will lower the quality
17:46:50 <rameshg87> jroll: wanted to avoid the two sources of truth as well.
17:47:04 <jroll> dtantsur++
17:47:05 <NobodyCam> jroll: I tend to believe in the points you jaut made :)
17:47:15 <rloo> jroll: we already have multiple sources of documentation. i agree, there shouldn't be multiple sources of Truth, but I think that can be dealt with.
17:47:37 <jroll> I do want to investigate what other projects do, and perhaps the single +2 thing might be fine
17:47:42 <rloo> dtantsur: why do you think moving it to wiki will lower the quality?
17:47:43 <jroll> rloo: O_o where?
17:47:47 <wanyen> jroll, thechallenge that vendor driver owner face was taht the vendor driver features usally are ranked lower priority and hence code will merge late in the release cycle.  It leads very little time for author to write doc and for review process.
17:48:09 <dtantsur> rloo, because "I see a lot of useful comments on the vendor docs each time"
17:48:13 <krtaylor> if one source, then I think it should stay with the same review process
17:48:13 <rloo> jroll: that was a general comment. eg, we have our intree docs, the configs are described via the docs folks.
17:48:22 <devananda> wanyen has a point. how can we fast-track the vendor docs once their driver (changes) have landed?
17:48:31 <jlvillal> Is being less stringent on vendor docs a no-go?  Requiring only one core to approve?
17:48:37 <wanyen> so for Liberty iLO doc is not even merged to the liberty stable branch
17:48:42 <jroll> devananda: wanyen: honestly, we shouldn't be landing code like that without docs.
17:48:54 <jroll> I think that's the real fix to wanyen's problem statement.
17:49:01 <krtaylor> jroll, ++
17:49:01 <dtantsur> jroll has a good answer to this question: require docs with patches
17:49:06 <devananda> jroll: I often see the docs in a separate patch
17:49:14 <dtantsur> it also simplifies life for reviewers, to be honest
17:49:17 <jroll> devananda: yeah, I didn't say we're doing it right today
17:49:27 <devananda> jroll: and I'm fine with that. different folks are better at reviewing docs vs. code some times
17:49:28 <NobodyCam> maybe some type of tag added to the comment message "Doc update for Landed code changes"?
17:49:44 <devananda> NobodyCam: I see that all the time. doesn't seem to help
17:49:57 <NobodyCam> :/
17:49:59 <rloo> jroll: i disagree with having one patch that includes doc + code.
17:50:07 <rloo> jroll: we don't always have one patch that implements a feature.
17:50:13 <jroll> rloo: why? code isn't very usable without docs
17:50:20 <jroll> in that case, put it at the end of the chain
17:50:24 <devananda> jroll: I agree with rloo
17:50:25 <rloo> jroll: and sometimes docs are written/need iterations. most time.
17:50:25 <devananda> jroll: it often is
17:50:27 <rameshg87> jroll: it could be last patch in the chain
17:50:37 <rloo> jroll: preventing code from landing means more rebasing etc.
17:50:43 <jroll> I tend to think if it's in the chain it will get noticed
17:50:48 <devananda> jroll: that is exactly what i've seen driver authors do during the last cycle
17:50:52 <rloo> jroll: at the end of the chain works for me.
17:51:07 <rloo> jroll: but that's basically what they are doing. adding doc patches at the end of the chain.
17:51:20 <NobodyCam> devananda: have you seen success with that approch?
17:51:41 <jroll> rloo: okay, maybe I was mistaken then
17:51:45 <rloo> jroll: honestly, if i see doc patches that are ok, i +2. maybe i am being too picky but if folks want their patches to land quicker, maybe they should spend more time or whatever to get it up to a better level.
17:51:50 <jroll> I still want to see examples of problematic patches
17:52:00 <krtaylor> honestly, in my experience, ironic reviews/lands doc patches quickly compared with other projects
17:52:07 <wanyen> jroll, some features are inter-related and require some re-org to the overall doc so it's going to be hard to do code+patch
17:52:27 <NobodyCam> just fyi: 8 minutes left
17:52:36 <dtantsur> wanyen, maybe we should not demand it really... but if you want it to get in faster, having one patch is often better
17:53:30 <rloo> dtantsur: i disagree. unless the doc changes are well written. otherwise, it'll delay the entire patch.
17:53:41 <gabriel> rloo++
17:53:44 <rloo> dtantsur: and if the doc changes are well written, it doesn't matter if they are in the same patch as code, or in a separate patch.
17:53:50 <dtantsur> 2 delayed patches take more time, than 1 delayed
17:54:05 <dtantsur> you're assuming that doc and code -1's will go sequentially
17:54:16 <sambetts> this only works for inital doc/code lands too, for doc updates/interations we'd still have the issue
17:54:26 <rloo> dtantsur: no. but i've seen in the past where someone has doc + code, and the code is ready to go but the doc isn't.
17:54:42 <rloo> dtantsur: so we iterate over the doc, and the code then has to be rebased in the meantime.
17:55:47 <gabriel> I think verndors have enough incentives to have good documentation. Putting that on one pach just because there should be docs with the respective code does not help having better documentation.
17:56:02 <rameshg87> okay, may be coming back to some resolution
17:56:18 <dtantsur> rloo, " the code is ready to go but the doc isn't" why do you think it happens often? I usually see the opposite..
17:56:22 <jroll> no, but it does help us to ship docs with the code
17:56:33 <rloo> dtantsur: cuz developers can't write very well?
17:56:35 <jroll> I feel like we should take this back to the mailing list
17:56:46 <rloo> jroll: I agree. back to mailing list please.
17:56:47 <gabriel> the more locks for having code in, the harder will be to contribute, the less we are going to have contributions in general
17:57:00 <jroll> code isn't done until there are docs for it.
17:57:14 <dtantsur> I wonder how soon we'll end up with separate patches for unit tests..
17:57:15 <rameshg87> okay, please share your thoughts on mailing list
17:57:19 <jroll> wanyen: rameshg87: can you please provide examples of patches where you have experienced this problem, on the mailing list?
17:57:33 <rameshg87> jroll: ack
17:57:34 <jroll> actually, I'll reply with that question
17:57:40 <jroll> thanks
17:57:47 <jroll> #topic Open Discussion
17:57:50 <jroll> two minutes :P
17:57:57 <rloo> dtantsur: ? do you think we should ask for bits of doc related to each individual patch for a feature?
17:57:57 <jroll> keep talking about docs or anything else
17:58:05 <wanyen> jroll: I am having problem that iLo dirver doc is still under review and not merge to Liberty branch
17:58:11 <BadCub> no results from my searches for a venue for a dinner
17:58:17 <jroll> wanyen: the stable branch thing is a separate topic
17:58:21 <gabriel> jroll: I agree with you on that. I just think that growing the community is more important than having the right docs right there right then.
17:58:27 <huangkai> only one reminder: spare some time for Lenovo driver spec with comments (especially cores), thanks :p
17:58:27 <dtantsur> rloo, that would be awesome, to be honest..
17:58:43 <wanyen> jroll: but it ties to the entire vedor's driver review process
17:58:53 <wanyen> I eant doc review process
17:58:55 <dtantsur> wanyen, most of the folks do not have rights to approve stable/* changes
17:58:59 <rloo> wanyen: wrt the ilo driver doc. i had asked whether we wanted that patch in stable/liberty or whether we were ok having it on master, and no one seemed to think it is a high priority to get into stable/liberty.
17:59:05 <dtantsur> but yeah, it's the whole different topic
17:59:07 <jroll> wanyen: "no doc changes" is a stable branch rule which I do not control
18:00:02 <NobodyCam> really good meeting ... thanks to everyone
18:00:06 <jroll> ^
18:00:08 <rloo> jroll: we could have tried to get that ilo doc into liberty but we don't typically do that for docs cuz we didn't know we have docs for each release.
18:00:08 <jroll> #endmeeting