16:00:01 <thingee> #startmeeting Cinder
16:00:02 <openstack> Meeting started Wed Oct 29 16:00:01 2014 UTC and is due to finish in 60 minutes.  The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:05 <openstack> The meeting name has been set to 'cinder'
16:00:09 <smcginnis> Hi
16:00:15 <thingee> Hello all
16:00:20 <tbarron> hi
16:00:22 <patrickeast> hi
16:00:23 <eharney> hi
16:00:26 <thingee> Agenda items for today:
16:00:28 <thingee> #link https://wiki.openstack.org/wiki/CinderMeetings
16:00:29 <bswartz> .o/
16:00:47 <xyang1> hi
16:00:54 <thingee> #topic Discuss the brick spec/effort for Kilo
16:00:58 <thingee> #link https://review.openstack.org/#/c/129069/
16:01:01 <thingee> hemna: you're up
16:01:01 <avishay> hi
16:01:06 <jungleboyj> o/
16:01:10 <hemna> mornin
16:01:18 <hemna> ok so Brick
16:01:32 <thangp> o/
16:01:34 <hemna> I liked eharney's suggestion of making brick a subproject of Cinder
16:01:37 <Swanson> hi
16:01:38 <hemna> a la python-cinderclient
16:01:46 <kmartin> hello
16:01:51 <hemna> so cinder PTL is the PTL of brick and cinder core's are cores of brick.
16:02:16 * DuncanT- appears from the coffee fumes
16:02:25 <ameade> +1
16:02:27 <smcginnis> Makes sense to me.
16:02:32 <DuncanT-> +1
16:02:33 <thingee> hemna: +1
16:02:34 <jgriffith> hemna: thingee so not to throw a major wrench in the works....
16:02:38 <xyang1> +1
16:02:42 <winston-d> o/
16:02:48 <jgriffith> but I still am not sure brick is going the right direction here
16:03:12 <DuncanT-> Can you outline the direction you think it should go in, John?
16:03:19 <thingee> jgriffith: I think the general idea of accepting brick if it goes in a direction we can agree on the summit, hemna's proposal is fine
16:03:22 <asselin> hi
16:03:30 <jgriffith> DuncanT-: thingee hemna https://wiki.openstack.org/wiki/CinderBrick
16:03:31 <jgriffith> Ok
16:03:35 <jgriffith> fair enough
16:03:39 <jgriffith> ignore me :)
16:04:03 <hemna> I still want to see brick exist as a lib.  simply to help remove the dupe code between Cinder and Nova.
16:04:14 <jgriffith> hemna: that's easy to say :)
16:04:18 <thingee> jgriffith: but it would be helpful for you to raise these points to hemna outside of the meeting so that he can have things in a better state for his summit session
16:04:23 <jgriffith> hemna: my point is it's weird
16:04:38 <jgriffith> hemna: thingee it's weird to have iscsi stuff and LVM stuff in a lib
16:04:43 <hemna> why is removing duplicate code 'weird' ?
16:04:46 <jgriffith> and not touch anything we hoped to accomplish
16:04:58 <hemna> but that's just part of the lib.
16:05:09 <hemna> the other side still needs effort and work from folks.
16:05:11 <jgriffith> hemna: IMHO eliminating dup target/initiator code can be done another way
16:05:16 <jgriffith> hemna: as can duplicate LVM code
16:05:21 <hemna> just like everything else we do in OpenStack....baby steps
16:05:34 <jgriffith> but I keep pointing out that the LVM code as is today likely won't be consumable by anybody else
16:05:39 <jgriffith> Ok
16:05:46 <jgriffith> I'll shut up :)
16:05:49 <hemna> so I say then, help contribute the local volume management into brick and we're good.
16:06:42 <hemna> I don't know that side of the code quite as well as you do, so I'm hoping to get help from you and the rest of Cinder to drive that piece of it.
16:06:43 <jgriffith> hemna: but then you've got 4 disjointed things under that umbrella
16:06:49 * jgriffith NOW shuts up
16:06:50 <jgriffith> :)
16:06:52 <hemna> which is why I think it's good to be owned as a subproject of Cinder.
16:07:34 <jgriffith> hemna: yeah, I'm down with that, but that's sort of not the point I'm trying to make
16:07:49 <jgriffith> anyway
16:07:52 <hemna> ok I'm still trying to understand your point I guess.
16:07:53 <smcginnis> jgriffith: Would it be better to have multiple specific libs?
16:07:57 <hemna> I'm completely missing it.
16:07:58 <jgriffith> I'm the only one with anything to say so let's talk next week :)
16:08:19 <jgriffith> smcginnis: probably... and probably consider oslo for *some* of it
16:08:26 <thingee> jgriffith: I find the whole brick thing frustrating. Mainly because I feel like anytime work that is not done by you, you're unhappy with the direction. To be fair I know you're unhappy with the current state of brick, but I think it would be valuable for you to help hemna.
16:08:36 <jgriffith> thingee: wow!
16:08:39 <jgriffith> thingee: ok
16:08:42 <hemna> I'd like to see this move forward, so we don't have yet another release where nothing happens.
16:08:54 <jgriffith> as I said, feel free to move forward
16:09:00 <jgriffith> I'll be quiet
16:09:08 <thingee> jgriffith: that does us no good.
16:09:38 <rushiagr> hi! Sorry, late
16:09:40 <thingee> jgriffith: what are your objections with giving guidance?
16:09:56 <jgriffith> thingee: I thnk you and I should talk offline
16:10:14 <hemna> ?
16:10:22 <jgriffith> and move along
16:10:50 <thingee> #agreed if brick's direction is accepted, it'll be a subproject under cinder like cinderclient
16:10:57 <jgriffith> and not regarding brick itself, but your statement just for the record
16:11:13 <jgriffith> +1
16:11:26 <thingee> #topic Discuss the volume type extra specs cinder-spec
16:11:28 <e0ne> thingee: +1
16:11:38 <hemna> ok so the extra specs thing
16:11:39 <jungleboyj> +1
16:11:39 <thingee> #link https://review.openstack.org/#/c/127646/
16:11:49 <hemna> I think it might be worth talking about this in a session ?
16:12:07 <hemna> my coworker and I have been hashing on this one for a while
16:12:21 <hemna> she's done a great job on the specs and has some screen shots of what we'd like to see
16:12:47 <hemna> I can show them in Paris if anyone is interested
16:12:54 <jgriffith> thingee: am I incorrect that we shouldn't roll up 3 specs in one proposal?
16:12:58 <winston-d> hemna: I am.
16:13:00 <jgriffith> thingee: if so I can remove my -2
16:13:19 <DuncanT-> jgriffith: I agree that splitting them makes things easier to comment on and move forward in pieces
16:13:21 <hemna> I know winston-d has had some questions about the implementation, and I'd like to get some clarity on it
16:13:26 <jgriffith> oh wait... already done... sort of
16:13:35 <hemna> jgriffith, I believe she split the specs up into 3 specs already
16:13:52 <DuncanT-> hemna: Any chance of getting them online or emailed before hand? Easier to think ahead than see subtle issues while thinging on your feet
16:14:02 <jgriffith> hemna: yeah, that's what I just noticed :)
16:14:04 <jgriffith> hemna: thanks!
16:14:10 <hemna> DuncanT-, sure.   I have a .ppt that she made that I can put somewhere
16:14:13 <winston-d> hemna: you will be work on cinder part and Julie focuses on Horizon I guess?
16:14:18 <hemna> or just put the screens on a site for all to see.
16:14:22 <DuncanT-> hemna: Cheers
16:14:35 <hemna> winston-d, I'll probably end up doing a bunch of the Cinder work
16:14:48 <thingee> jgriffith: yeah seems fine to me.
16:14:48 <hemna> jgriffith, np
16:15:09 <hemna> ok, so I'll get those screenshots up before I bail for Paris
16:15:19 <winston-d> hemna: +1,thx
16:15:50 <thingee> #topic Discuss the differential backup patch
16:16:00 <thingee> #link https://review.openstack.org/#/c/110068/
16:16:04 <thingee> Murali: you're up
16:16:07 <Murali> yes
16:16:16 <Murali> Thanks Mike.
16:16:31 <Murali> I heard couple of concerns on the specs and implementation.
16:16:48 <Murali> if the design is expandable later for incremental
16:17:01 <Murali> and the driver interface to support differential
16:17:10 <Murali> I would like to know any other concerns.
16:17:22 <DuncanT-> Can you quickly define the two terms please? 'deferential .v. incremental'
16:17:36 <thingee> interview question
16:17:46 <Murali> Incremental is the delta from last backup
16:17:53 <Murali> differential is delta from last full backup.
16:18:02 <hemna> thingee, :)
16:18:17 <Murali> right now the implementation is for differential.
16:18:21 <DuncanT-> Thanks
16:19:51 <Murali> Right now the implementation uses local_path to get host path to the snapshot.
16:19:58 <smcginnis> Murali: Could you summarize the concerns with the spec or what is needed to proceed?
16:19:59 <thingee> Murali: I have not looked at the patch myself, so I will have to look to hemna DuncanT-  eharney and xyang1 for thoughts
16:20:09 <Murali> that is good for LVM, but does not work for other backups.
16:20:24 <DuncanT-> local_path doesn't work for any of the iSCSI drivers
16:20:27 <eharney> i haven't looked at this one in a bit but i'm certainly interested in reviewing it further
16:20:30 <Murali> This is something I need to look into. Duncan/Xing has some suggestions.
16:21:02 <Murali> create a hidden volume from a  snapshot and read the volume to calculate delta.
16:21:05 <DuncanT-> It also ties teh backup service to the cinder-volume service, which I'm trying to fix (fix is only needed for the LVM code, the rest already work AFAICT)
16:21:07 <xyang1> as long as Murali can explain the current design doesn't prevent it to be extended to support incremental, I'm fine with it
16:21:29 <Murali> xing1: I will do that.
16:21:36 <xyang1> Duncan't concern about local_path needs to be addressed as well
16:22:03 <Murali> ok.
16:22:09 <DuncanT-> It looks to me that the data structures are all good for incremental - the management code will need to be smarter for incremental, particularly delete, but that is only code and we have smart people
16:22:37 <thingee> #agreed differential backups needs to have a path to extend to incremental
16:22:39 <xyang1> so if the base driver do a create volume from snapshot and use local_path only in L
16:22:42 <eharney> yes, i think changing from "full backup id" to "parent id" etc. fixed most of my concerns around there at the basic level
16:22:45 <xyang1> only in LVM driver
16:23:16 <xyang1> that's kind of what Duncan suggested, I think.  that seems to be fine
16:23:50 <thingee> Murali: I'll try to take a look at this week before travels.
16:24:02 <thingee> Murali: thank you for working on this
16:24:04 <Murali> thanks a lot.
16:24:07 <Murali> no problem.
16:24:08 <thingee> and everyone for helping
16:24:32 <winston-d> Murali: question about your definition: 1st full backup, in your def, 2nd backup = delta diff to 1st, what about 3rd backup? 3rd will be delta against 1st as well?
16:24:48 <Murali> 3rd will be delta from 1st
16:25:21 <winston-d> Murali: I see, thx.
16:25:36 <thingee> #topic Discuss Updating Third Party Wiki
16:25:40 <thingee> #link https://wiki.openstack.org/wiki/Cinder/tested-3rdParty-drivers
16:25:44 <thingee> patrickeast: hi!
16:26:04 <patrickeast> hey, so first off, thanks for updating the requirements on that page thingee
16:26:05 <thingee> so from a previous meeting
16:26:05 <thingee> #link http://eavesdrop.openstack.org/meetings/cinder/2014/cinder.2014-10-15-16.00.txt
16:26:25 <patrickeast> the only piece of that remaining that i was wondering about is what we wanted to do for drivers added in Juno
16:26:34 <patrickeast> since the table w/ bugs is labeled for icehouse
16:26:37 <thingee> patrickeast: yeah honestly I did it *after* I saw your agenda item :)
16:26:52 <thingee> patrickeast: good point, I need to update that too.
16:27:15 <patrickeast> and i guess whether or not we are still doing the bug thing if we have a CI up and running
16:27:26 <patrickeast> do we just link to ci results or...
16:27:45 <DuncanT-> I think there's no point doing the bug thing when you have CI - that's the point of CI
16:27:53 <thingee> DuncanT-: +1
16:27:55 <jgriffith> DuncanT-: +1
16:28:05 <avishay> DuncanT-: +1
16:28:14 <jungleboyj> DuncanT-: +1
16:28:19 <thingee> my only main concern with CI's though is there's still not a good solution for vendors.
16:28:28 <DuncanT-> thingee?
16:28:36 <hemna> DuncanT-, +1
16:28:44 <DuncanT-> What do you mean?
16:28:50 <hemna> thingee, it is getting better though
16:29:15 <hemna> but slowly
16:29:28 <thingee> DuncanT-: there's still not a reliable way to get a ci system running. Last I spoke about this, I found using asselin puppet stuff not 100%. I have been talking to him though
16:29:51 <asselin> yes, I'm working to get the solution into -infra
16:30:12 <asselin> there's been lot's of upstream changes lately, so stability is not there
16:30:29 <asselin> I think once we get a solution in -infra it will be more stable and easier for everyone to use
16:30:30 <DuncanT-> thingee: Hopefully every vendor who sets one up will help smooth the process. I've no problem at all streading a bit of the pain to vendors, hopefully it provides some motivation to fix things - this has worked well so far
16:30:37 <thingee> I don't know if it makes sense, but maybe instead of vendors getting frustrated with trying to setup their own ci, maybe put that energy to helping asselin and co
16:31:19 <asselin> and then any changes that would 'break' 3rd party ci, might get caught at the gate.
16:31:30 <jgriffith> sigh
16:31:52 <jgriffith> maybe duplicating the OpenStack Infra isn't the best answer
16:32:16 <DuncanT-> thingee: Taht seems the logical solution to me, but then getting any vendor to talk about their CI experiences initially was like pull teeth.
16:32:18 <thingee> jgriffith: that's true. I know you had a working solution that was much simpler.
16:32:26 <asselin> I would rather call it, re-using
16:32:35 <hemna> asselin, +1
16:32:46 <jgriffith> thingee: yeah, the problem is there are "lots" of little one offs like mine out there
16:32:50 <DuncanT-> thingee: Frankly I don't /care/ which route they take, though I try to guide them into cooperating
16:32:54 <jgriffith> thingee: which is bad as well
16:32:58 <bswartz> DuncanT's KISS CI gets my vote
16:33:01 <asselin> right now, it's duplicating, and since we're out of tree, it's painful
16:33:37 <asselin> infra's interested b/c then one solution can benefit all of openstack projects/programs
16:33:55 <DuncanT-> thingee: CI /will not happen/ unless there is a forcing function, and while I'm entirely flexible as to how that forcing function works, backing off until somebody has doen all the work for them does not put pressure on anybody to find the resources to do the work
16:34:12 <thingee> DuncanT-: I can agree with that
16:34:18 <DuncanT-> bswartz: Use jgriffith's fork, he's way ahead of me now
16:34:30 <bswartz> link?
16:34:47 <vilobhmm> thingee, DuncanT : Also while dicussing last week there was an idea for a seperate CI pipeline for projects which can have an impact but are still WIP do we have any plan regarding that ?
16:34:57 <DuncanT-> bswartz: Give me 5
16:34:58 <jgriffith> bswartz: https://github.com/j-griffith/sos-ci
16:35:20 <jgriffith> probably needs a refresh, I'll have a look later this morning
16:35:42 <bswartz> "sort of simple" I love it
16:35:44 <thingee> patrickeast: to answer the original point of this topic, I will update the wiki
16:35:50 <DuncanT-> Suggestions about making something like kiss-ci a more official option resulted in some very rude comments from -infra team members
16:35:51 <jgriffith> bswartz: I've added some things for multiple nics etc
16:35:53 <patrickeast> thingee: haha thx
16:36:42 <patrickeast> and so to make sure i understand, for my driver that landed in Juno since we have  CI we don't need to put up an updated bug w/ test results?
16:36:57 <thingee> patrickeast: you're golden as far as I'm concerned
16:37:01 <patrickeast> kk
16:37:14 <thingee> #topic Project suggestions for OpenStack OPW
16:37:29 <thingee> #link https://wiki.openstack.org/wiki/OutreachProgramForWomen/Ideas
16:38:17 <thingee> I have listed myself as a mentor for the Gnome Outreach program for women. OpenStack has been doing this since 2012 and it would be great to have other members of cinder that have time to give guidance.
16:38:27 <thingee> signup for mentor is in that link
16:38:47 <thingee> but mainly it would be great if people have ideas of cinder projects that would be good for someone participating for the few months
16:39:01 <thingee> to later present their work at the next next summit
16:39:48 * DuncanT- has some gate ideas, nothing cinder specific ATM
16:40:12 <thingee> even if you don't want to spend the time to add a project to the wiki page and know of some new enhancements to cinder, just ping me and I'll take care of it
16:40:43 <thingee> just would appreciate people being mindful of ideas that we would like to see happen this release that would be good canididates for the short time we can work with someone.
16:40:55 <thingee> #topic Liaison for Cinder third party CI
16:41:27 <kmartin> asselin: ^^ :)
16:41:56 <thingee> #idea have a cinder liaison to help in #openstack-infra channel and ML with ci questions relating to storage
16:42:29 <thingee> so anteaya and co have to deal with all projects in ci systems. If we want ci systems there has to be someone that can handle block storage cis.
16:42:33 <asselin> also, to help identify ci systems that need to be disabled
16:42:43 <thingee> asselin: yes was just going to get to that
16:43:03 <thingee> on the infra ML, it's mostly guessing work on whether to reenable.
16:44:04 <thingee> so I thought this would be great for people who already have their ci setup to participate
16:44:35 <thingee> patrickeast, xyang1 ^
16:44:59 <xyang1> thingee: I  can help of course, I think asselin has the most knowledge
16:45:05 <asselin> I can help with ci questions
16:45:18 <xyang1> DuncanT-?
16:45:19 <patrickeast> i'm game to help out, i agree though that asselin would be best for the liaison role
16:45:19 <DuncanT-> One thing that would make a difference I think is for the XXX has been disabled mails on the list to be flagged with what project(s) they CI for, so that I can filter - I follow the list occasionally but it is hard to tell what is relevant
16:45:45 <asselin> I think -infra wanted a core? member to decide which to enable/disable in case of issues
16:45:58 <thingee> I instantly thought about asselin, but I was concerned about this distracting with the important infra work you're already doing
16:46:20 * DuncanT- can do it, but I'm not currently running a CI system
16:46:37 <thingee> DuncanT-: not a requirement, but if you want to watch the lists that's fine.
16:46:50 <kmartin> DuncanT- your company is
16:46:57 <asselin> I can help with ci setup and watching the mailing list.
16:47:30 <asselin> I'm not actively monitoring the results of other ci-systems however.
16:47:46 <thingee> yeah so that's important I think for disable/renable
16:47:47 <DuncanT-> thingee: I've been somewhat defacto ddoing the job to a degree since anteaya pokes me from time to time, might as well put my name on it if nobody else is suitable. I can work with asselin just fine
16:48:00 <hemna> it sure would be nice to have a health meter of 3rd party Cinder CI's
16:48:09 <DuncanT-> I want to script some CI monitoring and dashboard, so moving that up my priorities is fine
16:48:16 <hemna> like that one page we saw in Ft. Collins with the graphs
16:48:17 <thingee> How about DuncanT- watches the list, and asselin you can help in #openstack-infra?
16:48:18 <hemna> that was cool
16:48:30 <asselin> yes, there's going to be discussions on monitoring third party ci at the summit
16:48:44 <hemna> I think anteaya had that link previously
16:48:46 <thingee> I think whoever handles disable/enable should have somewhat of a history of the ci from gerrit's standpoint
16:48:47 <jgriffith> hemna: +1
16:48:50 <asselin> thingee, I can do that
16:49:01 <thingee> DuncanT-: is that fine?
16:49:02 <jgriffith> hemna: I'd propose a dashboard as the single version of truth
16:49:07 <DuncanT-> Fine by me, yeah
16:49:10 <hemna> jgriffith, +1
16:49:30 <DuncanT-> jgriffith: I'll code it, you can tell me what I got wrong ;-)
16:49:35 <jgriffith> hemna: yeah, anteaya showwed that and personally I think it's the way to go
16:49:38 <hemna> CI's break all the time as of no fault of the infrastructure and or upstream patches.
16:49:45 <jgriffith> DuncanT-: awesome!
16:49:48 <asselin> #link third party summit etherpad https://etherpad.openstack.org/p/kilo-third-party-items
16:49:48 <thingee> #agreed DuncanT- will handle the openstack infra ML for reenable/disable CI | asselin will help for block storage ci's in #openstack-infra
16:50:02 <DuncanT-> By code I quite possibly mean 'steal', like all the great artists
16:50:18 <hemna> jgriffith, agreed.  that dashboard was great.
16:50:19 <thingee> #topic New Drivers deadline in Kilo
16:50:19 <jgriffith> DuncanT-: of course, you'd be a fool not to do it that way :)
16:50:37 <hemna> DuncanT-, whatever it takes brother :)
16:51:00 <thingee> Per DuncanT-'s email earlier to the list about only accepting drivers in k-1
16:51:31 <thingee> I would like to do a cut off of accepting new bps and in general cutting off new drivers being proposed in K-1
16:51:38 <jgriffith> thingee: DuncanT- was K-1 a made decision?
16:51:42 <jgriffith> thingee: ahh... yeah, ok
16:51:49 <rhe00> how do I get my driver on the review list for K-1?
16:51:52 <jgriffith> proposals in K-1
16:51:56 <DuncanT-> jgriffith: That's what we said in FC
16:51:58 <thingee> jgriffith: yeah I don't have the links handy, it was in some previous meeting and then brought up on the ML
16:52:04 <DuncanT-> rhe00: Post the code!
16:52:11 <hemna> DuncanT-, +1
16:52:18 <jgriffith> DuncanT-: yeah, thought so but there's been miscom on a number fo things so wanted to clarify
16:52:24 <bswartz> does that mean that new drivers have to be proposed but not merged by K-1?
16:52:25 <xyang1> thingee: is 12/18 the drop dead date?
16:52:28 <hemna> rhe00, yah, get the code in gerrit as soon as you can.  even if it's WIP.
16:52:37 <rhe00> DuncanT: it was posted before Juno
16:52:44 <jgriffith> wording there sounded like "submission" not proposal
16:52:44 <thingee> xyang1: I just mean proposals. an intent to submit a new driver
16:52:50 <jgriffith> important distinction IMO
16:52:56 <DuncanT-> rhe00: Ah, poke some people for reviews then, including me
16:52:57 <rhe00> just want to make sure it is marked correctly so it isn's overlooked
16:53:04 <xyang1> thingee: what about driver code submission date?
16:53:28 * DuncanT- would like code up before K1...
16:53:44 * jgriffith would propose close of K2 for submitted patches
16:53:47 <hemna> DuncanT-, +1
16:53:49 <thingee> #idea deadline to accept new driver blueprints for Kilo ends Nov 7th
16:53:53 <DuncanT-> 'Intent' is easy... Vaguely working code is harder, and long running driver reviews suck up lots of time
16:53:57 <bswartz> and is there are cutoff for merging new drivers? depending on how slow the author and reviewers are, the review/update cycle can take weeks for a driver to go from submitted to merged
16:54:05 <xyang1> if it is close to K2, then that is similar to Juno?
16:54:28 <DuncanT-> I'd say aim to merge before K2
16:54:31 <thingee> If we're following our previous discussion, we would want the code merged in k-1
16:54:36 <jgriffith> DuncanT-: I'm down with that
16:54:38 <thingee> DuncanT-: +1
16:54:54 <thingee> but the code needs to be in k-1
16:54:54 <hemna> DuncanT-, +1
16:55:01 <jgriffith> DuncanT-: thingee TBC... you're saying merged BEFORE k-2 opens up?
16:55:08 <jgriffith> ie last items for K-1?
16:55:09 <eharney> this is getting kind of confusing
16:55:20 <xyang1> eharney: +1
16:55:26 <jgriffith> eharney: indeed
16:55:26 <xyang1> I''m confused
16:55:30 <DuncanT-> jgriffith: I don't think we can manage that, sadly
16:55:37 <jgriffith> DuncanT-: I don't either
16:55:39 <thingee> let me try this again
16:55:42 <jgriffith> DuncanT-: that's why I called i tout
16:55:50 <DuncanT-> I think code up before K1, merged before (end of) K2
16:56:09 <thingee> blueprint deadline Nov 7th, code should be in gerrit by K-1
16:56:11 <DuncanT-> With the first being a hard cutoff
16:56:22 <xyang1> I thought the original plan was to get driver code submitted by K-1
16:56:25 <eharney> i thought we weren't doing blueprints/specs for new drivers anyway
16:56:25 <jgriffith> thingee: ummm... that might not bfly
16:56:40 <thingee> jgriffith: not sure what bfly is
16:56:50 <jgriffith> thingee: hehe... "fly"
16:57:04 <jgriffith> thingee: you might want to give some amount of time after communicating the policy at the summit
16:57:08 <thingee> jgriffith: ok
16:57:15 <xyang1> eharney: I thought at least not spec
16:57:27 <jgriffith> eharney: no specs, but still need bps IMO
16:57:29 <thingee> fine Nov 15 for bp deadline
16:57:38 <thingee> for k-1
16:57:47 <thingee> and k-1 is the only time to get drivers in
16:57:59 <xyang1> thingee: so bp 11/15, code submission 12/18?
16:58:05 <thingee> yes
16:58:09 <xyang1> thingee: thanks
16:58:12 <eharney> er
16:58:12 <jgriffith> sold!
16:58:20 <eharney> 12/18 submission or merged in
16:58:21 <hemna> xyang1, +1
16:58:25 <eharney> 12/18 is k-1
16:58:39 <DuncanT-> eharney: Submission
16:58:43 <thingee> eharney: submitted
16:58:45 <eharney> ok
16:58:46 <bswartz> code submitted by 12/17 won't be merged by 12/18
16:59:01 <bswartz> any deadline for merge? or is that fuzzy?
16:59:01 <thingee> submitted just means posted to gerrit not merged
16:59:13 <xyang1> is there a driver code merge deadline?
16:59:16 <eharney> thingee: can we cover any non-driver blueprints/specs deadlines so we're all on the same page there too?
16:59:18 <xyang1> Ki-2?
16:59:21 <thingee> ok I'll send this to the list replying to duncan's original email
16:59:22 <xyang1> k-2
16:59:33 <jgriffith> hey... can we just say:
16:59:34 <thingee> this includes bp/specs for k-1
16:59:43 <thingee> they should be submitted to k-2 or k-3
16:59:47 <thingee> for non-drivers
16:59:54 <jgriffith> We will not accept any driver/code *submissions* after 12/17
17:00:02 <thingee> #endmeeting