14:02:05 #startmeeting airship 14:02:06 Meeting started Tue Sep 25 14:02:05 2018 UTC and is due to finish in 60 minutes. The chair is mark-burnett. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:09 Hi 14:02:10 The meeting name has been set to 'airship' 14:02:31 I didn't really prepare an agenda, though: https://etherpad.openstack.org/p/airship-meeting-2018-09-25 14:02:33 hey mark-burnett hope you're feeling a bit better :) 14:02:54 yeah, a bit better, still a bit of a cold though 14:02:59 :) 14:05:25 thanks everyone for adding items to the agenda 14:06:12 #topic Meeting TIme 14:06:30 * roman_g o/ and left 14:06:42 Looks like no change here - we had one or two new additions to the doodle, which look good for the current time. 14:07:13 Let's close it 14:07:25 Yeah, we can't keep this issue open every week for months 14:07:33 This thing is just floating and the people asking for it aren't speaking up 14:07:40 If they really care, they'll ask again 14:07:45 Agree 14:07:49 Ok, let's move on 14:08:05 #topic -2 Reviews 14:08:14 @portdirect asked that we discuss this again this week 14:08:53 I don't know whether he's here? 14:10:20 well, it seems like we aren't going to have much discussion around this 14:10:25 lol 14:10:32 Channeling my inner pete 14:10:34 two meetings in a row and nothing to say on the topic 14:11:04 Sorry been held up 14:11:14 "-2 reviews are typically reserved for strong responses when a PS doesn't just need to be changed, it needs to be abandoned" 14:11:15 Give me 5 if you can 14:11:49 well, we can move on and maybe come back 14:12:17 #topic reducing gerrit bot noise 14:12:37 We discussed this briefly last week, but attendance had diminished before we could reasonably vote 14:13:00 So, what would be the options to vote on? 14:13:02 This was originally roman's suggestion, and there didn't seem to be much objection to removing the PS upload notifications 14:13:03 sorry, I missed that one - what are the knobs we can turn down for the bot? 14:13:15 ah I see 14:13:18 I'm not sure whether it's possible to set it to merges only or not 14:13:22 Is that a problem? 14:13:30 * mark-burnett shrugs 14:13:40 I mean you can configure your client if you don't care. 14:13:52 : ) 14:14:08 If everyone configures their client to hide those, then why have them? 14:14:09 FWIW they don't bother me, I find them informative around "what's going on at the moment". But I can easily respect it being distracting / annoying for other folks 14:14:21 mark-burnett: not everyone, I like those :) 14:14:33 I don't know if it's possible, but I think a digest summary would be nice, at some interval. 14:14:40 mattmceuen: +1 14:15:00 * portdirect sneaks in through the back door, sits down and hope no one notices him knock over a coffee mug 14:15:01 I wonder if roman/others would like to try client-side configuration 14:15:01 I believe the knob is available: https://docs.openstack.org/infra/system-config/irc.html#gerritbot 14:15:08 b-str: you can ignore the notifications in your irc client, and ask for a daily digest on gerrit email notifications maybe ? 14:15:32 aha thanks sthussey 14:15:32 Because of how Gerrit works, I'd be good with turning off PS upload notifications 14:15:40 sure, they don't bother me per se, but I can see where getting 4 notifications for 4 "oops" is a little aggressive reporting. 14:15:51 oh it's technically possible, and the feature was added indeed 14:16:06 yeah, hard to separate the "substantial update" vs "4 typo fixes in 1 hour on a single change" 14:16:45 I think Roman's concern is if someone asks a question and then in 10m it is scrolled off the screen due to PS notifications, it might be hard to get traction with support 14:16:47 well yeah, there is no difference between new patches and updates 14:16:58 TBH, put me in the camp of "don't care - not a problem for me" 14:17:13 Yeah, I think that's a valid one, though maybe addressable for him with just ignore 14:17:19 I personally don't care, but don't find IRC that informative. Gerrit has a web interface, I can easily see what is going on there 14:17:31 That is more digestable, imo too 14:17:50 I would table it until Roman is here to state his case 14:18:14 I think that's fair 14:18:25 I'll mention the suggestion to him, and he can try it 14:18:33 Should we move back to -2 reviews? 14:19:05 go for it 14:19:14 sure, this was a comment based on some behavior that we had in the early days - though its fading out now a bit i think 14:19:16 #topic -2 Reviews 14:19:55 but its always been my understanding that -2 can essentially be read as "this is a bad idea, we really should never merge this" 14:20:24 so we should probably be a bit less liberal with them? 14:20:28 it is the intent -- but it doesn't prevent a merge 14:20:55 -2 should be kept for extremes reason in openstack, so I suppose airship could take this as inspiration 14:21:05 That seems a bit extreme. Shouldn't folks just read them as 'this will break something.' So is blocks the merge until that is addressed. 14:21:08 this is my thought 14:21:08 Gerrit says 'Do not merge'. Seems pretty straightforward. 14:21:28 People can read into it what they want. 14:21:33 i'm just offering the perspective of where ive come from in the wider community 14:21:40 -1 means something is wrong and you don’t think it should be merged, but needs work 14:21:53 -1 workflow will prevent a merge 14:21:58 this please have a look at https://docs.openstack.org/project-team-guide/review-the-openstack-way.html 14:21:58 `-1` would seem pretty approprate for you ned to update or respond to this before merge? 14:22:27 `The purpose of the -2 vote is to indicate to the submitter that any further time they spend on the change will almost certainly be wasted. ` 14:22:51 ^ I suppose this is the nub of my argument 14:22:57 -1 WF doesn't persist between updates to the PS. 14:23:13 Then Gerrit should be updated to reflect that -2 indicates the PS should be abandoned 14:23:14 That's because you can fix things with PS :) 14:23:20 I have certainly used the -2 before for procedural reasons around a release too. 14:23:21 I've been bit by the -1 thing 14:23:46 Yes, sometimes -1's get ignored 14:23:47 let's not talk about abandonning, but talking about channeling energy: if needs updates -> -1 14:24:00 Perhaps that's the root issue? 14:24:07 evrardjp: +++ 14:24:19 I would be happy if airship would follow openstack procedures, as it makes things clearer for contributors 14:24:21 If a PS will break existing functionality, I think a -2 is warranted 14:24:31 I review after a -1 that didn't address all the -1's things - don't see an issue, but the -1 person sidechannels me about "why not my -1's" 14:24:35 Kaspars Skels proposed openstack/airship-treasuremap master: Set Keystone admin endpoint to match public https://review.openstack.org/604947 14:24:46 sthussey: I do not agree, as this would not pass gating. 14:25:09 in a perfect world that's true 14:25:09 That may be true when zuul gating can support running larger tests 14:25:41 this is further away of the initial conversation :) 14:25:51 Merged openstack/airship-shipyard master: Update to Airflow 1.10 https://review.openstack.org/603927 14:25:51 it's not too far i think 14:25:54 if you definitely do not want the patch to get in, add -w. 14:25:59 so I propose one of two things 14:26:04 Workflow is cleared w/ every PS on a cS 14:26:09 1) we adopt the spirit of: https://docs.openstack.org/project-team-guide/review-the-openstack-way.html 14:26:16 or 2 we write our own 14:26:51 sthussey: on purpose: "do not merge in this case, you're breaking x." Then the person fixes its patch to not break x, and review happens again. Why taint the patch? 14:26:56 otherwise the different style will make it hard for people who have worked on openstack and other projects to come in and participate 14:27:13 What is tainted? 14:27:18 I would prefer we adopt the openstack way, as we plan to collaborate / integrate with that project quite a bit, and the PTG proved that there is an overlap in user / developer bases 14:27:18 You remove the -2 and life goes on 14:27:20 I think -2 has been used in order to avoid -1's being ignored 14:27:25 portdirect: agreed, one or the other, but I think it is worth documenting 14:27:32 They're easily removed, as sthussey says 14:27:37 But they aren't automatically removed 14:27:37 sthussey: I will never review a -2. 14:27:47 Okay 14:27:52 neither would i for any project other than here ;) 14:27:57 Does a change need more reviews at that time? 14:27:58 well I mean objectively, why would I? 14:28:01 It clearly doesn't 14:28:07 so it's an accurate indicator in this case as well 14:28:56 I would happily replace -2 with the idea that if a CS gets a -1, it won't be merged until the person giving the -1 provides a +1 or +2 14:29:01 Sometimes explaining why you’re ignoring a -1 in a merge is also polite. It’s the final decision of the cores, but clear communication is better for everyone 14:29:08 If people are ignoring -1s, that's a problem we need to fix 14:29:16 agreed with hogepodge 14:29:22 ++ 14:29:40 there will be times were a diff of opinion comes in 14:29:43 here the idea is: if you want to bring more people to the community be clear at every time. In your contributor's guide (say which practices you have) 14:29:47 or in your reviews 14:29:55 eg: https://review.openstack.org/#/c/604428/5 14:30:06 but there have been cases that a -1 review is left and then the author responds to it and the CS is approved and merged before the original reviewer even gets a chance to re-review 14:30:32 We have to weigh: 14:30:44 1) the chance that things get merged badly if we're not careful 14:30:55 2) the fact that everyone with experience with -2's interprets them harshly 14:31:16 If we define a non-conventional meaning for -2, we'll be alienating potential contributors 14:31:16 1) git revert 14:31:26 Let's work to be careful with merges 14:31:31 isn't a revert also impolite? 14:31:35 that's the issue here, politeness 14:31:40 Felipe Monteiro proposed openstack/airship-pegleg master: Remove Pegleg stub logic from CLI and engine https://review.openstack.org/605091 14:31:47 or hurt feelings, or however we want to say it 14:32:00 I'll happily follow whatever is decided, but I come from a perspective of trying to get things done. Feelings don't enter into the equation. 14:32:05 2) as long as there is a policy it would be clearer -- currently there is only an implicit policy which is not the clearest one if I understand the conversation 14:32:13 Feel free to give my PS a -5 if that is what is warranted 14:32:21 Zuul can't run full Airship gates, so we need something else to block patch sets, -2 is the only tool available for that at this time. 14:32:39 I don't agree 14:32:43 no - a choesive core team is 14:32:48 portdirect: +1 14:32:52 *cohesive 14:32:59 it's the +w that decides a merge 14:33:32 if the -2 -1 discussion is talking about merging, I think we are doing it wrong 14:33:43 Ive seen several cases where there have been 2*+2 and a -1 from a core, often that core who -1 is also the same person to +wf 14:33:50 I don't want to lose contributors for the sake of keeping code out. It's a tradeoff and it's worth the slight risk. 14:34:01 as they accept that even though they dont like it, others do 14:34:03 -2 -1 is about code quality -> -1 update it, -2 go back to drawing board? 14:34:09 at least in openstack ters 14:34:11 terms* 14:34:13 according to openstack guideline, -2 should be accompanied by a comment explaining the reason that the change does not fit with the project goals, so that the submitter can understand the reasons and refocus their future contributions more productively. 14:34:22 It can be confusing because some rules are cultural (two +2s) and some enforces by the gate (only +1 w needed to merge) 14:34:55 Felipe Monteiro proposed openstack/airship-pegleg master: Remove Pegleg stub logic from CLI and engine https://review.openstack.org/605091 14:35:06 So it seems like the action item here is likely 'Write the guidelines' 14:35:13 I agreed on both assertings of jamesgu__ and hogepodge (again) 14:35:14 It won't be decided in IRC 14:35:33 sthussey: it will be discussed in a review , guess what will happen? :p 14:35:46 hahaha :) 14:35:56 but yeah maybe worth moving to another topic... 14:36:29 As stated, it needs to be documented anyway. I believe there is an ongoing effort for governance documentation 14:36:39 This can just follow under it - Code of Conduct type of thing 14:37:09 I really doubt it is that big of a thing 14:37:11 I do think that if -1's persissted, it would be clearer. 14:37:28 In 1000+ reviews of Airship PS, less than 10 are -2 according to stackalytics 14:37:49 Felipe Monteiro proposed openstack/airship-pegleg master: Remove Pegleg stub logic from CLI and engine https://review.openstack.org/605091 14:38:15 are we moving on mark-burnett or wrapping up discussion on this? 14:38:45 Yeah, some good points have been discussed, but it's clear we're not going to settle on something here i think 14:39:09 Scott Hussey proposed openstack/airship-in-a-bottle master: [WIP] Add apiserver w/ webhook https://review.openstack.org/604918 14:39:19 #topic Marketing Deadlines 14:39:58 Please note the deadlines and links in the etherpad: https://etherpad.openstack.org/p/airship-meeting-2018-09-25 14:40:07 I think I should have put this in announcements :> 14:40:13 Ok, on to new business 14:40:20 #topic Pegleg breaking changes 14:40:59 So the initial pegleg sketch was mostly a stop gap, and frankly full of dubious technical decisions 14:41:25 Felipe has been trying to improve it, and has included some breaking changes that are discussed here: http://paste.openstack.org/show/730723/ 14:41:58 Looks like there's room for discussion around managing breaking/changes, but it feels like it just fits in generally with a versioning conversation 14:42:13 I'm not sure we're at a place where we can solidly version these tools yet, tbh -- surely some of them 14:43:15 I am a big fan of the changes, just a little bit of growing pains - nice work felipe 14:43:40 Yeah, I'm not sure there's much more to talk about here - just an effort to raise awareness about the newer changes 14:44:22 Ok, let's finish up 14:44:25 #topic roundtable 14:44:30 Anything we missed? 14:45:22 I think today has gone long enough 14:45:37 For next meeting possibly open the topic of a versioning strategy for the components 14:45:46 Sure 14:46:07 Thanks all 14:46:09 #endmeeting