21:00:46 <notmyname> #startmeeting swift
21:00:46 <openstack> Meeting started Wed Feb 24 21:00:46 2016 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:51 <openstack> The meeting name has been set to 'swift'
21:00:55 <notmyname> who's here for the swift team meeting?
21:00:58 <siva_krishnan> o/
21:01:02 <torgomatic> .
21:01:05 <gmmaha> o/
21:01:05 <m_kazuhiro> o/
21:01:06 <ho_away> o/
21:01:08 <Zyric_> Hi
21:01:10 <dmorita> o/
21:01:12 <sgundur> hi
21:01:12 <takashi> o/
21:01:17 * onovy 
21:01:17 <kota_> hi
21:01:22 <tdasilva> hello
21:01:29 <ntata> o/
21:01:39 <joeljwright> hello
21:01:40 <cutforth> o/
21:01:41 <skraynev_> notmyname: np ;)
21:01:54 <notmyname> welcome, everyone
21:02:02 <acoles> here
21:02:04 <notmyname> acoles: mattoliverau: cschwede: ?
21:02:08 <notmyname> acoles: :-)
21:02:12 <mattoliverau> o/
21:02:48 <notmyname> thanks for coming. agenda is at
21:02:50 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
21:03:21 <notmyname> sorry, just saw clayg going into a meeting...
21:03:26 <notmyname> a different meeting!
21:03:35 <notmyname> ok, first up...hackathon!
21:03:40 <notmyname> #topic hackathon
21:03:43 <jrichli> o/
21:03:44 <notmyname> it's next week
21:03:50 <notmyname> #link https://etherpad.openstack.org/p/swift-hackathon-feb-2016
21:04:04 <notmyname> also, FWIW, no team meeting in here next week, in lieu of the hackathon
21:04:21 <notmyname> I hope everyone has all their travel logistics figured out
21:04:25 <notmyname> if not, good luck
21:04:52 <notmyname> there's a ton of great topics on the etherpad. please continue to update that. we'll use it as a starting point for our discussions next week
21:05:03 <notmyname> acoles: anything to share that we need to know about logistics?
21:05:08 <notmyname> (wear a coat)
21:05:15 <acoles> yes, that ^^
21:05:37 <acoles> look for email I sent earlier today with a few more bits of info
21:05:47 <notmyname> thanks for keeping us informed on that
21:05:52 <acoles> including my mobile number in case anyone needs that
21:05:54 <notmyname> are there any questions from anyone about the hackathon?
21:07:27 <notmyname> ok. that's easy, then :-)
21:07:33 <acoles> phew
21:07:35 <notmyname> next up...
21:07:47 <notmyname> #topic reviewer stats and community-starred patches
21:08:11 <notmyname> if you haven't seen already, http://not.mn/swift/swift_community_dashboard.html is something that I've made and has had some success and usefulness to people already
21:08:13 <notmyname> #link http://not.mn/swift/swift_community_dashboard.html
21:08:32 <notmyname> 3 areas on it. I'll sumarize quickly
21:08:56 <notmyname> review stats measures the time it takes for a patch author to respond to a reviewer and a reviewer to respond to an author
21:08:59 <kota_> cool
21:09:16 <notmyname> current reported time is the mean. if I can find a better metric, I may switch to that
21:09:58 <notmyname> my goal is to keep "reviewers" winning. ie responding faster that patch authors. that means that any review holdup is on authors and not reviewers. the goal is to lower overall time a patch spends in review
21:10:06 <notmyname> second section is the community starred patches
21:10:20 <notmyname> that's the top 20 patches that are starred by the community
21:11:11 <notmyname> basically, if you've ever made any gerrit comment on any swift patch, I'll pull down whatever patches you currently have starred. then weight your star by your level of involvement in swift (active = higher score). then sum up to totals for each starred patch and take the top 20
21:11:26 <notmyname> the idea is that these are likely to be the patches that are most important to people in the community
21:12:01 <notmyname> my goal here is to encourage reviews on important things. I think this is slightly better than "the PTL has starred this, so I'll review it"
21:12:15 <notmyname> it lets us all vote on what's important to swift
21:12:54 <notmyname> the third section is a list of patches that have had zero comments from any reviewer, listed oldest first
21:13:00 <notmyname> the goal is to have this list be empty
21:13:23 <notmyname> any questions on it for now?
21:13:30 <notmyname> it's linked in the -swift channel topic, too
21:13:32 <mattoliverau> great idea, looking great
21:14:00 <ho_away> i would like to know the meaning of color.
21:14:32 <notmyname> no meaning. the only color rules are for visited and unvisited links
21:14:53 <ho_away> i see. thanks
21:14:55 <jrichli> thanks for all your work - great idea
21:15:15 <notmyname> I resurrected the stylesheet from a personal project I worked on probably 7 or 8 years ago. in related news, I no longer love CSS. CSS is evil ;-)
21:15:44 <notmyname> also, if you happen to love CSS and have a good eye for design, I've got some stuff you can work on ;-)
21:16:49 <kota_> so third list looks sorted according to the date *last updated*, is it in your intention?
21:17:21 <notmyname> kota_: number 1 in the unreviewed patches should be the one that's been the longest without any comment or activity.
21:17:43 <notmyname> the data is coming from gerrit, whcih only sorts by last activity. I pull it down and pass it through reversed(). that's it
21:18:04 <notmyname> the idea is that the top of that list will be stuff that's languished the longest without comments
21:18:05 <joeljwright> notmyname: is swiftclient included here?
21:18:05 <kota_> i thought *listed oldest first* you said means oldest orderd the date of initial commit, maybe i was wrong, though :P
21:18:20 <joeljwright> I realise it's never going to make the list even if it is :(
21:18:29 <notmyname> joeljwright: no. swiftclient is not yet included. I've got some integration with that staged, but it's not complete yet
21:18:39 <kota_> make sense.
21:19:00 <joeljwright> cool, thanks
21:19:06 <notmyname> joeljwright: I definitely want to have swiftclient included. it will not get left out
21:19:24 <joeljwright> what I meant was due to the weighting it probably needs to be separated
21:19:30 <notmyname> the hardest part there will be the starred patches, actually. I've already got the review timings and unreviewed list done
21:20:11 <notmyname> FWIW, this is all tightly integrated with the same scripts that generate those graphs I've talked about before
21:20:18 <notmyname> acoles: cue eye rolling ;-)
21:20:24 <joeljwright> yay! graphs!
21:20:49 <acoles> i'm wondering how we could monitor whether a review that falls of the top 20 starred list has done so because it was merged, people removed stars, or it just got overtaken in time as more reviewers add more stars?
21:21:00 <acoles> notmyname: you have to forgive and forget!)
21:21:05 <notmyname> lol
21:21:07 <torgomatic> starflation
21:21:50 <notmyname> it's all a work in progress :-)
21:22:10 <joeljwright> acoles: we need top of the pops style rank changes shown on each update
21:22:37 * acoles imagines it like the music charts "last week's number 2 drops to number 7"
21:22:47 <acoles> joeljwright: right, that!)
21:22:52 <tdasilva> acoles: lol
21:23:02 <notmyname> hello patchbot
21:23:19 <notmyname> ok, let's move on to talk about actual code stuff instead of all this meta-swift stuff ;-)
21:23:31 <notmyname> #topic auditors don't finish bug
21:23:38 <notmyname> https://bugs.launchpad.net/swift/+bug/1183656
21:23:38 <openstack> Launchpad bug 1183656 in OpenStack Object Storage (swift) "object auditors don't finish" [Critical,In progress] - Assigned to Christian Schwede (cschwede)
21:23:45 <notmyname> patch 279440
21:23:46 <patchbot> notmyname: https://review.openstack.org/#/c/279440/ - swift - Skip already checked partitions when auditing obje...
21:23:47 <mattoliverau> notmyname, maybe I should borrow your CSS for the abandoner.. It uses none
21:24:05 <notmyname> cschwede: here?
21:24:15 <notmyname> what's the status of this patch and closing this bug?
21:24:57 <notmyname> mattoliverau: you left a review last week saying you had "a bit more to do". have you had a chance to do those things yet?
21:25:50 <mattoliverau> Yeah a little, been testing it, seems to be working, want to play/stress it a little more, will update later today
21:26:06 <notmyname> ok, thanks
21:26:25 <mattoliverau> I left a question for cschwede there too
21:26:36 <mattoliverau> But will chase it up today :)
21:26:42 <notmyname> since this is a critical bug that will block any release, I'd like to have another core added as a reviewer who is looking at it too. any volunteers?
21:27:03 <kota_> yup
21:27:27 <kota_> add in my task list to do today.
21:27:30 <notmyname> kota_: thanks
21:27:50 <Zyric_> On a related note, torgomatic and patch 212824?
21:27:51 <patchbot> Zyric_: https://review.openstack.org/#/c/212824/ - swift - Let developers/operators add watchers to object audit
21:27:53 <notmyname> ideally, I'd love to see that land this week so we can roll a release next week
21:28:09 <notmyname> Zyric_: we'll get there in a bit :-)
21:28:15 <Zyric_> Cool :)
21:28:17 <onovy> oh, next release? last mitaka release?
21:28:41 <notmyname> onovy: perhaps. but maybe we can squeeze in two more. a bigger one and then a minor one
21:28:58 <notmyname> next week I want to look at the timings with everyone to see what's reasonable
21:29:01 <onovy> because i have one big think which i want to land before mitaka release :)
21:29:11 <onovy> *thing
21:29:17 <notmyname> ok, let's get to that in a bit
21:29:28 <notmyname> moving down the agenda wiki...
21:29:36 <notmyname> #topic copy middleware ready for review
21:29:48 <notmyname> tdasilva: you added this. is this for awareness or for a particular question
21:29:54 <notmyname> ?
21:29:58 <tdasilva> just awareness
21:30:02 <notmyname> ok
21:30:07 <tdasilva> first two patches there already have one +2
21:30:13 <tdasilva> and are simpler to review
21:30:19 <notmyname> patch 260179 patch 263902 patch 156923
21:30:20 <patchbot> notmyname: https://review.openstack.org/#/c/260179/ - swift - decouple versioned writes from COPY
21:30:21 <patchbot> notmyname: https://review.openstack.org/#/c/263902/ - swift - Re-format the SLO manifest file on new multipart-m...
21:30:22 <patchbot> notmyname: https://review.openstack.org/#/c/156923/ - swift - Refactor server side copy as middleware
21:30:26 <tdasilva> then the 3rd is copy middleware itself which is also ready for review
21:30:35 <notmyname> thank you for working on it
21:30:51 <tdasilva> thanks to acoles, jrichli, ppai
21:30:57 <acoles> note we now have in these patches copy middleware to the left of dlo/slo and copy_hooks are gone
21:30:58 <notmyname> yes. absolutely
21:31:03 <notmyname> gool!
21:31:08 <notmyname> also, *cool
21:31:20 <acoles> goal!
21:31:21 <kota_> wow
21:31:33 <jrichli> yay
21:31:36 <notmyname> and it also removes a blocker for crypto work, right?
21:31:40 <tdasilva> it was a team goal!
21:31:41 <mattoliverau> I'll keep my eye in that one too (once back from doctors)
21:31:46 <jrichli> yes!  thanks everyone
21:31:53 <acoles> yes this is a blocker for crypto
21:32:01 <notmyname> ok
21:32:10 <notmyname> I suspect we'll be looking at these next week :-)
21:32:26 <jrichli> i already added it as a topic on the etherpad ;-)
21:32:26 <tdasilva> :)
21:32:59 <notmyname> #topic swiftclient logging issue
21:33:05 <notmyname> patch 282363
21:33:05 <patchbot> notmyname: https://review.openstack.org/#/c/282363/ - python-swiftclient - Do not reveal auth token in swiftclient log messag...
21:33:18 <notmyname> this one is a critical issue blocking a swiftclient release
21:33:34 <notmyname> thanks joeljwright for grabbing it and getting a good patch set
21:33:55 <joeljwright> we've worked through a few issues on this, so it's certainly ready for other reviews
21:34:21 <notmyname> I'm hoping to look at this one today
21:34:36 <acoles> i'll try to get to it tomorrow
21:34:37 <notmyname> and that should allow for a swiftclient release, too
21:34:39 <notmyname> acoles: thanks
21:34:57 <joeljwright> one question I did want to ask
21:35:02 <notmyname> yeah, what's up?
21:35:07 <joeljwright> do we need to backport this for 2.7
21:35:18 <joeljwright> the current code is not py26 compatible
21:35:27 <joeljwright> and neither are the tests in general now
21:36:12 <notmyname> we've never backported anything for swiftclient before. and the way the release have changed, now that's possible, I suppose
21:36:16 <joeljwright> we're only just announcing no more py26
21:36:27 <joeljwright> and leaving them with a critical issue
21:36:37 <notmyname> joeljwright: how much work is the backport from your perspective?
21:36:38 <joeljwright> was just a thought
21:36:45 <joeljwright> nothing much
21:36:57 <joeljwright> I used a dict comprehension because I could, so it's a trivial change
21:37:03 <notmyname> if there's a patch, I'm happy to backport it
21:37:20 <notmyname> I'm glad you mentioned somethng about that. reminded me of a skipped topic
21:37:26 <joeljwright> but I don't know how to make a patch for a previous release
21:37:48 <notmyname> joeljwright: instead of branching off of master, branch off of stable/<whatever>
21:37:51 <acoles> joeljwright: i can help
21:37:55 <notmyname> thanks acoles
21:37:59 <joeljwright> acoles: thanks
21:38:04 <notmyname> #topic swiftclient docs
21:38:31 <notmyname> you may have noticed that our official in-tree docs, as presented on the openstack site, are rather terrible
21:38:33 <notmyname> #link http://docs.openstack.org/developer/python-swiftclient/
21:38:43 <notmyname> just yesterday I found out why
21:39:11 <notmyname> for client projects, those docs are only rebuilt and republished for every release
21:39:19 <notmyname> for the server projects, it's done every commit (see http://docs.openstack.org/developer/swift/)
21:39:43 <joeljwright> that would explain all the MIA docs
21:39:45 <notmyname> we've landed several good changes for swiftclient docs already. and there are several more proposed
21:39:47 <notmyname> joeljwright: right
21:40:02 <notmyname> so we can choose to do either the per release docs or the per commit docs
21:40:06 <notmyname> that's the choice before us
21:40:09 <notmyname> what do you think?
21:40:21 <joeljwright> per release does seem to make more sense for clients
21:40:22 <tdasilva> pros and cons?
21:40:31 <joeljwright> once we have decent docs
21:40:55 <notmyname> joeljwright: I'm not sure I understand that. why is per-release better for a client?
21:41:02 <tdasilva> I guess I don't see the difference...
21:41:08 <jrichli> they might not always update if there isnt a new release
21:41:10 <mattoliverau> People will be using the docs assuming it works for the latest stable.. So kinda makes sense
21:41:11 <notmyname> IMO per-commit is better because docs changes will get to users faster
21:41:17 <joeljwright> well, changes in behaviour reflected before release might be confusing
21:41:33 <acoles> notmyname: if we go per-commit, is there a url to use for the docs for a specific version?
21:41:35 <mattoliverau> Tho having the ability to update docs without having to cut a release is a big win
21:41:44 <joeljwright> yeah, true
21:41:48 <jrichli> acoles: my question too
21:41:54 <notmyname> one idea I've heard is to have what acoles just said. soemthing for 2.7, 2.6, 2.X, etc
21:42:16 <tdasilva> but then, shouldn't we do that for swift also?
21:42:55 <joeljwright> it's a difficult question though - adding generally applicable updates to lots of places is a pain
21:42:58 <notmyname> also, I'm not really concerned with the general case (for a generic client, when is the best time to publish docs). I'm worried about our specific case. do we think per-commit docs will break end users of swiftclient
21:43:38 <joeljwright> hopefully our release cycle will be fast enough not to confuse people
21:43:40 <gmmaha> how does one for latest release and one for commit sound? Two links at the top level?
21:43:52 <joeljwright> the python docs have a nice **introduced in version xx** style
21:44:06 <joeljwright> for new features
21:45:01 <notmyname> #vote what's your initial opinion: should we build docs per release or per commit? per-release, per-commit
21:45:13 * notmyname doesn't know if that works. seems like no
21:45:28 <notmyname> #startvote what's your initial opinion: should we build docs per release or per commit? per-release, per-commit
21:45:28 <openstack> Begin voting on: what's your initial opinion: should we build docs per release or per commit? Valid vote options are per-release, per-commit.
21:45:29 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
21:45:37 <notmyname> quick straw poll
21:45:38 <gmmaha> #vote per-commit
21:45:40 <tdasilva> #vote per-commit
21:45:42 <torgomatic> #vote per-release
21:45:43 <notmyname> #vote per-commit
21:45:44 <mattoliverau> I'm thinking per release makes sense (I guess) but having docs managed 1 way to avoid confusion is better, so I think I'm leaning to per commit.
21:45:54 <acoles> #vote per-release
21:45:55 <jrichli> #vote per-release
21:46:01 <timburke> #vote per-release
21:46:02 <tdasilva> i think swift and swift client should be consistent
21:46:08 <mattoliverau> #vote per-commit
21:46:09 <sarafraj> #vote per-commit
21:46:09 <siva_krishnan> #vote per-commit
21:46:12 <ho_away> #vote per-commit
21:46:12 <onovy> #vote per-commit
21:46:16 <kota_> #vote per-release
21:46:19 <takashi> #vote per-release
21:46:26 <joeljwright> #vote per-release
21:46:27 <Zyric_> #vote per-commit
21:46:40 <notmyname> anyone else?
21:46:51 <notmyname> #endvote
21:46:52 <openstack> Voted on "what's your initial opinion: should we build docs per release or per commit?" Results are
21:46:53 <openstack> per-commit (9): gmmaha, siva_krishnan, notmyname, tdasilva, sarafraj, Zyric_, onovy, ho_away, mattoliverau
21:46:54 <openstack> per-release (7): acoles, takashi, kota_, jrichli, torgomatic, joeljwright, timburke
21:46:59 <notmyname> very interesting
21:47:01 <notmyname> thank you
21:47:15 <notmyname> no agreement for now. we will discuss further
21:47:39 <joeljwright> I'd be fine with per-commit if we had an obvious way of showing features that aren't yet available, and where major new features/changes were made
21:47:59 <notmyname> I'll bring this topic up again. for now, especially if we'll have a swiftclient release soon, it doesn't matter too much
21:48:06 <joeljwright> :)
21:48:12 <torgomatic> it's obnoxious when the docs have .do_what_i_mean() in them, and you want that, but it's only on master and not pypi
21:48:23 <notmyname> #topic auditor watchers
21:48:34 <notmyname> this is stuff torgomatic and Zyric_ are working on
21:48:34 <joeljwright> torgomatic: +1
21:48:42 <torgomatic> yes, watch them. WATCH THEM ALL
21:48:58 <notmyname> also note that Zyric_'s outreachy internship is officially over next monday. (although i hope she will stay involved)
21:49:03 <tdasilva> i don't know...imagine when encryption gets delivered (i'm assuming there will be changes to client too), now if someone is searching on the web about the feature, they will find the docs for the server but not the client
21:49:11 <Zyric_> I will :)
21:49:34 <notmyname> torgomatic: Zyric_: anythign we need to bring up here about the audit watcher patches?
21:50:30 <Zyric_> Previously mentioned patch 279440 was blocking the object watcher getting through, and the object watcher is preventing the account watcher getting though
21:50:30 <patchbot> Zyric_: https://review.openstack.org/#/c/279440/ - swift - Skip already checked partitions when auditing obje...
21:50:55 <torgomatic> I've got a revision I'm working on, but one of my unit tests ends up SIGINT-ing the testrunner somehow (!), and that kills the test run
21:50:57 <torgomatic> so that's bad
21:51:35 <notmyname> wow. that sounds fun
21:51:46 <notmyname> (for me to hear about after you fix it) ;-)
21:51:52 <Zyric_> Indeed that doesn't sound good. Is there any way I can help, or something else that might be useful I could do?
21:52:12 <torgomatic> eh, I'll throw what I've got up there with a SkipTest in it so people can look
21:52:16 <torgomatic> after the meeting, that is
21:52:19 <notmyname> ok, thanks
21:52:25 <Zyric_> Thank you
21:52:34 <notmyname> #topic open discussion
21:52:42 <notmyname> onovy: you mentioned some patches you want in a swift release
21:52:51 <onovy> yep https://review.openstack.org/#/c/238799/
21:52:51 <patchbot> onovy: patch 238799 - swift - Change schedule priority of daemon/server in config
21:53:00 <notmyname> that hasn't landed yet?
21:53:12 <notmyname> bah!
21:53:13 <onovy> no :(
21:53:31 <mattoliverau> New concurrent reads patch is up, just fyi
21:53:50 <notmyname> mattoliverau: great!
21:53:52 <kota_> cool
21:53:56 <mattoliverau> And I almost have the sharding shrink algorithm working (I hope)
21:53:56 <ho_away> i would like to have review for patch 213608
21:53:57 <patchbot> ho_away: https://review.openstack.org/#/c/213608/ - swift - Add functional test for access control (container ...
21:54:00 <notmyname> onovy: I've starred it
21:54:07 <onovy> notmyname: thanks
21:55:02 <torgomatic> if you're gonna review stuff on a plane, merge this https://review.openstack.org/#/c/283828/ since it cuts 3 minutes (ish) off a full test run
21:55:02 <patchbot> torgomatic: patch 283828 - swift - Fix StatsD tests to not use real DNS
21:55:04 <mattoliverau> Turns out shrinking is rather complicated.. I might write a spec on it to get people's opinion
21:55:50 <notmyname> mattoliverau: I'm sortof of the mind that shrinking is v2. (but I haven't thought deeply about it recently)
21:56:16 <awelleck> If anyone can get a chance to review this patch it would be appreciated: https://review.openstack.org/#/c/283815/
21:56:17 <patchbot> awelleck: patch 283815 - python-swiftclient - Query string functionality for containers
21:56:21 <acoles> notmyname: how do we decide what bugs go critical to block a release? or...how do we ensure that non-critical bug fixes eventually make it into a release? we can't star bugs :)
21:56:35 <mattoliverau> notmyname: yeah, I'm OK with that too.. But I'm still going to push ahead :)
21:56:40 <notmyname> acoles: good question, and I don't have an answer other than "we talk about it"
21:57:13 <joeljwright> awelleck: I'll add it to my list, but I may not get to it quickly
21:57:31 <acoles> notmyname: for example https://bugs.launchpad.net/swift/+bug/1540884 IDK if I would argue it is critical but I'd like to see the fix land before mitaka
21:57:31 <openstack> Launchpad bug 1540884 in OpenStack Object Storage (swift) "Object copied by container-sync may have older timestamp than source" [High,In progress] - Assigned to Alistair Coles (alistair-coles)
21:57:44 <awelleck> joeljwright: thanks
21:58:43 <notmyname> acoles: ok
21:58:54 <notmyname> time's up for this week's meeting
21:59:03 <notmyname> no meeting next week (in lieu of the hackathon)
21:59:11 <mattoliverau> :(
21:59:14 <notmyname> thank you for coming today. thank you for working on swift
21:59:17 <notmyname> #endmeeting