19:00:39 <notmyname> #startmeeting swift
19:00:40 <SridarK> thanks bye
19:00:41 <openstack> Meeting started Wed Feb  5 19:00:39 2014 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:44 <openstack> The meeting name has been set to 'swift'
19:00:59 <notmyname> hello world!
19:01:02 <tristanC> hello!
19:01:03 <peluse> hola!
19:01:04 <chmouel> bonsoir!
19:01:08 <acoles> hi
19:01:09 <dirk> ehlo!
19:01:24 <torgomatic> erf
19:01:24 <portante> hello
19:01:25 <notmyname> looks like we have a full agenda for this meeting
19:01:27 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
19:01:44 <notmyname> but maybe some of it will go quickly (here's hoping ;-)
19:02:02 <notmyname> first, as a general update...
19:02:13 <notmyname> swift 1.12 was released last week.
19:02:18 <peluse> sweet
19:02:23 <notmyname> a few days later than expected because of the gate issues
19:02:55 <notmyname> seems that gate issues have lessened somewhat, but that's (AFAIK) mostly because of the limitation on concurrent patches being tested
19:03:05 <notmyname> that means less gate resets and therefore faster processing
19:03:13 <tongli> @notmyname, hi john.
19:03:24 <portante> notmyname: does it mean less stable code being committed?
19:03:25 <notmyname> there will be some trimming of the jobs that are run, so that should also help
19:03:38 <portante> still many rechecks
19:04:14 <notmyname> yes, there are many rechecks. but zuul is just testing the top XX patches in the gate instead of all of them. that means more nodes available for when resets happen in eg the top 10 patches
19:04:34 <notmyname> improvements, but IMO no fundamental systemic changes
19:04:47 <notmyname> anyway, that's all I got on that
19:05:23 <notmyname> seems like there are some discussions that may affect us to some degree in the TC and BoD about "what is openstack core", but I'll keep you up to date on that as new things happen
19:05:31 <notmyname> just stuff I'm keeping my eye on
19:06:10 <notmyname> so let's move on to the agenda items. anything else can go to open discussion at the end if we have time
19:06:20 <notmyname> #topic storage policy status
19:06:37 <notmyname> we've got about 8 weeks until the Icehouse RC is due
19:06:41 <peluse> so the EC branch was recently rebased (thanks torgomatic) and 3 patches were marged since
19:06:49 <notmyname> good
19:06:49 <peluse> there are now 5 policy patches ready for final review
19:07:03 <notmyname> status pon the account status rollup and the policy reconciler?
19:07:06 <peluse> beyond that, I have one todo (account roll-up) and torgomatic can speak to SLO/DLO
19:07:18 <zaitcev> So sorry not reviewing that.
19:07:37 <peluse> ahh, acct rollup is WIP.  torgomatic has the SLO/DLO and container reconciler
19:07:53 <notmyname> DLO was just approved I think
19:07:57 <notmyname> SLO is merged
19:08:00 <notmyname> torgomatic: right?
19:08:03 <peluse> cool
19:08:31 <peluse> so that would mean 5 in need of final review, 2 WIP and from there I think we are ready to make the call on merge to master
19:08:33 <torgomatic> SLO is done and merged, DLO has had troubles merging, but we've been hitting it with the reverify plunger, and it'll go in eventually
19:08:37 <peluse> well... docs too :)
19:08:53 <notmyname> it would be a good idea for people to start taking a look at the branch (feature/ec). after the rollup and reconciler land, the feature/ec branch needs to be proposed for merge into master
19:09:04 <peluse> torgomatic:  have you had a chance to look at the container reconciler (clayg said he thought you were doing it)
19:09:11 <torgomatic> I think object versioning can live without being hoisted into middleware, FWIW... when I looked at the code I didn't see that it was necessary
19:09:25 <torgomatic> peluse: yeah, I've started poking at it, but nothing interesting enough for Gerrit yet
19:09:25 <notmyname> I expect that merge process to take a few weeks, then we should be able to let it sit for a couple of weeks before the Icehouse RC
19:10:05 <peluse> great, lets get those reviews going.  the 5 that are up there are small compared to the last several
19:10:20 <notmyname> am I missing anything on storage policies here that are necessary before the merge to master?
19:10:46 <peluse> i think Trello is up to date - all required are in doing or code review or done
19:11:08 <peluse> well, docs... need to start on that.  I'll do so after th 5 up there land
19:11:16 <notmyname> #link https://trello.com/b/LlvIFIQs/swift-erasure-codes-and-storage-policies
19:12:14 <notmyname> ok, so keep reviewing, finish up the patches for the last bit of functionality, and we're on track for storage policies in Icehouse. yay!
19:12:21 <zaitcev> I'm pondering if I ought to ask peluse or someone else on EC crew to trade reviews with me. I was sitting on that 47713 since before last Hackathon!
19:12:24 <peluse> rock n roll
19:12:35 <peluse> yup, can do that zaitcev
19:12:40 <notmyname> thanks peluse
19:12:56 <zaitcev> awesome, I always wanted to learn about EC more, too.
19:13:01 <notmyname> #topic EC status
19:13:17 <notmyname> a follow-on to storage policies
19:13:19 <peluse> zaitcev:  the time is coming.... EC has a few small things on gerrit but not up for review yet
19:13:21 <notmyname> peluse: anything here?
19:13:33 <peluse> tushar and keving have been banging on it and should have PUT path ready for review soon.. Tushar?
19:13:48 <tgohad> notmyname: Kevin and I have been finalizing the pyeclib stuff
19:13:54 <notmyname> good
19:14:12 <tgohad> I will have stuff rebased and posted up on geritt first thing next week
19:14:13 <peluse> note:  for everyone that didn't catch it, the EC branch only has policy stuff now and we won't be landing EC work there until policies move to master
19:14:29 <notmyname> good point. thanks for mentioning that
19:14:47 <peluse> yeah, in case folks were looking for ec code on the ec branch, go figure :)
19:15:04 <notmyname> also, when we get storage policies merged into master, I want to do a retrospecitve to see if the long-running feature branch is a good idea for us
19:15:06 <tgohad> zaitcev: if you could review ec/pyeclib discussion on trello, that will be cool
19:15:32 <peluse> sound good
19:15:42 <notmyname> anything else on EC to report?
19:15:54 <zaitcev> tgohad: I have account but do not quite understand how Trello works. I'll look into it today.
19:15:56 <notmyname> peluse: or tgohad?
19:15:56 <tgohad> I have started an rst for EC design
19:16:02 <peluse> don't think so...
19:16:26 <notmyname> k
19:16:39 <peluse> zaitcev:  its just a bunch of semi-organized discussion.  we're not using super wiz bang features
19:16:40 <tgohad> zaitcev: let one of us know if you have issues accessing
19:17:03 <notmyname> any questions on storage policies, EC, or the plans here before we move on? raise your hand so I know you have a question and don't move on too fast
19:17:54 <notmyname> ok, moving on
19:18:03 <notmyname> #topic python-swiftclient port to requests
19:18:13 <notmyname> tristanC has been working on this
19:18:28 <notmyname> the reason has started with wanting to do cert validation
19:18:29 <briancline> what does it use currently?
19:18:32 <zaitcev> What does it mean?
19:18:35 <notmyname> httplib
19:18:55 <notmyname> tristanC: want to give a summary here?
19:19:01 <tristanC> notmyname: yes sure
19:19:02 <dirk> requests is also providing a much nicer (more pythonic) API
19:19:19 <briancline> indeed
19:19:22 <tristanC> as of now, python-swiftclient does not verify ssl certificate, allowing mitm attacks
19:19:36 <notmyname> (also resulting in it being dropped from debian packaging)
19:19:45 <zaitcev> They should've called it something that was obviously a name or symbol. Like bagels. Then you port to bagels.
19:19:57 <tristanC> an attempt have been made to fixes this within current implementation, but the validation wasn't done properly and the patch was not working when actually transfering data
19:20:20 <notmyname> #link https://review.openstack.org/#/c/69187
19:20:56 <tristanC> well, most openstack client are now using requests for http[s] requests, so here is the port to requests ^
19:21:24 <chmouel> tristanC: can you list the current issues iwth ssl and 100 expect?
19:21:25 <notmyname> so there are 2 downsides to using requests. tristanC can you go over them? (ssl compression and 100-continue)
19:21:31 <zaitcev> okay... I guess I'll review after the policies then
19:21:50 <tristanC> yes, as explain on the swift agenda wiki page, there are two remaining issue
19:22:19 <tristanC> First, ssl_compression. It isn't controllable anymore, as it should be disabled by default
19:22:31 <notmyname> and so it's always disabled now?
19:22:33 <zaitcev> How can SSL compression be a "downside" when any expert you ask says just disable it and forget it ever existed. Bah, done.
19:22:56 <notmyname> zaitcev: right. just a change from existing swiftclient behavior
19:23:12 <notmyname> I think this issue should be noted, but isn't too concerning, from what I know of it
19:23:19 <tristanC> notmyname: not always sadly, old system like debian 7 does compress ssl traffic
19:23:42 <dirk> tristanC: any system that has security updates installed from < 1 year ago should have ssl compression disabled
19:23:53 <tristanC> dirk: correct
19:23:56 <notmyname> tristanC: ah, so you get whatever the underlying system does?
19:24:07 <torgomatic> "to disable SSL compression, please switch to a completely different operating system"  <-- fun times
19:24:23 <tristanC> notmyname: as I said, ssl_compression is not controllable with requests as of now
19:24:31 * torgomatic actually isn't too worried about it
19:24:53 <notmyname> ok, so we lose functionality on older systems by moving to requests wrt ssl compression
19:25:10 <torgomatic> cert validation >> toggling SSL compression IMO
19:25:22 <briancline> debian 7 old?
19:26:16 <notmyname> does anything think this ssl compression issues is a showstopper for the port to requests?
19:26:45 <chmouel> maybe the HP guys if they are around since they were the one concerned hte most by the feature
19:26:56 <notmyname> (obviously the official vote there is in gerrit, but I wanted to bring it up here)
19:27:22 <notmyname> chmouel: good point. it would be good to get acoles to look at tit
19:27:25 <notmyname> and it
19:27:43 <briancline> just to be clear -- is requests forcing it to be used? or is it providing the option to whereas that option was not present before?
19:27:45 <notmyname> tristanC: so 100-continue support
19:28:10 <dirk> briancline: requests forces compression to be off all times, as it should be
19:28:12 <chmouel> briancline: the function is only available with python3.2+ version
19:28:17 <acoles> chmouel: notmyname: i'll run it by the relevant hp folks
19:28:22 <notmyname> acoles: thanks
19:28:42 <tristanC> And the second issue, is that requests does not support the "except: 100-continue" header
19:28:50 <notmyname> dirk: well, tristanC said it ends up being on for debian 7
19:29:00 <notmyname> tristanC: that one concerns me a little more
19:29:13 <notmyname> tristanC: isn't there an unadressed issue open with requests to support it?
19:29:25 <torgomatic> is expect-100-continue the sort of thing that we'd get for free later if requests ever did support it, or would we need extra plumbing in swiftclient?
19:30:05 <chmouel> torgomatic: I think we will get for free
19:30:12 <tristanC> notmyname: agree, and the patch that disable ssl_compression once and for all is good to go for python3.2+. For the other version there is solution in pyopenssl contrib module of requests. Though I haven't test this
19:30:24 <notmyname> 100-continue support isn't something we can require clients to use, but it sure would be nice if the official client app actually supported it
19:30:38 <briancline> rather than waiting around for it, perhaps it'd be a good idea to contribute towards it to make it happen in its rightful place (requests)
19:30:49 <tristanC> torgomatic: current implementation of httplib in swiftclient does not do any plumbing (as the 100-continue is controlled by requests header)
19:30:52 <notmyname> briancline: thanks for doing that ;-)
19:31:26 <notmyname> briancline: but yes, I agree :-)
19:31:33 <torgomatic> as long as we don't end up with some annoying compatibility shim for old/new versions of requests, that's okay by me
19:31:41 <zaitcev> I'll have to read on this more, I have no clue what we're talking about. It was my view that 100-continue was absolutely essential for PUT, because otherwise errors cannot be sanely reported. So it's very amazing that any HTTP library would not support it.
19:31:51 <chmouel> #link https://github.com/mikeal/request/issues/611
19:32:10 <notmyname> so same question on this point: does anyone see lack of support for 100-continue in requests is a showstopper for porting swiftclient to use requests?
19:32:11 <chmouel> or maybe that's not the one
19:32:27 <chmouel> #link https://github.com/kennethreitz/requests/issues/713
19:32:39 <chmouel> the good link ^
19:32:52 <notmyname> zaitcev: it allows early failure, so yes it's very important for sane clients to use when they are uploading lots of data
19:32:57 <tristanC> zaitcev: 100-continue purpose is to avoid sending the full body before having an error.
19:33:19 <zaitcev> notmyname, tristanC: exactly my recollection too
19:34:32 <notmyname> to me it's kinda like the boto default that was reported today (a default makes a bunch of extra requests to S3, resulting in higher bills). I'd like our client to do the Right Thing (tm)
19:35:06 <notmyname> tristanC: thanks for bringing these up
19:35:24 <tristanC> notmyname: you're very welcome
19:35:25 <notmyname> any more questions or discussions for this meeting on porting python-swiftclient to use the reuqests library?
19:35:37 <portante> notmyname: FWIWs, going forward with requests seems sane to me
19:35:50 <portante> we work on contributing 100-Continue to requests for the future
19:35:51 <chmouel> portante: +1
19:36:05 <notmyname> I agree
19:36:09 <zaitcev> "We" being Tristan or...?
19:36:28 <notmyname> zaitcev: briancline volunteered I think ;-)
19:36:38 <portante> zaitcev: yes, the royal "we" of folks concerned about swift who want a client that uses 100-Continue
19:37:11 <portante> briancline: I would be willing to review the work on requests to get that 100-Continue support in, and/or help you as you see fit.
19:37:35 <notmyname> actually briancline was just the unlucky one to mention doing a patch upstream first
19:37:45 <notmyname> creiht: around for py3 discussion?
19:37:53 * portante continues to push him forward ...
19:38:04 <notmyname> #topic python3 ins wift
19:38:10 <notmyname> #topic python3 in swift
19:38:29 <notmyname> lots of talk here in the larger openstack community
19:39:03 <notmyname> we've held off on py3 support in swiftclient so far, but I think that would be the first place to support it
19:39:05 <portante> is a switch to asyncio (aka tulip the only game in town)?
19:39:24 * portante put the last paren in the wrong place
19:39:35 <zaitcev> I switched a couple of simple apps to py3 in order to warm up. Seemed like painless enough -- unless you want to support 2.6 too. Then it's try:-expect: all over the place.
19:39:55 <torgomatic> gevent is supposedly working on py3 compatibility, and it started life as a fork of eventlet, so that'd probably be our best bet for easy porting
19:39:56 <chmouel> portante: for python3? no there is gevents supporting it
19:40:12 <torgomatic> AFAIK eventlet has made no moves toward py3 at all
19:40:27 * portante in favor of gevent w py3
19:40:35 <notmyname> "eventlet has made no moves" FTFY
19:40:38 <zaitcev> Yeah, I had to drop eventlet for py3 and use the stock httpd. Swift can't do that though.
19:40:57 <portante> unless of, course we move to jython and just use os threads directly. :)
19:41:16 <chmouel> portante:  recipe for success
19:41:22 <portante> =)
19:41:28 <zaitcev> threads are not enough, we use the webserver parts of eventlet.
19:41:36 <notmyname> I remember creiht or redbo had reasons for not using gevent because of something that it didn't do. I don't remember the details (and it doesn't seem like they are here to help
19:42:02 <chmouel> I think swiftclient is  the one we shoudl start focus
19:42:03 <briancline> portante: zaitcev: notmyname: I can jump in on that upstream contribution as well, just gotta see what the state of their current issue on it is
19:42:09 <notmyname> chmouel: agreed
19:42:14 <torgomatic> chmouel: agreed
19:42:16 <chmouel> cschwede_: do you know what's the status of removing the dependences from swiftclient on swift
19:42:22 <portante> notmyname: the advantage of gevent in my mind is that we can switch to it on py2 and work out the quirks without the py3 changes as well
19:42:46 <notmyname> portante: ya. because distros and install base we'll have to support py2 for quite a while
19:42:54 <clayg> notmyname: gevent used to be libevent (which wasn't thread safe and we like threadpools)
19:43:06 <cschwede_> dependencies on swiftclient: i think it's ready for review: https://review.openstack.org/#/c/65660/
19:43:06 <clayg> gevent is now libev which is threadsafe and should be all freaking gravy
19:43:07 <portante> it is now libev based, I belive
19:43:17 <notmyname> clayg: cool!
19:43:38 <torgomatic> sounds good to me; so once gevent actually has py3 support finished, we port swiftclient and see how it goes?
19:43:39 <portante> swifterdarrell: what are your experiences with gevent and ssbench?
19:43:44 <notmyname> I'd love to see a tech session on this, in depth, in Atlanta
19:44:26 <chmouel> The zen of the gevents
19:44:26 <notmyname> torgomatic: and get cschwede_'s patch merged :-)
19:44:55 <notmyname> ok, timecheck, let's keep moving on. just a little more to discuss
19:44:57 <briancline> I do love gravy
19:45:05 <portante> is it worth switching to gevent ahead of py3?
19:45:16 <notmyname> #topic moving bin/ to swift/cli/ for testing goodness
19:45:32 <notmyname> cschwede_: you're in progress here
19:45:32 * portante is in favor of bin to cli
19:45:35 <cschwede_> the recently landed patch to test swift-recon moved bin/swift-recon to swift/cli/recon
19:45:36 <cschwede_> I want to add more tests for scripts in bin/* and thus move more scripts to swift/cli/recon
19:45:37 <cschwede_> two questions popped up doing this:
19:45:38 <cschwede_> 1. should i just submit a single patch for moving all the scripts from bin/ to swift/cli/recon (should be easy to review) or move each script separately when adding a test? the first one would clean up everything and things would not be scattered all around
19:45:39 <cschwede_> 2. when testing scripts, should I only test functionality or also output from print statements? testing print output requires redirecting sys.stdout and somehow this doesn't feel correct to me.
19:45:57 * portante thinks cschwede_ can type pretty darn fast
19:46:01 <notmyname> heh
19:46:04 <portante> =)
19:46:12 <clayg> maybe he had that like pasted up and ready before hand?
19:46:16 <chmouel> cschwede_ is all the time ready
19:46:18 <torgomatic> I'd rather see one thing at a time; if there's some 4000-line patch that moves everything, I'm gonna go find something else to review
19:46:33 <torgomatic> there's not enough coffee in the world for that
19:46:37 <chmouel> +1
19:46:47 <chmouel> very large patch tend to sit around forever in the Q
19:47:06 <notmyname> cschwede_: there you go :-)
19:47:17 <cschwede_> ok, so I'll will only move things when adding a test for it.
19:47:32 <clayg> cschwede_: I don't think anything wrong with with getstdio(): do_stuff() assertEqual(mockio, expected)
19:48:05 <clayg> cschwede_: so as you move them are you moving them from setuptools scripts to entry_scripts (or whatever it's called?)
19:48:10 <torgomatic> sounds good; and if not everything moves (like bin/swift-object-server is maybe 2 LoC), then that doesn't bother me personally
19:48:43 <clayg> does anyone have a link to the recent recon change that got merged?
19:48:45 <cschwede_> clayg: yes, adding it to console_scripts
19:48:52 <clayg> cschwede_: yeah that's the business!
19:48:56 <notmyname> cschwede_: thanks for tacking that task. those things have languished with no tests for too long
19:48:57 <cschwede_> https://review.openstack.org/#/c/62584/
19:49:14 <torgomatic> https://github.com/openstack/swift/commit/cd4b4da8b6362e6621602a8b815bbeeea2000ff7
19:49:19 <notmyname> ok, quickly moving on. I think we have a direction here
19:49:28 <cschwede_> thanks everyone!
19:49:34 <notmyname> #topic hacking
19:49:38 <notmyname> dirk: you
19:49:44 <notmyname> (this should be fast I think)
19:49:46 <dirk> so the two sentence summary is..
19:49:54 <dirk> https://review.openstack.org/#/c/44757/
19:49:59 <notmyname> you've had a patch for about 2 years now? ;-
19:50:03 <notmyname> ;-)
19:50:04 <dirk> I sent this review about 4 months ago, then nothing happened
19:50:19 <dirk> then I noticed that meanwhile apparently there was a decision to opt-in only
19:50:25 <notmyname> ya
19:50:31 <dirk> regarding hacking warnings and somebody mentioned that I should bring up the topic in the meeting here
19:50:34 <dirk> so here it is :-)
19:50:44 <dirk> I think opt-out is overall the consensus in the wider range of openstack projects
19:51:08 <notmyname> turns out there isn't really a consensus, and there is strong support for the opt-in method
19:51:12 <dirk> it might make sense for swift to go the same route as well. if there are new warnings that are bothering gating, they can be blacklisted until they can be resolved
19:51:18 <notmyname> based on in-person conversations I've had recently
19:51:32 * torgomatic likes the opt-in idea
19:51:38 <notmyname> I much prefer opt-in. I think it's much more sustainable
19:52:04 <zaitcev> How do we know if new cool tests come about?
19:52:06 <chmouel> I prefer the opt-in too, some of the new rules are just weird (the dot in the commit message??)
19:52:13 <clayg> but what if the add a "no bugs" hacking check and we forget to turn it on!?
19:52:15 <dirk> those can be opted out
19:52:31 <dirk> hacking is being release-managed pretty strictly
19:52:34 <zaitcev> You know in Fedora we ruled that oneliners (such as RPM summary) MUST NOT end with a period.
19:52:36 <briancline> no worries, we write bug-free code
19:52:42 <dirk> new hacking checks are only introduced once per cycle
19:52:58 <dirk> in a new minor release. patch level releases fixe bugs but do not add new checks
19:53:03 <notmyname> dirk: then we'll only have to check them once per cycle to see if we want new ones ;-)
19:53:05 <torgomatic> just because someone else decides that they don't like backslashes for line continuations doesn't mean it needs to be "resolved" in Swift, IMO
19:53:18 <chmouel> torgomatic: +1
19:53:21 <torgomatic> but I'm happy to have automated checking of things that I care about
19:53:37 <clayg> wait, so some projects summary line DO end in a period?
19:53:38 <dirk> notmyname: or check only once per cycle which ones should be blacklisted
19:53:39 <torgomatic> hence my preference for use hacking, opt in to checks one at a time
19:53:49 <notmyname> ok, ruling from the bench: we stick with opt-in for now
19:53:59 <torgomatic> and this is why we have a single leader :)
19:54:00 <zaitcev> yay
19:54:09 <torgomatic> instead of a Project Technical Committee
19:54:19 <briancline> aw
19:54:22 <notmyname> #topic helpful gerrit queries (ie lets reduce the review queue)
19:54:31 <notmyname> torgomatic: you have some nice stuff here
19:54:31 <torgomatic> #link https://gist.github.com/smerritt/8795447
19:54:49 <torgomatic> basically, looking through the list of pending stuff sucks because it's huge
19:54:54 <torgomatic> these queries let me narrow things down
19:55:07 <notmyname> I like the last one especially (patches with no core review yet)
19:55:12 <torgomatic> and I can star reviews that I want to keep things moving on, and then find them easily later
19:55:35 <torgomatic> that's about it; they're all pretty self-explanatory. Gerrit searches are pretty easy to read.
19:55:45 <clayg> torgomatic: but those all say "torogomatic"
19:56:01 <portante> that is his way of getting others to work for him
19:56:05 <torgomatic> clayg: yeah, our Gerrit is too old to support the magic "self" user that just references whoever uses it
19:56:15 <portante> we get his review queue down and then he can have a coffee
19:56:24 <notmyname> generalizing these helpful links....
19:56:26 <torgomatic> so s/torgomatic/$me/g and be happy :)
19:56:35 <torgomatic> that's all I have on this
19:56:39 <clayg> torgomatic: I think that breaks the last one
19:56:43 <portante> torgomatic: thanks
19:56:46 <notmyname> it turns out that patches seem to languish if they don't have a "core sponsor". I'm not saying that's good or bad, and we don't have time to go into depth now. but it's something that we should identify and either embrace or fix
19:57:19 <portante> I'd be happy to be a patch core sponsor
19:57:27 <chmouel> by the way i have a generated rss of reviews here http://rss.chmouel/swift.xml
19:57:33 <notmyname> but in the mean tim, using some of torgomatic's links will help with finding thing to review in order to reduce the review queue
19:57:37 <chmouel> (served from swift)
19:57:51 <briancline> +1 for fixing. are there just not enough hours in the day for current core reviewers?
19:57:55 <notmyname> chmouel: I don't have a .chmouel TLD
19:57:57 <portante> so how many core devs do we have?
19:58:01 <cschwede_> chmouel: http://rss.chmouel.com/swift.xml
19:58:06 <chmouel> yeah sorry :)
19:58:13 <clayg> hehehe
19:58:15 <chmouel> but that's on my todo list (the TLD)
19:58:28 <notmyname> portante: 12 cores
19:58:30 <clayg> I think there'd be enough time if every swift core did reviews full time :P
19:58:49 <clayg> i haven't done any reviews *this week*
19:58:49 <portante> clayg: that is what I am afraid of, right now
19:58:58 <notmyname> I'd like to see a target of one review per day per core
19:59:12 <clayg> can I just pick the one at the end of the list and -1 it
19:59:15 <notmyname> but not all reviews take the same time, so that's not simple to apply
19:59:16 <peluse> core reviewers need hypethreading
19:59:16 <chmouel> i don't think all swift core are active
19:59:33 * torgomatic mostly just sits there
19:59:33 * clayg waves to redbo
19:59:39 <portante> notmyname: the priority review queue might be good to have a core sponsor assigned
19:59:41 <notmyname> http://russellbryant.net/openstack-stats/swift-reviewers-60.txt
19:59:47 <notmyname> portante: that's a good idea
20:00:10 <clayg> portante: does stuff get on that list w/o some core at least like... idk sorta already keeping an eye on it?
20:00:12 <notmyname> unfortunately we're out of time
20:00:14 <chmouel> there is the swiftclient ones too as well
20:00:24 <notmyname> chmouel: ya
20:00:35 <notmyname> but this is something that we as a group need to be thinking about
20:00:45 <notmyname> thank you everyone for attending and participating today
20:00:48 <notmyname> #endmeeting