21:00:03 #startmeeting swift 21:00:04 Meeting started Wed May 30 21:00:03 2018 UTC and is due to finish in 60 minutes. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:08 The meeting name has been set to 'swift' 21:00:10 who's here for the swift team meeting? 21:00:11 o/ 21:00:12 o/ 21:00:17 o/ 21:00:23 good morning 21:00:28 o/ 21:00:47 hi 21:00:54 o/ 21:01:11 welcome. thanks for coming 21:01:19 agenda this week is at 21:01:21 #link https://wiki.openstack.org/wiki/Meetings/Swift 21:01:40 o/ 21:01:41 2.18.0 is done! it's been tagged and released and is available for anyone! 21:01:47 hi 21:02:07 great 21:02:30 o/ 21:02:38 I found a funny stat in the code related to the release 21:02:45 2.18 is old news. 2.19 is going to be awesome. 21:02:48 lol 21:03:09 lol 21:03:20 lol 21:03:21 feature/deep was huge and took a lot of concentration. but since it landed (may 18), we've landed 89 commits (including merge commits). 51 not including merges 21:03:48 more than 7 commits per day, on average 21:04:00 merge all the things! 21:04:17 (from `git shortlog -nes "@{May 18, 2018}"..`) 21:04:44 on a roll! 21:04:49 #topic summit recap 21:05:08 last week I was at the openstack summit in vancouver with kota_ and mattoliverau and m_kazuhiro and rledisez and csatari 21:05:12 * cschwede 21:05:18 and even mahatic was there! 21:05:32 we had a great time 21:05:56 I thought the summit was very good (also, I had no jet lag and wasn't there the whole week) 21:05:56 Yeah it was great 21:06:04 sounds awesome! what a great group of folks! sorry we missed ya'll! 21:06:16 I've talked to just about all of you, I think, about what happened there 21:06:21 see you in Denver, tho I hope!? 21:06:21 lots of interesting conversations 21:06:44 there was a lot of encouraging feedback on what's going on in swift. 21:07:14 lot's of people are using it (and finding more ways to use it more) 21:07:33 and there were even some new faces that turned up at the project onboarding session 21:08:15 I'm not sure what level of participation they'll have, but here's hoping we'll have a few more active contributors :-) 21:08:52 +1, hope it 21:08:59 so yeah... like clayg, the next time together is in denver at the ptg 21:09:01 Let's keep an eye out for them and support them if and when they turn up :) 21:09:09 mattoliverau: yes! 21:09:20 I hope you've all signed up for the ptg. I think the early registration deadline has passed 21:09:22 Not that we wouldn't anyway, great group of peeps here :) 21:09:28 #link https://www.openstack.org/ptg 21:10:19 My baby is officially due on the Monday of the ptg (10th) so I won't be there :( 21:10:22 I paid $199 21:10:36 mattoliverau: I *guess* that's ok 21:10:42 zaitcev: yep. that's the cheap price 21:10:51 mattoliverau: congraturations! 21:11:05 #topic proposal for changing reviews 21:11:09 Oh yeah, I'll miss seeing you all, but marriage and new baby over work :) 21:11:14 congratulations 21:11:34 I've got a proposal I'd like to make and talk about with everyone 21:12:08 zaitcev: i also paid the $200 - so hopefully we're all set! 21:12:11 mattoliverau: congrats 21:12:22 notmyname: sounds ominous 21:12:26 I propose we change our review/approval policy to allowing one core +2 before a +A for merge. (of course, a core could ask for other reviews too, if needed) 21:12:48 clayg: that was just the first installment 21:13:12 I would like to know your thoughts on changing the review policy 21:13:26 tdasilva: lol 21:13:59 notmyname: so the question is do we have any cores right now that we don't want to +A any patch they happen to find and like? 21:14:16 seems reasonable, particularly given (1) the limited review bandwidth we have and (2) the fact that most changes are coming from people i already trust to write good code anyway 21:14:35 I think it's a good experiment to try for the next year or so. We've been favoring stability over progress, and IMO the balance is a little too far towards stability. 21:14:35 clayg: it's ok. I can promise not to review stuff, if that helps ;-) 21:14:40 notmyname: or is the question - will we in the future have a core that might not know when it's appropriate to +A vs. asking for more eyes? 21:14:49 If we end up with too little stability, we can always switch back. 21:15:06 notmyname: I'm against the single +2. I even found mistakes that acoles made, although very rarely. 21:15:23 timburke: +2 on a lot of patches from trusted authors that know how to write good swift patches! 21:16:07 zaitcev: I'll definately grant that I've had a +2 sitting on a timburke patch that acoles came around and -1'd for good reason (would have been a lp bug #) 21:16:16 zaitcev: same goes for you catch stuff I missed as well 21:17:27 zaitcev: even in light of the way torgomatic phrased it? 21:18:51 I suppose we can try 21:18:54 more reviews will catch more bugs, true. but it's not like we can say "ok, so 5 +2s, and then we'll just not have any bugs at all". it's a balance between catching bugs and being able to land code 21:19:03 notmyname: torgomatic: I'm open to running the experiment... but I almost think it's halfway a mind game and halfway just an extension of the "go ahead and +A docs" rule 21:19:09 okay 21:19:21 We could try it, but still a little on the fence. Some patches like aways seem straight forward, yeah 1 +2 would be fine. Others more eyes the better. I guess this is what is meant tho, if more eyes are needed thats just a social/communication thing. 21:19:29 then I get Thiago to review PUT+POST and voila it's +A 21:19:32 ? 21:19:43 sounds good experiment but i have same concern with zaitcev. 21:19:50 clayg: +1 21:19:55 we *constantly* say "if it's a good patch just go ahead and land it" but when it comes to putting code on master we're in reality all pretty conservative 21:19:57 i feel like there should be some kind of "risk evaluation". a simple patch in proxy_logging middleware is ok with just one +2, while a patch in ring.py should wait for two +2. I guess you guys a reasonable enough to known when to ask a second opinion 21:21:14 rledisez: +1 21:21:26 I'm ok with the change. I agree with statements from timburke (i.e., review bandwidth) and torgomatic (progress vs. stability). More then trust the people that write the code, I trust core reviewers *good judgment* to ask for a second opinion (or a second +2). Yes, mistakes will happen, and we might get some bugs that we wouldn't otherwise, but I'm hoping for more +s then -s with such a change. 21:21:26 i suppose there was also a (3) for me: i trust everyone here to recognize when a change is large enough in scope to demand a second review 21:21:41 timburke: +! 21:21:51 gah I mean +1 21:22:13 notmyname: i see two things as being true at the same time "sometimes code that should be +A'd sits there with a +2 instead of on master" and "merging code to master is scary and hard and more eyes is better" 21:22:25 clayg: yeah 21:22:41 but w/e - I ain't SKERED! 21:23:03 what if we had a standing agenda item in this meeting for "stuff you've reviewed and need to call out as big enough in scope to need more eyes"? 21:23:26 I'd be worried that we'd be super conservative and a lot of stuff would end up there 21:23:51 If nothing else it might help us build some confidence. Look tdasilva merged zaitcev's patch and the sky didn't fall down! torgomatic wrote something good and acoles landed it! some random person wrote something useful and timburke merged it, then wrote 15 followup patches too boot! 21:24:33 lol @ "then wrote 15 follow-up patches". so true ;-) 21:25:12 It might, but only till people find their feet, and any new cores in the future I'd expect to be a little more conservative 21:26:14 hmm... how does the vote option work again? 21:27:05 honestly after so long with the 2 +2 rule I'm pretty fearful of a change - but I'm pretty sure some of that is just the devil you know... I think notmyname is right to push us to question status quo... but I don't much care for moved cheese if I'm entirely honest 21:27:32 luckily - we can do whatever we want and change our mind later - we're running this banana stand! 21:27:53 so many american/english/clay idioms ;-) 21:28:07 probably the correct answer is 1.5 +2's 21:28:12 I just assume it's a clayism :p 21:28:24 acahcahcphap - that's 3!? of course the correct answer is 3! 21:28:26 "wait!? clayg says we're moving the banana stands now?", probably kota_ and rledisez right now ;-) 21:28:32 It might be worth waiting some time until calling a vote. This idea was only introduced ~25 minutes ago, so I'd bet that proper consideration would take some time. 21:28:32 the devil is in the cheesy banana details! 21:28:42 lol 21:28:43 :D 21:28:50 torgomatic: yeah, that was one of my options I'm trying to figure out 21:29:53 torgomatic: we talk about this EVERY time we look at code inventory and feel bad we don't have more better/mergeable changes 21:30:05 It might be worth somehow articulating some expectations e.g. 'API changes ought to require more review than test changes', 'ring.py may require more review than ring.rst' 21:30:09 heh... 21:30:31 clayg: in person, yes, but this is the first time I know of that it's been brought up in a meeting. 21:30:42 If that's wrong, then disregard what I said about waiting. 21:30:47 +1 for acoles 21:30:56 it's so easy to get caught up trying to fix up something on a patch and forget to check for docstrings... 21:31:02 torgomatic: that's true. but it's also all the same people who are in-person and talk about it 21:31:19 #vote should a single +2 be ok for landing a patch on master? yes, no, wait 21:31:23 bah 21:31:25 that didn't work 21:31:48 test and docs are easy to get single +2 and it will work with the rule proposed. 21:32:04 I mean, "yes, I'm ok with this", "no, I'm not ok with this", and "I'd like to wait a week and say yes or no at next week's meeting" 21:32:08 To help lower the number of bugs introduced we could require 2 +2s when close to a release, tho we do release often 21:32:08 #startvote should a single +2 be ok for landing a patch on master? yes, no, wait 21:32:09 Begin voting on: should a single +2 be ok for landing a patch on master? Valid vote options are yes, no, wait. 21:32:10 Vote using '#vote OPTION'. Only your last vote counts. 21:32:10 notmyname: it's #startvote 21:32:17 the design change, I'm still feeling we need more than single +2, IMHO. 21:32:20 yay! 21:32:36 #vote yes 21:32:52 #vote yes 21:33:00 #vote yes 21:33:05 #vote yes 21:33:07 #vote eys 21:33:08 clayg: eys is not a valid option. Valid options are yes, no, wait. 21:33:12 lol 21:33:14 lol 21:33:19 Lol 21:33:22 aye 21:33:26 #vote yes 21:33:29 clayg: did you mean 'aye' :P 21:33:37 #vote yes 21:33:45 #yes 21:33:51 lol 21:33:55 #vote yes 21:33:59 Im ok with yes knowing the social conventions we've been talking about 21:34:08 but I like that we still have chances to get more reviews for large (or design change) patches. 21:34:10 zaitcev: rledisez: mattoliverau: ? 21:34:13 #vote yes 21:34:19 mattoliverau: thats a #it_depends 21:34:21 #vote yes 21:34:57 Yeah kinda, but I'll get off the fence, we can always go back, and trying just after a release is the best time :) 21:35:02 #vote yes 21:35:03 #vote yes 21:35:05 kota_: mattoliverau: do you think we could articulate some explicit expectations? top-level doc in repo? expand review_guidelines.rst? 21:35:07 #endvote 21:35:08 Voted on "should a single +2 be ok for landing a patch on master?" Results are 21:35:10 yes (11): rledisez, notmyname, acoles, tdasilva, kota_, torgomatic, m_kazuhiro, mattoliverau, zaitcev, clayg, timburke 21:35:33 clayg: review_guidelines sounds nice to write down 21:35:46 TBH, I didn't expect that. I expected to bring it up and then wait a week. I didn't expect it to have broad support like this 21:35:48 or something like principle? 21:36:17 notmyname: just to make it clarify, this would also affect other repos (i.e., python-swiftclient) 21:36:37 #agreed a single +2 s sufficient for landing a patch. core reviewers are expected to use their best judgement as to when other reviewers should be called in to give additional reviews 21:36:38 tdasilva: yes 21:36:50 tdasilva: ie, all the code repos we manage 21:37:08 notmyname: can you write something up - email list - or at least follow up to get kota_ or mattoliverau to start on an update to guidelines? 21:37:20 Yeah, being clear if great. And I know it isn't a simple rule. This is ok, this isn't. But just so something is written somewhere :) 21:37:31 clayg: yep 21:37:47 Like I think we #agree that we should pursue the change - but there HAS to be some sort of ... announcement or something - we've been doing it one way forever 21:37:59 and to be clear, this is really just our social convention we choose to follow. there is no technical enforcement of this or any other review policy 21:38:21 notmyname: +A 21:38:54 and any one should feel free to bring it up again in the future if they think we need to tinker with it again.... 21:39:00 yes. I'll write up something. adding it to review and contributor guidelines is good. a ML post is good too, but will need to be a little more carefully worded 21:39:07 it's all mind games - it'll be good for us - once we get used to the idea that we can come to a patch with no other reviews and if it makes swift better we can put it on master right then and there (subject gate backlog) - I think it will be empowering to reviews and authors both! 21:39:08 tdasilva: yes, absolutely 21:39:26 clayg: right! that's the way to think! :-) 21:39:47 #topic events 21:39:49 tdasilva: in fact we should probably PLAN to have a retrospective 21:39:53 all right. last topic 21:40:03 clayg: tdasilva: at the PTG in denver! 21:40:04 clayg: good PTG topic 21:40:18 we've already discussed the PTG 21:40:20 just after the bugfest ;) 21:40:25 lol 21:40:34 but tdasilva pointed out another conveference we should consider going to 21:40:38 #link https://mountpoint.io 21:40:50 one question about PTG, do we know the schedule yet? will it be, as usual, 2 days cross-project and 3 days of pure swift stuff? 21:40:50 looks very interesting, and I'll definitely be looking at it more 21:40:57 alecuyer and I got tickets, we are waiting to book plane and hotel 21:40:58 rledisez: likely 21:41:13 rledisez: i'm SO sorry you guys missed Dublin - it was a snowy mess 21:41:14 rledisez: for PTG or mountpoint.io? 21:41:15 rledisez: or rather, I assume so because I have no reason to think otherwise 21:41:28 tdasilva: can you give any more info on the mountpoint conference? 21:41:35 yeah, hopefuly, no snow strom in denver in september. maybe sand storm? :D 21:42:44 Oh mountpoint sounds interesting 21:42:50 notmyname: yeah, that's a new conference being promoted to talk about opensource SDS and they are looking forward to seeing Swift talks proposed 21:43:16 tdasilva: cool find bro! 21:43:18 I assume it's in the US 21:43:23 Vancouver 21:43:23 it's in vancouver! 21:43:31 Oh cool 21:43:38 I love Vancouver 21:43:51 lol 21:44:51 i suggest that notmyname should go 21:45:09 #startvote ;) 21:45:09 I suggest you take that up with mrs notmyname ;-) 21:45:10 Only the meeting chair may start a vote. 21:45:14 tdasilva: lol 21:45:26 #topic open 21:45:32 anything else to bring up this week? 21:45:39 notmyname: I suggest you take mrs notmyname 21:45:42 how much cost will it require per person for mountpoint? 21:45:49 acoles: yeah, actually. that's a great idea :-) 21:45:54 kota_: I couldn't find it 21:46:07 notmyname: same with me, tdasilva may know something 21:46:11 oh yeah, speaking of code review policy, http://lists.openstack.org/pipermail/openstack-dev/2018-May/130802.html seemed to spark an interesting discussion 21:46:12 i can find that out 21:46:19 Sounds great, is love to go, but not till post baby and if I can sell it to SUSE, who aren't really swift focused 21:46:29 *I'd 21:46:30 will mention in #openstack-swift channel when i find out 21:46:37 tdasilva: thank you 21:46:56 timburke: i also found the nitpicking thread 21:47:01 thanks again, everyone, for the final push to get 2.18.0 landed 21:47:03 timburke: thanks! 21:47:45 so... on the nitpicking thread 21:48:01 kota_: I found "Registration costs $25 per person. " https://www.regonline.com/registration/dialogs/regtypedetails.aspx?EventId=2447527&RegTypeId=509661 21:48:18 my first reaction is "oh, we don't have a problem with that. that's pretty much what we do anyway (the guidelines)." 21:48:23 m_kazuhiro: thanks! 21:48:52 however, then I realize that of course *I* don't think we have a problem with that. it's actually not my place to say if we have a nitpicking problem or not 21:48:59 m_kazuhiro: thx 21:49:05 That's cheap, how long does it go for? 21:49:13 2 days 21:49:24 that is, we've all got a position of "power" in the community, so it's easy for us to claim there's no problem in the community 21:49:25 Oh, that's a long way to go for 2 days 21:49:37 mattoliverau: but, you're in vancouver, so that's nice 21:49:41 but mind you that it's happening just before ossummit, so most folks stay for that 21:49:48 and that costs more, i believe 21:49:50 That is true 21:50:18 but i guess one could also propose talks to ossummit 21:50:29 Oh yeah, but thats still a good solution, SUSE is pro OSS conferences ;) 21:50:38 so my point is, re the nitpicking, we need to realize there may be a problem. and we need to pay attention when people come into our group to make a contribution and realize what we see as normal others may find quite hostil 21:51:16 notmyname: that's fair, but it's also easy for an outsider with less experience to misjudge the cost of "merging w/o a test/doc/etc" 21:51:32 so if someone has an issue, please feel free to say something to me (privately or otherwise) and remember that we were all once new ourselves :-) 21:51:42 clayg: yep. doesn't mean we land bad code 21:52:14 the ML thread reminds me of the late night hackathon conversation we had as a group about talking in IRC and how difficult than can be for some people 21:52:22 don't we give a new contributor their first unit test for free? 21:52:35 Lol 21:52:51 mostly that we all have very very different perspectives on social cross-cultural interations in potentially non-native languages 21:53:18 :P 21:53:22 acoles: lol 21:53:41 all right. anything else? or are we done for this meeting? 21:54:01 acoles: that's a good deal! 21:54:12 Done, I'm hungry :p 21:54:14 I was half serious 21:54:33 mattoliverau: :-) 21:54:40 rather than -1 for no test I might rite the test to encourage future behaviour 21:54:49 or even *write* a test 21:54:49 acoles: that's really good 21:54:56 write a right test? 21:55:01 but I'm not promising ;) 21:55:03 is that your right? 21:55:10 ok ok ok 21:55:13 notmyname: right! 21:55:13 #endmeeting