19:00:00 #startmeeting releaseteam 19:00:01 Meeting started Thu May 16 19:00:00 2019 UTC and is due to finish in 60 minutes. The chair is tonyb. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:05 The meeting name has been set to 'releaseteam' 19:00:14 o/ 19:00:17 ttx dhellmann diablo_rojo hberaud evrardjp fungi armstrong: Release team meeting is starting 19:00:22 o/ 19:00:34 Sean McGinnis proposed openstack/releases master: [monasca] final releases for pike https://review.opendev.org/652854 19:00:42 * tonyb will point out that the start time was "Thu May 16 19:00:00 2019 UTC" #nailedit! 19:00:45 Tests took 30 seconds too long. 19:00:53 Haha, nice! 19:01:15 smcginnis: gotta take the wins ;P 19:01:20 o/ (but commuting back home so that I can have my laptop) 19:01:25 o/ 19:01:48 o/ 19:02:11 ttx: has (as always) set us up with a good agenda 19:03:34 okay let's start 19:03:52 #topic Confirm task assignments from https://etherpad.openstack.org/p/relmgmt-train-ptg 19:04:10 So there were a fez open question marks on last week assignment exercise 19:04:22 few* 19:04:32 Yup we have evrardjp here today so ... 19:04:43 * smcginnis wants an official release team fez 19:04:44 On the process changes we had to complete by train-1... 19:04:47 So we can assign him a bunch of stuff. 19:04:56 Do stable autoreleases around milestones: evrardjp? 19:05:02 Track release liaisons in deliverable files: diablo_rojo? 19:05:04 * diablo_rojo_phon agrees with smcginnis's fez idea 19:05:12 Yeah I can take that one. 19:05:26 I was thinking he can let us know his capacaity but sure we can just give it all to him ;P 19:06:03 haha 19:06:18 evrardjp: are you ok with driving that change? 19:06:21 I am not yet sure if I can take this, tbh. 19:06:31 s/yet// 19:06:42 do we have anyone else who could take it? needs to be completed soon enough 19:06:56 that's the problem for me 19:06:59 I can't, my travel schedule in crazy in june 19:07:25 I can do the scripting side of things but the hard part is looking at each deliverable and making the call on if it needs to be released 19:07:34 I'm hesitant to sign up for anything because I'm not sure how much time I am going to have to devote to things soon, but I'm willing to help someone else. 19:07:36 ttx: I did notcie that ;P 19:07:40 t-1 is in 3 weeks 19:07:51 I mean it's also crazy in May 19:08:10 tonyb: I had looked at making the scripting interactive where it could print out the changes, then you y/n whether anything requires a release. 19:08:10 come to think of it, July is not really better :| 19:08:23 ....I could maybe take it. With help. 19:08:28 My June doesn't suck. 19:08:33 Just the rest of this month. 19:08:41 lucky you 19:08:52 I think you're traveling too much :/ 19:08:54 hmm, do we NEED to have it done by train-1? 19:09:03 ttx: I was just going to ask that 19:09:15 I said t1 because we kinda wanted to do that milestone in autorelease 19:09:32 not really on-topic, but tonyb mentioned a great meeting agenda just didn't link to it (and the irc-meetings data doesn't include one either)... can haz link? 19:09:34 it was a preety soft "lets do it at this time" rather than a hard "it must be done" 19:09:35 but I guess we could also not do anything for t1 19:09:54 We can work on it this cycle and put that 'in prod' for next ? ;) 19:10:00 fungi: sorry 19:10:04 #link https://etherpad.openstack.org/p/train-relmgt-tracking 19:10:08 thanks! 19:10:08 s/train-1/as soon as possible/ 19:10:10 evrardjp: we ship to prod here 19:10:12 Line 134'ish 19:10:32 :) 19:10:40 evrardjp: could you take it if it was a t2 thing? 19:10:59 (July 24) 19:11:12 probably the same as t1 19:11:29 so I would say no. 19:11:47 but after it looks better 19:11:58 "theoretically " 19:12:06 smcginnis: could you mentor diablo_rojo through it ? 19:12:10 sorry :/ 19:12:55 evrardjp: It's all good. 19:13:16 evrardjp: You can make it up to us later ;P 19:13:34 :) 19:13:35 ttx: Sure, I can help. 19:13:57 smcginnis: thanks 19:14:03 OK so I'll move that task on the PTG doc to t2 and make it diablo_rojo mentored by smcginnis 19:14:40 thx ttx 19:14:42 If we did it for T1 what's the actual date on that? 19:14:52 that'll mean we can use the liasion stuff diablo_rojo_phon is doing/will do 19:14:58 before June 6 19:15:37 I mean you can always finish before 19:15:38 smcginnis if you're free the fee days leading up to that I think we can have it done then. 19:15:46 *few 19:16:12 We can also start with a crawl, walk, run approach and start semi-manual/semi-automated and work towards complete(r) automation later. 19:16:14 * tonyb likes smcginnis idea to add '--interactive' to new-release which will help with this 19:16:18 We also had a must-do improvement 19:16:26 Add a tool script for producing the list of intermediary deliverables that have not released 19:16:38 I'll do that one if nobody else wants it 19:16:42 tonyb : agreed 19:17:00 That one is basically a wrapper around the existing commands to make the task easier, right? 19:17:01 ttx: I think it's yours ;P 19:17:08 smcginnis: I guess 19:17:14 Going once, going twice, sold to ttx 19:17:19 haven't looked :) 19:17:46 smcginnis: I like your style 19:17:52 ;) 19:18:07 ok, I have nothing more on this topic 19:18:12 tonyb , smcginnis : regarding the interactive mode, harlowja built a tool like that in the repo already (don't remember the name, but look at the list of cli apps in setup.cfg) 19:18:34 I think it's out of date, but it should be possible to update it 19:18:40 or at least crib from it to update new-release 19:18:42 dhellmann: Yup I do recall that 19:18:43 That would be great to have a starting point. 19:19:10 interactive-release ? 19:19:19 probably 19:19:26 Huh, would you look at that. :) 19:19:53 Might be worth doing an inventory of all our commands and tools and get that all in once place with short descriptions. 19:20:02 s/once/one/ 19:20:06 I thought we had that in the readme, too, but maybe not 19:20:14 It's in the readme 19:20:15 that's probably out of date, too 19:20:25 I think we do for the tools we want others to use. Maybe not. 19:20:32 man, the old release team was really a bunch of slackers 19:20:36 Yeah, likely could use a refresh at any rate. 19:20:41 Hah! 19:20:46 dhellmann: haha 19:20:48 especially the last 3 PTLs 19:20:50 Okay I'll do that 19:21:30 at least those PTLs could send email on time .. this new PTL ... what a schmuck! 19:21:38 Hah!! 19:21:40 now onto pike-em fun 19:21:49 email on time or meeting on time, pick one 19:22:01 hehe 19:22:08 :) 19:22:09 tonyb: To be fair, I think it took me a few weeks to get into the habit. 19:22:33 smcginnis: I'll take it 19:22:43 #topic pike-em 19:23:00 Monasca should be ready to go now. Then we just need to update the pike-em tagging patch. 19:23:14 * ttx fetches a drink 19:23:14 I emailed the four PTLs/liaisons. 19:23:22 Awesome! 19:23:37 Yeah, a few of them have shown more attention the last few days, so that has helped. 19:24:01 Looks like tripleo is released we just need the pike-em tag 19:24:04 Tricircle is stuck pending an update for the sphinx requirements that's blocking the README fixes needed. 19:24:09 Glad it want wasted effort :) 19:24:28 I think I just pushed tripleo a little earlier. 19:24:43 yup saw that :) thanks smcginnis 19:25:04 We have monasca (ready), tricircle, and puppet. 19:25:23 so how much longer do we give tricircle or puppet? 19:25:51 and heat is a whole other question 19:26:14 A couple heat and ansible issues that are bigger. 19:26:18 we did say today we'd just tag the existing releases as pike-em and declare it done 19:26:27 ansible ? 19:26:32 diablo_rojo_phon: Is that what you communicated? ^^ 19:26:36 Yeah. 19:26:49 I said if there was no action by today we'd just tag them 19:26:51 something new I should be aware ? 19:27:05 evrardjp: https://etherpad.openstack.org/p/train-relmgt-tracking Line 118 19:27:09 evrardjp: Links to failures in the etherpad, but os_molteniron had a releasenotes job failure and python-pankoclient had a tagging failure. 19:27:44 The python-pankoclient failure is a bit odd. 19:28:35 Umm yeah that is odd 19:28:36 I see, it's probably with the fact we discussed retiring this repo 19:28:46 but it isn't retired yet 19:29:02 So maybe both of those are safe to ignore and we can just do the final taggin? 19:29:06 g 19:29:23 Err, wait. I think these were on the final taggin. 19:29:29 I can't judge for pankoclient 19:29:30 Gah, can't spell ing. 19:29:51 smcginnis: yeah I think at least pankoclient was the pike-em tag 19:30:13 smcginnis: and the tag is in that repo 19:30:13 were there any failures associated with the zuul artifacts issue yesterday which need to be rerun? we had to dequeue some refs, i think tripleo-ui at a minimum 19:30:28 fungi: None I've seen. 19:30:37 os_molteniron has the pike-em tag too. 19:30:39 So I guess we're good. 19:30:50 fungi: like what smcginnis said ;P 19:31:12 So Heat's the big question mark at this point. 19:31:18 yeah 19:31:21 But also maybe something we can just ignore and move on. 19:31:32 we can fix it but that kinda means a new release 19:32:00 I kinda think just declare pike-em done ... with some issues and aim for better with queens 19:32:13 I'm fine with that. 19:32:28 which *should* be better if we do the automatic releases we disussed 19:32:32 We'll hit this with queens too, so either we need to get them to do some work, or we can just expect it and ignore it again. 19:32:42 ++ 19:32:44 what's the story with heat? is there something blocking the name change? 19:32:49 less bitrot anyway, and less delta from the last release 19:33:19 dhellmann: They changed from heat to openstack-heat in later (sooner?) branches, but didn't go back to pike and queens with those updates. 19:33:29 yeah, so they just need to fix that, right? 19:33:32 dhellmann: I don't think it's blocked just hasn't been done 19:33:38 ok 19:33:39 dhellmann: Yup 19:33:41 That would make things a little easier. 19:33:44 as long as it's just a matter of not doing it 19:33:57 tell them there won't be any new releases from any branch until that's done :-) 19:34:05 dhellmann: ;P 19:34:57 Haha :) 19:35:57 or, you know, make the validation job report that failure 19:36:01 do what you have to 19:37:16 that doesn't sounds like a problem a little socialization wouldn't fix 19:37:29 dhellmann: validation is already failing 19:38:08 tonyb : yeah, I was making a joke about having it fail on master, too 19:38:13 "all branches must be publishable" 19:38:26 evrardjp: I think the only tension really is our desire to get the pike-em stuff off the plate and the (probably small) delays that fixinx it in heat will take 19:38:54 makes sense 19:38:55 the heat team is alsmost certainly okay with it and has been pretty responsive 19:39:03 dhellmann: ahh sorry I missed it ;P 19:40:53 Let's just fix queens and declare pike done, as per the email diablo_rojo_phon sent 19:41:15 it's a little unfair to heat but then we can put pike behind us 19:41:25 ++ 19:41:33 Works for me. 19:42:01 okay moving on 19:42:02 So just to make sure I have the plan, drop any outstanding final releases (other than Monasca that is ready to go) and update the pike-em patches to just use the last successfully release versions. 19:42:06 Right? 19:42:13 #topic Do we want to add per-projects links for Feature freeze 19:42:18 smcginnis: correct 19:42:38 so on $topic 19:42:43 I raised this one on a few reviews of project specific deadlines. 19:42:57 A few have added $project Feature Freeze on the overall feature freeze week. 19:43:12 So.. a bit redundant IMO as that applies to everyone already. 19:43:31 yup 19:43:53 I'd say unless they have a specific thing it's not worth mentioning each 19:43:54 I think if it's different than the official feature freeze (like being earlier) it would be fine. 19:44:05 But it doesn't make sense to restate what is already there. 19:44:10 Yeah, earlier is good and should definitely be called out. 19:44:21 So everyone OK if I put up a patch to remove those? 19:44:40 Fine by me. 19:44:50 We could even still leave the text descriptions in under the project section, just not have them linked from the weekly table. 19:45:01 smcginnis: yup 19:45:20 OK, I'll take that action then if no one is against the idea. 19:45:55 smcginnis: all yours 19:46:11 #topic openstack-manuals owned by releases team? 19:46:17 I added this one. 19:46:44 Not sure if folks saw, but there's been a lot of conversation on the ML and in the -tc channel about the idea of getting rid of the docs team. 19:47:10 * tonyb missed the chatter but saw the reviews 19:47:11 And one idea raised was whether it made sense to move openstack-manuals under the release team since it is now just a coordinating spot for docs. 19:47:29 And there's just some procedural stuff that needs to happen around release time. 19:47:42 Other than some tooling that other folks sound willing to still maintain. 19:48:05 So just wanted to raise it here to get folks thinking about it, pro or con, in case that developed more. 19:48:17 I'm not sure what my opinion is yet. :) 19:49:06 I haven't checked the review, but I more or less said openstack-manuals should be owned by a project team, realeases the least worse 19:49:42 I guess it kinda makes logical sense to live under us. 19:50:06 If the mainenance needed is all around release cycles, then yes it makes sense 19:50:51 I know we have items around release time that we corordinate with them, but that isn't all of it 19:50:55 I think I'd like to understand a little more of what that team currently does throughout the cycle to make sure we don't sign up for too much should the existing docs folks get pulled away. 19:51:06 for example I recent;y added the EM SIG to the site 19:51:28 Could make them like a sub team? 19:51:37 that's very "not releases", and I'd be pretty uncomfortable owning that side of things 19:51:40 smcginnis +1 19:51:53 so as long as we can keep some of the existing core team ... 19:52:30 yes I feel like I'm missing details on what it would take to handle that 19:52:52 okay, so who wants to run that investigation? 19:53:04 * tonyb kinda looks at TC memebers ;P 19:53:12 oh look we have a few of those ;P 19:53:16 I think dhellmann has a better understanding than most of what is involved 19:53:28 and we need to make a decision soon enough 19:53:37 I think I'm leaning towards rather still having a docs team and stepping in if Stephen just doesn't want to be the PTL for it. 19:53:49 Not to interrupt but I wanted to mention that gerrit replication has caught up so it should be safe to do release work again (thank you for your patience) 19:53:58 \o/ 19:54:00 clarkb: Thanks! 19:54:05 clarkb: \o/ 19:55:21 I'd rathre keep the docs team too but that doens't seem to the be the direction the docs team is going 19:56:57 ok no time left so let's iterate on that review 19:57:04 okay 19:57:11 last item shoudl be quick 19:57:18 #topic meeting next week 19:57:51 many of y'all are in BCN next week and I assume will not be wanting to have an IRC meeting at 2000 on Thursday 19:57:53 Most of us will be out. 19:57:56 so cancel it? 19:58:24 that has the benfit that I get an extra hours sleep ;P 19:58:36 Then I'm in favor of cancelling. :) 19:58:41 \o/ 19:58:59 y'all can have an in bar^wperson meeting instead 19:58:59 yes cancel 19:59:07 I'll be on a plane anyway 19:59:12 pfft 19:59:26 okay I think we're done here 19:59:33 thanks everyone 19:59:40 the sort of plane that does not have wifi 20:00:00 #endmeeting