16:02:12 #startmeeting cinder 16:02:13 Meeting started Wed Jun 18 16:02:12 2014 UTC and is due to finish in 60 minutes. The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:16 The meeting name has been set to 'cinder' 16:02:17 Hey everyone 16:02:19 o/ 16:02:22 hello 16:02:25 hi 16:02:26 Happy Wednesday. 16:02:29 morning 16:02:32 Hi 16:02:35 hello 16:02:35 hi 16:02:42 hi 16:02:54 we have a quick agenda today 16:03:00 Hi: First time attendee here. 16:03:02 famous last words 16:03:09 jkremer: welcome 16:03:13 thingee: true 16:03:16 :/ 16:03:32 hi 16:03:37 #topic review day 16:03:45 o/ 16:03:50 So lots of activity going on in terms of reviews 16:04:01 That is good news. 16:04:03 thanks to everyone that's carving out some time and helping out here 16:04:07 would it make sense to do a hangout again? 16:04:25 thingee: I was hoping to keep it informal 16:04:29 * jungleboyj is looking the debug one right now and has been working on the Database change as well. 16:04:38 Just raise awareness and get folks to do a few reviews 16:04:49 we've been pretty slack as of late in general 16:05:03 thingee: if the review are being kept up on it's probably not needed 16:05:04 depending on what the queue looks like after today I'd like to consider a formal day next week 16:05:08 with a Google-Hangout 16:05:31 seem reasonable? 16:05:33 +1 16:05:36 +1 16:05:37 jgriffith: Sounds reasonable. 16:05:51 +1 16:05:59 alright... so I just wanted to make sure we raised awareness on the topic 16:06:00 does the bot count ±1 votes, too? 16:06:09 and send a plea to everyone here.... 16:06:24 Please, if you can set aside some time each day to do even just one or two reviews 16:06:32 that applies to EVERYONE 16:06:40 that would be great 16:06:47 jgriffith: I will try to do what I can. 16:06:50 core should be doing at least that 16:06:53 just blueprints or SPECs also? 16:07:00 flip214_: what do you mean? 16:07:02 flip214_: ohhhh 16:07:11 flip214_: ignore the bot, core should just +2/A those 16:07:15 don't waste your time :) 16:07:27 Arkady_Kanevsky: code reviews 16:07:42 OK 16:07:44 Arkady_Kanevsky: good point... I'm mostly interested in whittling down code submissions today 16:08:02 Arkady_Kanevsky: in general though, sure.... specs as well. Input is always welcome 16:08:23 just today I want to focus on our backlog of code submissions 16:08:41 any questions/concerns? 16:09:01 cool 16:09:09 thanks for everyone that's pitching in here today 16:09:19 #topic cinder meetup in FTC 16:09:42 I think Scott put together an etherpad for us: https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014 16:09:43 https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014 16:09:49 scottda: :) 16:10:11 whole week meeting? 16:10:15 jgriffith: is it also going to be shared online on hangout? 16:10:15 Things are pretty set from this end for now. Chime in on the etherpad and let me know if I'm missing anything. 16:10:26 One thing I realized I should point out to folks.... Denver and particularly Fort Collins aren't exactly like the Bay area etc 16:10:47 I thought is was going to be three days 16:10:56 kmartin: it was :) 16:11:13 from eitherpad - Cinder Mid-Cycle Meetup August 11-15th 2014 16:11:21 so let's figure that out right now 16:11:44 full week is great for some folks traveling internationally ( DuncanT- ) 16:11:48 tuesday to thursday? 16:11:50 but what about others? 16:12:06 kmartin: tuesday-thursday seems reasonable to me 16:12:16 allows people to NOT travel on the week-end 16:12:20 tu-th good. traveling on Mond & Friday 16:12:37 jgriffith: whats the procedure for joining it remotely? 16:12:39 Anybody object to Tues - Thurs? 16:12:51 jgriffith: No, that would work great for me. 16:12:52 DuncanT- can go dancing the other two days 16:12:54 navneet: We'll set up a hangout 16:13:01 jgriffith: That was what I had proposed to my management. 16:13:06 jgriffith: cool... 16:13:31 navneet: I'll proably bring an extra laptop just to setup/run a hangout with 16:13:32 agree +1 on the days 16:13:48 jgriffith: that would be gr8....thx 16:13:51 Ok... So the plan is Tues - Thurs 16:14:03 Note my points about things like public transportation 16:14:17 You don't want to take a cab from DIA to FTC 16:14:26 rent a car. find a buddy to carpool 16:14:32 there are shuttles and car services but yes... 16:14:37 as Arkady_Kanevsky says... 16:14:47 rent a care and if you can coordinate carpool 16:14:50 Anybody know if the shuttle services that run during ski season still operate int eh summer? 16:15:01 If there is anyone that wanted to try and meet in DIA and get a ride I should be able to get a rental. 16:15:06 There are airport shuttles. 16:15:17 glenng: there is SuperShuttle 16:15:18 http://www.supershuttle.com/Locations/DENAirportShuttleFortCollins.aspx 16:15:28 scottda: What is the address of the HP site? 16:15:36 use etherpad https://etherpad.openstack.org/p/CinderMidCycleMeetupAug2014 for car pooling 16:15:38 See the etherpad for HP site google map 16:15:48 scottda: Thanks. 16:16:31 Also, HP employees get a discount at the nearby Cambria suites. Let me know and I can try to block out some rooms (let me know about how many rooms) 16:17:44 ok... so we'll put more details together as we go along 16:17:54 but the meetup IS happening and we have dates and a location 16:18:07 Will the meeting be useful for newbies? 16:18:08 a HUGE thanks to scottda for cooridinating this 16:18:22 np. 16:18:24 jgriffith: +10 16:18:24 jkremer: my crystal ball says "sure" :) 16:18:40 Cool I'll attend (since I live in CO anyway) 16:18:42 jgriffith: is there a proposed agenda? 16:18:49 jkremer: I would think so. Wish I had a summit or something like the meetup when I first started. 16:18:54 now if I can just get approval for travel 16:18:55 jkremer: oh... well then you should at least stop in for a day or so 16:19:11 hemna: you better, since we changed it specifically at your request! 16:19:31 and I had to reschedule a bunch of stuff as a result 16:19:49 yah...unfortunately it's out of my hands :) 16:19:51 * DuncanT- will come up for the week anyway, there are plenty of none-cinder folks in FC I need to meet 16:19:52 err :( 16:19:54 bleh 16:19:57 (Soory I'm late ;-) ) 16:20:06 scottda: can you put the building # for the lobby that you want people to go into? 16:20:06 jgriffith: you stay in CO too....some space in ur farmhouse :) 16:20:14 I'm hoping I get to go....as I might head to Montana after to get some fly fishing in. 16:20:15 hemna: ummm... maybe you should've just responded "can't go" instead 16:20:17 but too late now 16:20:33 hemna: bring your fly-rod.... I'll take you to a spot here 16:20:42 sweet! 16:20:44 Welcome to the party DuncanT- 16:20:52 and I'll drive up to Missoula with you after :) 16:20:52 kmartin: will do 16:20:59 Ok... 16:21:07 more details to come but we've got things lined up 16:21:31 #topic seperating control and data planes in drivers 16:21:41 So I had hoped to share some code today 16:21:48 but I've got some other things going on 16:21:57 I've almost got this *done* 16:22:07 is that the " Separation of Connectors from Driver/Device Interface (status update) [jdg] " point now? 16:22:16 There's going to be a bunch of cleanup in drivers and in the unit tests though 16:22:24 flip214: yes 16:22:28 I'm asking because the wiki title made me think about splitting up drivers 16:22:33 is everybody clear on what that means? 16:22:39 flip214: ok... there's my answer 16:22:42 but I don't really know about "separating control and data planes" 16:22:52 so... one of the problems I see in our current architecture 16:23:04 control path and data path are intertwined 16:23:11 IIUC you want to move the iSCSI connector out of the LVM driver interface, right? 16:23:17 as an example 16:23:30 for example you have things like driver-->iSCSIDriver--->LVMiSCSIDriver etc etc 16:23:34 jgriffith: is this not brick? 16:23:38 flip214: yes 16:23:56 akerr: it was supposed to be but IMO brick has pretty much failed and is dead :( 16:23:59 akerr: but.... 16:24:02 more to the point.... 16:24:09 if you look at what we have today... it's a mess 16:24:27 We have some iscsi/data-path things being done in driver.py 16:24:31 some in volume/iscsi.py 16:24:33 jgriffith: brick is dead means....some other component to replace? 16:24:36 and yet more in brick/iscis 16:24:45 navneet: slowwww down now :) 16:24:51 um. that's quick important to me, because now I have to re-think about the layering inbetween - replication driver (LVM - DRBD - iSCSI) 16:25:03 ;-) 16:25:12 so what I'm working on is seperating the connection code from the drivers completely 16:25:13 so yes, having some code to look at would be quite nice ... 16:25:19 navneet: Brick is what it is, this new stuff probably isn't going into brick 16:25:21 I'm surprised to hear about the death of brick 16:25:40 bswartz: hold on... let's not get carried away 16:25:42 DuncanT-:interesting 16:25:58 * DuncanT- is far from convinced brick is dead, brick just didn't turn out to be what was originally planned for it.... IMO 16:25:59 jgriffith: you were the one that said it :-p 16:26:11 what I meant by that was that it never really turned into anything 16:26:15 i think we need a blueprint somewhere explaining some of this 16:26:28 and frankly it added some complexity that I hadn't intended or foreseen 16:26:34 DuncanT-, well I disagree with that. the initiator connector stuff is good and is needed by cinder and nova 16:26:34 good idea, bad outcome 16:26:52 hemna: DuncanT- ok... don't worry 16:27:10 first patch to seperate things brick will still be there and will get "more" items 16:27:17 The target side of brick hasn't panned out yet 16:27:20 that I agree with. 16:27:22 right now tgt-helper functions are spread out in 3 places 16:27:30 in other words brick was never really "finished" 16:27:44 jgriffith, agreed. 16:27:48 anyway... I'll get code up this week 16:27:49 hemna: There's lots of good stuff in brick, just not the stuff that was planned back when we floated the concept 16:27:55 it'll be easier to talk to 16:28:09 jgriffith, very cool. Looking forward to it. 16:28:12 and the main thing is I'm trying to make sure there's backward compatability 16:28:18 and that upgrades aren't broken 16:28:30 DuncanT-, jgriffith: do we have spec or design somewhr? or some modifications to brick 16:28:32 jgriffith: could you share some git URL for your work, so that I can look at what you're doing? 16:28:35 The idea is that one "should" be able to do things like: 16:28:45 have LVM as a backend device 16:28:58 and EASILY configure what protocol to use with it 16:29:06 jgriffith, I'm curious/interested in the FC side of things, especially since I've kinda removed most concepts of FC in the volume manager and VolumeDriver now with my latest patch 16:29:08 iscsi, fibre, direct etc 16:29:24 and add things in the future if needed like infiniband or whatever 16:29:34 very cool 16:29:44 To be clear I'm not proposing infiniband... just an example 16:29:59 hemna: shouldn't FC also be part of the connector component? 16:30:04 hemna: yeah, that's why I pinged you about this last week 16:30:09 for this new code, just make sure we have something (spec/blueprint) describing the direction and goal, relation to brick, etc 16:30:09 navneet, yes it should 16:30:10 so, less inheritance in the code? 16:30:13 jgriffith: rtslib takes care of management of these things pretty well. 16:30:19 navneet, there is already a connector in brick for FC 16:30:21 eharney: understood 16:30:26 and more of "take this backend device, and use its functins" 16:30:30 *functions 16:30:41 eharney: wanted to make sure I actually had folks on board and clear on the goal before that 16:30:41 hemna: ok...so code move is on your cards 16:30:46 jgriffith: Is the expectation that all drivers move to this approach by the end of Juno or are you flexible on that timing? 16:30:47 eharney: and there is a bp for this 16:30:56 a connector HAS A backend, and there won't be so many classes that ARE lvm and iscsi. 16:30:59 jungleboyj: that's going to depend 16:31:11 jungleboyj: I'm going to try and actually fix that myself but we'll see how it goes 16:31:21 jgriffith: have you considered using rtslib as an interface for the different connectors? 16:31:23 flip214, well, I think we'll still have driver inheritance, just not broken inheritance like we have now. 16:31:27 jungleboyj: I certainly don't intend to just "break" everybody's driver. that would be stupid 16:31:46 thingee: that's a future topic IMO 16:31:54 thingee: fwiw one stumbling point w/ rtslib at the moment is that it requires the library to run as root 16:31:59 thingee: I don't want to force any one solution right now 16:32:08 thingee: for now I just want to seperate the code 16:32:15 rtslib could just be another connector 16:32:24 have a logical implementation that's actually maintainable and works 16:32:37 +1 to maintainable ;) 16:32:42 hemna: yeah... and that's the idea for what I'm doing currently 16:32:43 hemna: well rtslib provides an interface for iscsi, fc, infraband, etc 16:32:57 it wouldn't be a connector imo 16:32:58 thingee: yeah, which is coool.... 16:32:58 jgriffith: Right, I knew that backwards compatibility was planned but just wondering if there is an expected time frame for people to move. 16:32:59 jgriffith: so many places we need to implement this principle 16:33:03 maintainable 16:33:11 thingee: but I'm not willing to say you "have to" use rtslib 16:33:13 jgriffith: Or are you thinking that drives may not need to make a change? 16:33:13 at least not right now 16:33:16 thingee, yup, but there is no harm in creating an rtslib connector. 16:33:29 imo a connector is the fabric 16:33:35 navneet: yeah, but this is one of the worst areas currently IMO 16:33:53 navneet: try following things like the attach process today 16:33:57 jgriffith: why dont we identify the areas and post it somewhr 16:34:00 heh 16:34:01 particularly with the LVM driver 16:34:03 it's henous 16:34:11 navneet: go ahead 16:34:13 :) 16:34:27 anyway... 16:34:30 jgriffith: ll post and catch DuncanT- :) 16:34:44 I'll get my prototype code up here in the next day or two and let everyone know when it's up 16:34:59 thanks 16:35:02 I don't think there should be any objectsion to the idea 16:35:09 impl maybe... but not the concept 16:35:18 #topic 3'rd party CI updates 16:35:26 Ok... so we're in J-2 16:35:42 not seeing any 3'rd party CI testing in the reviews (including my own) 16:35:55 jgriffith: we are facing connectivity issues...working on it 16:35:58 Just want to make sure folks are in fact keeping in mind we MUST do this for J-2 16:36:08 Have anyone successfully setup the whole thing? 16:36:10 navneet: yeah, akerr filled me in on the joys yesterday 16:36:21 navneet: I have the same problem on my side ;) 16:36:33 xyang1: I've succesfully set it up and run 16:36:36 jgriffith, navneet: i think I *might* know what the issue is, but i'll take it offline 16:36:39 jgriffith: :) ...I am not alone...thanks God 16:36:41 xyang1: I haven't succesfully got my voting to work 16:36:51 jgriffith: can you get events? 16:36:55 xyang1: yes 16:37:06 jgriffith: so you don't have firewall issue? 16:37:09 we are blocked on an internal IT request currently 16:37:12 xyang1: no 16:37:23 suppose to be resolved at the end of June. :( 16:37:28 * hemna waits for HPIT 16:37:32 we had big problems with IT:( 16:37:44 You can use corkscrew or similar to get the events through most https proxies.... 16:37:45 so you folks can't get "out" ? 16:37:53 we requested unblocking the ports, but they are very concerned 16:38:08 Your firewall blocks you going out to OpenStack Infra? That sucks 16:38:10 git review is blocked 16:38:21 yah there is a port that has to get opened up for us to do it. 16:38:33 there are other projects inside of HP that need it as well. 16:38:39 since this is in a lab, not someone's laptop, they are concerned that noone is monitoring this 16:38:48 Ok... sounds like a lot of challenges (which I suspected) 16:38:52 our fw sucks for many reasons. 16:39:02 hemna: +1million 16:39:17 We have hardware and some of the other pieces in place. Looking for resource to get everything set up. 16:39:18 hemna: you can proxy... 16:39:30 I can see if corkscrew helps us at all in this situation, but I'm not sure it does. I use it for git review submissions locally 16:39:30 proxy from your lab to your laptop to gerrit :) 16:39:31 #link http://dilbert.com/strips/comic/2007-11-16/ 16:39:32 the fw being opened is more of a convenince thing 16:39:36 and hope you don't get fired 16:39:39 about publishing logs, where to do that? 16:39:42 hehe 16:39:49 clarkb: ahh.. you have an alternate 16:39:51 yah, I've done ssh tunnels like that before.... 16:39:53 sshhh 16:39:59 you don't even need an ssh tunnel 16:40:10 hemna: was thinking tunnelling ;-) 16:40:10 Does it only support "scp" when publishing logs? 16:40:49 clarkb: is there a documented alternative for these folks? 16:40:51 hemna: the corkscrew is for opening the bottle to drown your sorrows 16:40:58 :) 16:41:17 akerr: +2 16:41:27 jgriffith: if we don't use nodepool, just restart slave node after runs, is that acceptable? 16:41:28 jgriffith: yes iirc therea re internal docs for how to talk to gerrit 16:41:34 hemna: You can absolutely use corkscrew to get a CI working... I just don't know where to plug it into the CI-in-a-box stuff 16:41:37 clarkb: great.. thanks 16:41:44 clarkb: I'll take another look there later 16:42:07 hemna: xyang1 let's see if the official OpenStack docs can solve this for us 16:42:12 or ... you :) 16:42:18 heh ok. 16:42:19 well not the official docs 16:42:30 we can't support everyones flavor of ridiculousness upstream :) 16:42:36 but there are knwon workarounds at hp 16:42:41 clarkb: haha... good point. I call them "official" as they live on OpenStack web-servers 16:42:50 clarkb: haha 16:43:06 jgriffith: so we can run it by restarting slaves, but it doesn't look like we can get nodepool setup on time to meet the J-2 deadline:( 16:43:19 xyang1: IMO that's ok 16:43:37 xyang1: node-pool isn't a requirement. Just running against patch submissions 16:43:44 jgriffith: that's a relief. 16:43:56 xyang1: I have the same problem of needing to restart slaves 16:44:03 for now I'm just living with that 16:44:28 although I can't figure out *why* I need to restart them 16:44:42 doing things like "clean.sh" etc doesn't work either 16:44:54 jgriffith: another question is whether we can filter out some commits. I mean there are about 10-20 commits every day, each run taks > 1 hour. if we run against each commit, it will choke up the system 16:45:07 s/taks/takes 16:45:14 xyang1: I think we agreed you only have to run against cinder commits 16:45:32 and yes, everybody felt you should run against all fo them 16:45:33 of 16:45:38 jgriffith: 10-20 cinder commits a day 16:45:51 yep 16:46:02 thats' what we all discussed in ATL 16:46:02 xyang1: nodepool helps here 16:46:09 is any list of planned 3rd party CIs available? i'm new in cinder and working on integrating testing with ceph as beckend 16:46:22 e0ne_: nope 16:46:31 navneet: we can't have nodepool setup on time for J-2:( 16:46:40 e0ne_: but somebody is going to need to pick up things like Ceph/RBD, Gluster, NFS etc 16:46:55 jgriffith: NetApp plans to pick up generic NFS 16:46:59 i hope, i'll do it for juno-2. 16:47:00 xyang1: you can set it in J3...and minimize time later on 16:47:05 akerr: yay! 16:47:19 navneet: sure, that is our long term plan 16:47:20 akerr: I'll start a wiki page and we can track this sort of thing 16:47:25 akker: Kudos 16:47:44 jgriffith: great! i'm already working on ceph testing using https://review.openstack.org/65113 16:47:54 nice 16:48:24 jgriffith: eventually we'd like to see it migrate to the gate, but we can cover for now 😊 16:48:29 navneet: have you figured out where to publish logs 16:48:31 e0ne: Ohh.. you're Sebastien! Nice to meet you :) 16:48:47 nope, I'm Ivan:) 16:48:53 Oh 16:48:53 xyang1: you will need a publicly accessible host 16:49:02 scp working 16:49:02 well... then "I'm confused" :) 16:49:07 i just using Sebastien's patch 16:49:15 navneet: are you hosting it inside your company? 16:49:21 e0ne: hehe... cool 16:49:25 ok... 16:49:26 xyang1: thats the plan right now 16:49:34 :) 16:49:36 xyang1: We've got a nice public cloud if it helps ;-) 16:49:40 we've got a lot of work and figuring out to do here obviously 16:49:47 DuncanT-: :) 16:49:58 let's keep it on a weekly agenda to get updates 16:50:01 there's always s3 16:50:02 Duncant-: ll need it too...is it free? 16:50:05 xyang1: IBM has a good one as well. ;-) 16:50:07 DuncanT-: does that work with scp? 16:50:14 if we aren't making much progress by next week let's come up with some action plans to get this going 16:50:19 IBM does the cloud? 16:50:21 :P 16:50:24 public clouds do NO good here 16:50:24 jungleboyj: softlayer? 16:50:33 but I suspect this was all sarcasim 16:50:42 xyang1: Sure, spin up a webserver on a VM and scp into the public_html directory.... should work fine 16:50:42 hemna: :-p 16:50:44 sarcasm even 16:50:44 xyang1: Yes. 16:50:47 jgriffith: where are you posting logs 16:51:03 xyang1: my own personal AWS server 16:51:07 jgriffith: Public clouds are a great place to post logs.... 16:51:10 So for FC CI, we haven't had a chance to test the PCI passthrough stuff yet. It's on our short list though. 16:51:18 sorry... I didn't realize you were just talking about logs 16:51:22 xyang1 will Dunkin' Donuts host a machine for you? 16:51:29 DuncanT-: yes... sorry, missed the context there 16:51:37 DuncanT-: but HP ain't cheap :) 16:51:44 DuncanT-, I was actually going to fire up a vm in my HPCloud account to post our logs 16:51:45 kmartin: I should start working with them on that:) 16:52:06 xyang1: :) 16:52:10 alright... we can all chat on this more in #openstack-dinder 16:52:12 cinder even 16:52:24 * hemna joins #openstack-dinder 16:52:28 One last thing I want to throw out there... 16:52:30 * jungleboyj likes openstack-dinder .... or openstack-dinner 16:52:33 hemna: funny funny :) 16:52:44 #topic upcoming decisions 16:52:44 or openstack-tinder, the openstack dating site 16:52:53 lol 16:52:53 akerr: LMAO 16:53:10 ok so there are two big things we need to decide upon soon 16:53:18 I don't want to debate them today or discuss them here 16:53:31 jgriffith: coming up with the etherpad for comparisions 16:53:34 but I want to make sure EVERYBODY is researching and gathering facts 16:53:37 pools 16:53:41 as well as coming up with ideas 16:53:52 akerr: :-) 16:54:01 item 1: SDS abstraction layers as drivers in Cinder 16:54:02 jgriffith: whats the way forward...whr do I post the link? 16:54:20 This is not JUST EMC's VIPR product 16:54:27 navneet, https://review.openstack.org/#/c/98715/ I'm rooting for that one. 16:54:36 there are at least 1/2 a dozen of these types of solutions waiting behind VIPR 16:54:42 they all do the same sort of thing 16:55:06 hemna: I kow...I see problems with it 16:55:10 know 16:55:10 do some research please, read up on what these solutions do. How they fit in OpenStack/Cinder 16:55:15 ok.... 16:55:20 seems I've lost everyone here 16:55:29 what's #2? 16:55:35 o/ 16:55:44 still here 16:55:49 #2 is the pools implementations 16:56:08 jgriffith: etherpad is coming up....when do we discuss over it togetjer* 16:56:14 *together 16:56:17 ah ok. navneet and I jumped the gun 16:56:17 I'll be providing my input/opinion later this week 16:56:25 jgriffith: one question 16:56:30 I'd like to make a decision at next weeks meeting at the latest 16:56:33 guitarzan: sure 16:56:39 jgriffith, +1 16:56:48 the thing about driver contributors having to contribute "core" code is a complete myth right? 16:56:54 jgriffith:hemna: before that wil everybody get chance to look at etherpad? 16:56:59 hopefully winston will be around to talk about his patch this week 16:57:08 guitarzan: yeah... not sure where that came from exactly 16:57:13 jgriffith: decision on SDS by next week as well? 16:57:13 guitarzan: it'd sure be nice 16:57:16 ok, cool 16:57:22 guitarzan: and it will get you a lot of karma 16:57:31 but it's not something we actually track and enforce 16:57:38 and I personally have no inention of doing so 16:57:52 you can't improve perfection 16:57:57 xyang1: I think that would be nice 16:58:03 guitarzan: That's partly my fault... somebody took my 'I have higher expectations of of SDR driver authors than normal driver authors' and extrapolated in ways I didn’t foresee 16:58:05 please send the etherpad link to the mailing list, so that it's not so easily missed 16:58:10 guitarzan, if driver maintainers just support and maintain their drivers every release, I think that's a win. 16:58:16 jgriffith: Are you referring to the etherpads from the summit? 16:58:18 DuncanT-: ah, that's an interesting possibility 16:58:31 DuncanT-: I think it was a combination of that, one of my blog posts and *other* stuff 16:58:37 jungleboyj: huh? 16:58:38 guitarzan: It has been my stated view since the summit 16:58:54 2 minute warning 16:58:59 jgriffith: What etherpads are being referred to above? I am missing something. 16:59:21 jungleboyj: navneet has proposed an etherpad to compare his pools solution to winstons 16:59:34 jungleboyj: navneet is going to post one about pools implementations 16:59:44 jungleboyj: yep 16:59:44 jgriffith: Oh, ok. Sorry. 16:59:46 is there an echo in here 16:59:48 :) 16:59:56 is there an echo in here 16:59:59 LOL 17:00:00 :) 17:00:00 :) 17:00:03 alright.... 17:00:06 we're out of time 17:00:06 navneet: please put a link to it on the agenda as well 17:00:11 #endmeeting