15:00:41 #startmeeting releaseteam 15:00:42 Meeting started Fri Feb 17 15:00:41 2017 UTC and is due to finish in 60 minutes. The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:45 o/ 15:00:45 The meeting name has been set to 'releaseteam' 15:01:10 courtesy ping: ttx, dims, fungi, stevemar, sigmavirus 15:01:23 last fillup before ocata! 15:01:30 * dhellmann puts on ominous music 15:01:32 yay 15:01:35 :) 15:01:36 this is week R-1 15:01:38 o/ 15:01:46 our agenda is in the etherpad as usual 15:01:48 #link https://etherpad.openstack.org/p/ocata-relmgt-tracking 15:02:16 #topic last minute final release candidates 15:02:40 there's an updated report, hot off of the presses 15:02:41 #link http://paste.openstack.org/show/599421 15:03:12 we're expecting an update from the senlin team to deal with their long list 15:03:16 most of the other projects look short 15:03:24 yeah, except senlin 15:03:28 but that is in progress 15:03:31 right 15:03:43 we ignore the ones with UPPER_CONSTRAINTS_FILE and .gitreview? 15:03:50 so I think it should be safe to say we're done except for senlin 15:04:01 dims : yes, those don't need to be in a release, really 15:04:07 right 15:04:09 yes, I'm fine granting senlin a delay since they are the only ones 15:04:21 not as if everything was oi fire 15:04:23 on 15:04:49 ok. I expect to be leaving the hotel shortly after our meeting to drive home, which will take several hours. if one of you catches the senlin update, go ahead and process it. otherwise I'll do it when I reach home. 15:04:58 ack 15:05:08 freezer seems to have some stuff 15:05:13 ack dhellmann 15:05:17 #action dhellmann send email declaring release candidates frozen except for very critical issues 15:05:52 dims : at this point unless they complain I think we'll just handle those in a point release 15:06:08 sounds good 15:06:52 #topic Missing stable branches 15:07:02 the only branch we're missing is python-magnumclient, right? 15:07:34 hmm, magnum too? 15:07:40 right. I was just wondering if cuttinh the stable branch post-release won't actually give us even more trouble than cutting it now 15:07:45 $ .tox/venv/bin/list-deliverables --no-stable-branch 15:07:45 magnum 15:07:45 python-magnumclient 15:07:45 tripleo-quickstart 15:07:45 tripleo-validations 15:07:56 I thought the magnum branch was cut, checking 15:08:03 maybe I have an out of date repo 15:08:37 no, they missed the stable branch request 15:08:41 no, I don't see it in the magnum repo 15:08:45 yeah 15:08:46 https://review.openstack.org/#/c/435026/3 15:09:04 oh, are they the ones with the cve? 15:09:09 I think that's it 15:09:10 I'm fine forcing it 15:09:14 ah. 15:09:21 I told them it would be safe to hold off 15:09:24 ok 15:09:31 if they are not already experiencing gate issues, there shouldn't be any harm in waiting 15:09:47 packagers may be confused, but we should get a branch set up as soon as the cve fix lands 15:09:58 strigazi : around? 15:10:20 so, back to magnumclient... I wonder if cutting Friday is not worse than cutting now 15:10:40 but I may miss part of the picture 15:10:43 ttx: how so? 15:11:00 we'll be missing a branch, and if we cut one anyway... 15:11:08 what's the point in delaying ? 15:11:14 heat, mistral, and rally use python-magnumclient 15:11:22 we've declared a library release freeze until after the final release 15:11:36 in order to not introduce instability 15:11:53 create branch from last release, right? 15:12:03 ok, that would trigger a minimums bump, I see 15:12:09 ok, ignore me 15:12:14 well, they have a new release requested so I would expect to branch from that 15:12:41 it wouldn't change the mins, but it would update constraints 15:12:42 alternatively we could say that what we have on release day is what will be in stable 15:13:07 so their new release would be a pike release? 15:13:25 do we want to set a precedent that cutting stable branches 5 weeks after the deadline for libraries is ok ? 15:13:28 that's 4 weeks late, so I could see doing that. We should talk to the magnum team about it, I guess. 15:13:41 not especially 15:14:20 I mean, I'm fine with making an exception and all, but we should make sure they understand that we have two options here 15:14:45 and that they put themselves in a painful situation 15:15:08 option 1 is to approve the new release and branch from that before the final 15:15:10 Normally we shoudl have cut the stable branch from what we had 15:15:15 option 2 is to do option 1 after the final 15:15:16 ttx : dhellmann : they did not know release process at all until a week or so ago. 15:15:31 option 3 is to branch from the most current release before the final 15:15:33 option 3? cut branch from last release? 15:15:34 right? 15:15:43 yep i vote for #3 15:15:48 dims : I no longer accept that excuse. 15:16:19 dhellmann : i don't either, so i'd vote for #3 15:16:21 dhellmann: I think we should have done #3 at library freeze time 15:16:35 since we didn't, I'm open to #1 and #2 15:16:39 they will have to wait till past release and manage cherry picks 15:16:41 * dhellmann is pleased to find others being even more hardline than himself 15:17:06 ok, I will send an email outlining those options and the reasons and indicating that we prefer option 3 15:17:16 I'm not necessarily for a hard line here -- I just want to make sure they understand it's an exceptional situation 15:17:19 #action dhellmann send email to address magnum client release 15:17:54 yeah, I was trying to be a little flexible this time around because of the shortened cycle, but 4 weeks is pretty late no matter what the schedule 15:18:04 I'm fine with #1 or #2 as long as the magnum team understands that we should normally do #3 15:18:21 i.e. we are cutting them some slack 15:18:41 I think I'd rank them 2, 3, 1 15:19:18 basically I don't want them to think it's OK, or them to expect we'll do #2 or #1 next cycle again 15:19:20 maybe 3, 2, 1 15:19:24 * fungi wonders if the ptl didn't get the e-mail telling them to follow the weekly release schedule annoncements, or didn't heed the advice, or didn't understand 15:19:33 but I'm OK to make an exceptions this time 15:19:43 since they are the only ones 15:19:51 fungi : i requested PTL to add tags to his filter 15:20:04 fungi : yeah. They've had a long time to ask, though, and the schedule is not a secret. 15:20:15 we've had several new ptls and liaisons this cycle 15:20:17 honestly surprised there's just one... doing pretty well with the new process i guess! 15:20:22 dhellmann: do you agree that normally we should have done #3 a few weeks ago ? 15:20:52 ttx: yes. like I said, i was trying to be a bit flexible because of the compressed schedule, to make it easier for patch releases if there was a need. 15:21:08 but I wouldn't do that for a longer cycle, like pike will be 15:21:28 I believe we've already updated the process doc to indicate that we expect branches from all projects around the third milestone 15:21:46 OK, I propose we do (2) after explaining that normally we should have just branched from what we had at freeze time 15:21:50 yes, b922b6dfebf0771f44d2a1a880fc377cdb1f48a6 15:22:04 i can go with that ttx dhellmann (#2) 15:22:14 i.e. "won't work for Pike" 15:22:14 ok, option 2 is going to be potentially disruptive to those 3 other teams 15:22:33 more than #1 ? 15:22:48 (that was my original question) 15:22:52 waiting until after the final postpones the disruption until after the ptg 15:23:10 basically, we're in the period where teams are supposed to not have to deal with firefights, and this may introduce one 15:23:22 I guess we could always revert the constraint update 15:23:43 dhellmann : i can do a test with the affected projects before i let the u-c in 15:23:51 dims : ack, ok 15:24:07 well, if we're going to do 2, do we still need to send an email? 15:24:31 dhellmann : y we should publicize the plan 15:24:33 I think we should make a point to explain it's an exception and not the rule 15:24:41 ok 15:24:52 #agreed we will make an exception for python-magnumclient and release and branch today 15:25:08 we need to introduce the branch instructions into that patch, or a follow-up 15:25:43 dims yes 15:25:48 hmm #2 is after final 15:26:00 "2 is to do option 1 after the final" 15:26:03 oops 15:26:04 #undo 15:26:04 Removing item from minutes: #agreed we will make an exception for python-magnumclient and release and branch today 15:26:14 so we may be not talking about the same thing 15:26:20 yes, let's stop using option numbers 15:26:27 :) 15:26:41 do we want to tag and branch today or next friday 15:26:47 dhellmann: with "branch now" would you say that affected projects should roll a new RC to catch the constrinat update ? 15:26:59 ttx: constraint updates don't go into the releases, so they don't need to do that 15:27:20 we've been asking the requirements team to pre-approve constraint updates 15:27:26 same with "branch after release", won't trigger a bunch of point releases ? 15:27:30 tonyb, prometheanfire: ping? 15:27:52 ttx: no, we don't update the minimum version so there is nothing to sync into the projects 15:28:04 the constraints file is used from the global location 15:28:11 hmm, sounds safe to me then 15:28:22 so is that a vote for today? 15:28:43 I'm fine with today or next week. Small preference for today and a clean slate 15:28:50 dims: ? 15:28:52 so make the new release with a branch, then test u-c change with affected projects 15:29:07 +1 15:29:17 dims : ok. will you have time to do that testing? 15:29:20 yep 15:29:32 cool, do you want to take the action to process the release, then? 15:29:49 dhellmann : sounds good, please give me an action 15:29:56 #agreed we will make an exception for python-magnumclient and release and branch today 15:30:17 strigazi : can you edit the magnumclient request and add request for creating the stable branch please? 15:30:22 #action dims test the python-magnumclient u-c change with heat, mistral, rally 15:30:43 strigazi : https://review.openstack.org/#/c/435241/ 15:30:55 dims: thanks for handling that 15:31:01 dims ok 15:31:07 thanks strigazi 15:31:32 moving on then 15:31:39 #topic Release notes update patch 15:31:50 as ttx points out in the agenda notes, it would be good to merge this now 15:31:59 there will be more updates, and those can happen early next week 15:32:17 conflicts with: 15:32:23 https://review.openstack.org/#/c/435282/2 15:32:31 https://review.openstack.org/#/c/435456/1 15:32:40 I'll prep a patch and we can get it merged before the final release next week 15:32:50 both need a refresh anyway so it's fine 15:32:53 we expect an update to the senlin rc2 patch so that should work itself out 15:33:00 so merge now 15:33:03 and yep, same for the other 15:33:24 ttx: do you want to do the honors there? 15:33:33 sure 15:33:36 thanks 15:33:41 #topic Coordinating for final release work next Wednesday 15:33:52 ttx, fungi, and I will all be in ATL next week 15:34:02 apologies folks, i won't be there to celebrate in person 15:34:08 I proposed that we meet at or right after breakfast Wednesday to do the merging work 15:34:09 dims: aw 15:34:12 we'll also be here in channel 15:34:18 dims: we'll definitely miss you! 15:34:19 dhellmann : cool! 15:34:40 loquacities has asked me to ping the docs folks so they can update the landing page when we're ready 15:35:05 so when we have a firm time for when we're meeting, I will let her know so they can be present, too 15:35:31 I figure we can set that time on monday or tuesday, when we have seen what the morning rush at the restaurants in the hotel looks like 15:35:36 thoughts? 15:35:56 i'm happy to join you all on wednesday since infra stuff will be officially over by then 15:36:10 ack 15:36:17 fungi : excellent, thanks 15:36:32 we might be able to secure a release war room 15:36:40 next up then 15:36:41 #topic Pike release schedule final approval 15:36:43 #undo 15:36:44 yeah, I wasn't sure how early we would need to start 15:36:44 Removing item from minutes: #topic Pike release schedule final approval 15:36:47 it took a bit longer than expected last time 15:37:05 if we need to be done by 11:00, I would rather be done early than rushing 15:37:06 we can discuss that on-site 15:37:08 yep 15:37:34 I intend to have all of the patches we need lined up by monday morning 15:37:45 #topic Pike release schedule final approval 15:37:54 I think we're ready to approve the details we have now 15:38:05 yes, will add PTg data once the date is 100% 15:38:08 date* 15:38:09 I do agree with Brian that as soon as we have the next ptg dates we'll ad those 15:38:09 yep 15:38:20 don't want people to start organizing 15:38:33 probably next week we'll have the date set in stone 15:38:41 I'll go ahead and approve that patch now 15:38:45 ack 15:39:18 we might want to set Pike "Under development" too 15:39:34 is there already a patch for that? 15:39:45 I'll prepare that (moving Ocata to "pre-release freeze" as well) 15:39:50 would be nice if maybe we had it settled in time for the ptg feedback session on thursday? 15:39:50 I think preparing that is part of the tasks I was supposed to do today 15:39:54 ttx: thanks 15:40:11 fungi : yes, good point 15:40:53 fungi: ++ 15:41:05 right then, let's talk about next week 15:41:07 #topic PTG planning 15:41:22 ttx: this one is yours 15:41:42 there is an attendee list for the room, if you already know you'll be somewhere else part of the time, good to indicate that there 15:42:24 yeah, it's going to be a crazy 2 days for me and then fairly quiet after wednesday morning 15:42:27 We mentioned we could do a release retrospective 15:42:43 i think we should schedule it in the large fishbowl room 15:42:51 and Thursday or Friday 15:42:53 you asked about scheduling for that, it might be better to do it some time thursday or friday morning 15:43:11 I know some teams/people are leaving friday so thursday may give us more liaisons 15:43:12 Let's do Friday morning 15:43:18 either way 15:43:20 ah, good point 15:43:33 * ttx looks up ethercalc 15:43:45 https://ethercalc.openstack.org/Pike-PTG-Discussion-Rooms 15:44:07 2:30pm Thu ? 15:44:31 wfm 15:44:44 we might want to avoid that horizon item, in case they have input 15:44:59 the keystone team is on top of things, but we had npm-related issues with some stuff this time around 15:45:00 dhellmann: that's wednesday though 15:45:08 * dhellmann can't read 15:45:09 ok 15:45:22 ok deal 15:45:36 #agreed retrospective thursday 2:30 in south captial room 15:45:47 Quick reminder that requirements/stable/Relmgt will have a team dinner on Tuesday night 15:46:06 hopefully not poisoning the whole team at the critical time 15:46:12 hah 15:46:19 RSVP @ https://framadate.org/XIbbQnbxSKRPW1yK 15:46:22 that could lead to a terrible release 15:46:24 no seafood :-) 15:46:32 I'll probably book over the weekend while there are still options 15:46:32 :) 15:46:47 I was thinking Alma Cocina 15:47:00 which is close by 15:47:17 wfm. I've never been there. 15:47:32 Alright that is all from me 15:47:42 oh, unless you hae other suggestions 15:47:52 dhellmann: you know the city way better than I do :) 15:48:08 I live far enough away that I don't actually know it that well any more 15:48:13 feels like if we want to avoid shuttling people around town there aren't that many options 15:48:25 yeah 15:48:57 we're not going to want to deal with going to far by car anyway, due to weekday traffic 15:49:10 although by dinner it may be better 15:49:28 it looks like that's the last formal topic on the agenda 15:49:31 #topic open discussion 15:49:38 does anyone have anything else to bring up? 15:49:53 nope 15:50:06 https://review.openstack.org/435500 sets Pike to "under development" 15:50:18 * dhellmann opens in the background 15:50:32 dhellmann: when do you get in ? Late on Sunday I assume ? 15:50:41 if that's it, I think we can close early 15:50:51 ttx: I'm driving in, so I can come in any time after lunch 15:51:00 safe travels everyone! 15:51:03 about the only venues i'm familiar with in atlanta are in little five points, which is a bit of a haul (that area has a pretty decent nightclub/bar scene though) 15:51:21 fungi : ++ 15:51:25 see everyone next week! 15:51:35 see you next week! 15:51:42 #endmeeting