18:00:55 <SlickNik> #startmeeting trove
18:00:56 <openstack> Meeting started Wed Feb 18 18:00:55 2015 UTC and is due to finish in 60 minutes.  The chair is SlickNik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:00:59 <openstack> The meeting name has been set to 'trove'
18:01:03 <amrith> ./
18:01:20 <SlickNik> Giving folks a couple of minutes to trickle in.
18:01:43 <georgelorch> o/
18:01:52 <amrith> hello george!
18:02:02 <sushilkm> Hello everyone
18:02:10 <georgelorch> howdy there amrith!
18:02:11 <nshah> o/
18:02:23 <edmondk> o/
18:02:44 <SlickNik> Agenda for today's meeting is at:
18:02:46 <SlickNik> #link https://wiki.openstack.org/wiki/Meetings/TroveMeeting#Agenda_for_February_18_2015
18:02:50 <amrith> doing well georgelorch ... we needs to have speaks. I hear we're peddling something in Vancouver. ttyl
18:03:22 <georgelorch> yes sir amrith, voting on the proposals starts very soon
18:03:43 <SlickNik> georgelorch: has already started — ends on Monday.
18:03:54 <sushilkm> Voting is already on :D
18:04:00 <SlickNik> Okay, let's get started.
18:04:07 <SlickNik> #topic Trove pulse update
18:04:21 <SlickNik> #link https://etherpad.openstack.org/p/trove-pulse-update
18:04:47 <SlickNik> So this is a follow up to the discussion we had at the mid-cycle review.
18:05:34 <SlickNik> We decided that we need to measure and keep an eye out on stats around reviews and merged patches — something to measure our momentum going forward.
18:05:47 <SlickNik> So we know when the gate is stalling, when reviews are drying up.
18:06:04 <SlickNik> I've complied statistics for the last week at https://etherpad.openstack.org/p/trove-pulse-update
18:06:39 <sushilkm> is this etherpad gonna be updated every week or so ...
18:06:56 <vkmc> o/
18:07:07 <SlickNik> sushilkm: Yes, the idea is that every meeting we will have a quick 5 minute look at the pulse.
18:07:41 <SlickNik> I'll compile, so that we will be able to look at the numbers over time as well.
18:07:41 <amrith> sushilkm, is kicking butt.
18:07:58 <SlickNik> Thanks to all the folks who did reviews last week!
18:08:06 <sushilkm> it wud be gr8 to preserve the history of the pulse ;)
18:09:02 <edmondk> we have to be careful though when you know you are measuring something every week like this, it can cause people to only care about quantity over quality
18:09:21 <edmondk> that's the problem with statistics based measuring like this
18:09:52 <SlickNik> edmondk: Yes, you need to take the stats with a dose of salt.
18:10:16 <amrith> I propose that we eliminate the per-reviewer stats and only track the total reviews and the overall health metrics. That's what we care about, no?
18:10:27 <sushilkm> apart from measuring quantity of reviews, it has more info over there like no. of patches merged  and no. of changes which are more exciting :)
18:10:39 <amrith> after all, those who care about per rviewer stats can go to stackalytics
18:11:45 <SlickNik> Interesting to note that our average wait times are huge even though our median and 3rd quartile wait times look reasonable.
18:12:00 <SlickNik> What that means is that we have really old changes that are not moving quickly.
18:12:46 <SlickNik> I've been trying to identify those — and either abandon them if folks are not actively working on them, or get them reviewed if they don't have reviews.
18:13:06 <SlickNik> most fall into the former bucket so far — but the effort is ongoing.
18:13:50 <SlickNik> #action SlickNik to look at changes that are really old — and either abandon them if folks are not actively working on them, or review them if they don't have reviews.
18:15:07 <SlickNik> Also credit where credit is due — I used slightly modified scripts that russellb wrote to get the details (you can check them out here https://github.com/openstack-infra/reviewstats)
18:15:50 <SlickNik> Any questions?
18:16:48 <russellb> output here too http://russellbryant.net/openstack-stats/trove-openreviews.html
18:17:15 <SlickNik> Thanks russellb!
18:17:25 <SlickNik> #link http://russellbryant.net/openstack-stats/trove-openreviews.html
18:17:42 <amrith> nice, that gives you the outliers
18:18:03 <edmondk> it would be also interesting to see what the pulse was last month
18:18:15 <edmondk> to see how the new core reviewers have changed the momentum
18:18:29 <russellb> yeah i haven't done anything to track historical data
18:19:26 <sushilkm> things seem to pick up since mid-cycle ... at least on reviews part, which is actually nice ....
18:20:14 <SlickNik> Okay, we've got a fairly full agenda. I can look to see if there's a simple way to get historical data — but let's move on for now.
18:20:22 <SlickNik> sushilkm: agreed.
18:20:39 <SlickNik> #topic Trove related presentations/talks at the Liberty Summit
18:21:11 <SlickNik> So I went through the summit talks and compiled a list of talks that were related to Trove
18:21:13 <SlickNik> #link https://etherpad.openstack.org/p/liberty-summit-trove-talks
18:22:21 <annashen> the deadline for vote?
18:22:22 <SlickNik> I'm planning to spend a chunk of time tomorrow going through all talks and voting for the ones I find interesting.
18:22:45 <sushilkm> looks like the big list  lots of topics
18:23:20 <SlickNik> annashen: I believe the deadline is Monday 23rd, so make sure to get your votes in by then.
18:23:40 <annashen> SlickNik, will do!
18:23:43 <annashen> thanks
18:25:06 <SlickNik> I don't think there's any more to add here. Any questions?
18:26:08 <SlickNik> .
18:26:32 <SlickNik> #topic Trove Liberty Mid Cycle Sprint -- Initial planning for date / location
18:27:03 <SlickNik> Just wanted to give folks a heads up here.
18:28:24 <SlickNik> Was planning into locations for the Liberty Mid cycle sprint — initial planning (so still tentative), but wanted to get a good idea of what dates worked well for folks.
18:28:41 <SlickNik> I've set up a doodle poll for this at http://doodle.com/candscrt36hg38a7
18:28:43 <SlickNik> #link http://doodle.com/candscrt36hg38a7
18:29:24 <SlickNik> The tentative location planned is Sunnyvale, CA.
18:31:09 <peterstac> Will HP be hosting it again?
18:31:24 <SlickNik> #action Please fill out the doodle at http://doodle.com/candscrt36hg38a7 for tentative dates for the Liberty Mid Cycle Sprint.
18:31:56 <SlickNik> peterstac: Yes — getting confirmation on the exact location, etc but that's the plan.
18:32:18 <amrith> SlickNik, thanks for helping with the location
18:32:32 <amrith> Tesora would be happy to help with the hosting
18:32:49 <amrith> After all, peterstac still owes us all a round of drinks.
18:34:18 <dougshelley66> peterstac did buy a round...just that only me and schang were there
18:34:32 <amrith> bah
18:34:47 <SlickNik> Hah, perhaps we could host it jointly then? Just wanted to get an idea of the dates for now so that I can lock in the location.
18:35:04 <SlickNik> We have some time to figure out the details.
18:35:59 <SlickNik> Okay, that's pretty much all I had for this topic — there's still more to cover on the agenda; let's move on.
18:36:25 <SlickNik> #topic Continue discussion of proposal to classify datastores and strategies
18:36:42 <SlickNik> #link https://review.openstack.org/#/c/154119/4
18:36:43 <amrith> sounds like I'm up
18:36:59 <amrith> I pushed up a spec (the link SlickNik just shared)
18:37:09 <amrith> in the last review there were some questions about the actual implementation
18:37:21 <amrith> I proposed one in the latest version of the spec
18:37:54 <amrith> but if people feel that it is too much and the overhead of editing the dozen or so files when we move a datastore/strategy from one place to another isnt too much
18:38:02 <amrith> I can push code for this later today
18:38:08 <amrith> ie. brute force editing of imports
18:38:11 <amrith> and moving the files around
18:38:12 <amrith> not very hard
18:38:21 <amrith> also there is a bit of a wrinkle I hadn't planned for
18:38:31 <amrith> cluster strategies are in trove/common not trove/guestagent
18:38:41 <amrith> so some questions for folks here
18:39:05 <amrith> 1. there aren't too many distinct places where one has to make an edit to move a datastore/strategy from one maturity level to another
18:39:09 <amrith> is brute force editing OK
18:39:22 <amrith> 2. For now MySQL will be the only stable datastore
18:39:35 <amrith> all others will be experimental or technical preview (percona and mariadb)
18:39:50 <amrith> 3. swift and mysql related strategies will be "stable"
18:39:55 <amrith> all others will be experimental.
18:40:08 <amrith> If those are OK, I'll push code this afternoon/tomorrow.
18:41:54 <SlickNik> amrith: I haven't had a chance to review the current incarnation of the spec — I did have some comments on the previous one.
18:42:08 <amrith> SlickNik, I incorporated some text to reflect your comments.
18:42:20 <amrith> but what I'm proposing here pares that spec back even further.
18:42:21 <SlickNik> For 1. I know you were talking to the oslo folks — what are our alternatives?
18:42:54 <amrith> the only option they had was stevedore
18:43:00 <amrith> and that doesn't really help us much
18:43:02 <SlickNik> 2. sounds reasonable to me and seems in line with the discussion that we had at the mid-cycle.
18:43:31 <amrith> the reason is that we do imports (which stevedore will help with) but we also have the use of things in configuration options
18:43:37 <amrith> and things like that
18:43:42 <amrith> which stevedore is useless for.
18:43:49 <SlickNik> 3. builds on making strategies stable / experimental — that's not something that was discussed before, so hopefully folks can chime in on that.
18:43:56 <amrith> furthermore, we already have something (like stevedore) in terms of how we load strategies.
18:44:19 <amrith> hence the proposal to just brute force the edits
18:44:22 <amrith> isn't too painful
18:44:28 <amrith> we agree on #2 and #3
18:45:53 <SlickNik> Amrith: stevedore won't currently work for the guest since it doesn't install any entry points, and having those is a pre-req for stevedore.
18:46:41 <amrith> SlickNik, that takes care of that option.
18:46:57 <SlickNik> IMO: 3 is a good step in the right direction. Having the same test standard for strategies as well seems to make sense.
18:47:19 <SlickNik> Will put up my comments in the review.
18:47:38 <SlickNik> Anything else wrt this?
18:47:40 <amrith> should I revise the review and just document the brute-force naming?
18:49:29 <SlickNik> Yes, I think that's a good idea.
18:49:34 <amrith> ok, done
18:49:37 <amrith> I'm all set for now.
18:49:39 <amrith> thanks!
18:49:43 <SlickNik> Thank you!
18:49:49 <SlickNik> #topic Open DIscussion
18:50:24 <SlickNik> Any items for open discussion?
18:51:05 <vkmc> regarding reviews... the first item in the agenda
18:51:20 <vkmc> I was looking for this http://status.openstack.org/reviews/
18:51:25 <vkmc> checkout trove branch reviews
18:51:52 <vkmc> there we have a 'Score' value we could use to prioritize reviews
18:52:05 <vkmc> (sorry I just brought it up, I couldn't find it earlier)
18:52:55 <SlickNik> vkmc: Good point
18:53:02 <SlickNik> #link http://status.openstack.org/reviews/
18:54:10 <vkmc> that's all from me :)
18:54:18 <edmondk> where does the score come from
18:54:31 <dougshelley66> vkmc, that score heavily waits things just because they are old
18:54:37 <dougshelley66> don't know if that always implies priority
18:55:18 <SlickNik> I think this has come up before. One of the things that was mentioned was that it doesn't seem to factor in that a review might be waiting on an update from the author — you'll see a lot of reviews that have -1 from multiple people that are high on that list because they are old.
18:55:23 <sushilkm> it looks its a combination of priority and oldness
18:55:26 <vkmc> dougshelley66, yeah, that's true generally
18:55:50 <SlickNik> But you could choose to add that to your personal filter.
18:56:18 <SlickNik> Unfortunately, I don't think there's a silver bullet here.
18:56:45 <SlickNik> The important part is that we actually do (more) reviews.
18:57:03 <vkmc> yeah.. there are many patches that are stalled because there is no activity from the contributor side
18:57:38 * SlickNik gets off soapbox
18:57:45 <edmondk> Is there still a gate break with gate-tempest-dsvm-neutron-src-python-troveclient-juno ?
18:57:51 <edmondk> that seems to be affecting some reviews on troveclient
18:57:55 <amrith> edmondk, yes
18:57:58 <edmondk> been broken for like a week
18:58:00 <amrith> it is still broken
18:58:31 <SlickNik> edmondk: Yes — is someone currently looking into that?
18:59:16 <iccha> X019: around?
18:59:21 <SlickNik> We're out of time. Let's take this conversation to #openstack-trove
18:59:26 <SlickNik> #endmeeting