16:00:13 #startmeeting releaseteam 16:00:13 Meeting started Thu Apr 11 16:00:13 2019 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:16 The meeting name has been set to 'releaseteam' 16:00:19 Ping list: smcginnis ttx dhellmann diablo_rojo hberaud evrardjp fungi armstrong 16:00:25 o/ 16:00:28 #link https://etherpad.openstack.org/p/stein-relmgt-tracking Agenda 16:00:32 o/ 16:00:37 aloha 16:00:40 o/ 16:00:58 #topic Release Postmortem 16:01:04 o/ 16:01:32 Any objection to approving https://review.openstack.org/#/c/650173 now? 16:01:34 I think overall the final release went well. A few items yet to wrap up. 16:01:46 evrardjp had a comment on there. 16:02:05 These were supposed to have happened with the final cwi release, so I don't think we need to wait for any PTLs on that. 16:02:06 it's fine 16:02:11 ++ 16:02:19 yeah we don't need to wait 16:02:27 smcginnis: you do it or should i? 16:02:31 I am not sure why I am always careful in those branching cases :) 16:02:39 ttx: Feel free to take care of that. 16:02:50 done 16:03:09 evrardjp: It's good to be careful earlier on. Really a pain if your repo gets branched and suddenly you realize you need to backport a bunch of things in a time crunch. 16:03:12 At this point though... 16:03:29 next up is two release page cleanups 16:03:49 I can approve those. Unless dhellmann wanted a chance to look? 16:04:16 #link https://review.openstack.org/#/c/651551/ 16:04:21 #link https://review.openstack.org/#/c/651549/ 16:05:05 OK, I'll approve. 16:05:32 ttx: Want to talk about Post-release tasks? 16:05:58 sure 16:06:16 there were a couple lines above though 16:06:30 Are we all done ? 16:06:32 Anything missing in the process ? 16:06:51 Oh, stable/stein releases. Sorry, I skipped that. We can circle back. 16:07:06 I do think we are ready to init-series for train. 16:07:27 I can grab that unless anyone else wants it. 16:07:28 yeah... 16:07:34 Once the stable branch process 16:07:46 Yeah 16:07:49 I mean https://review.openstack.org/#/c/650173/ is in 16:07:51 I would prefer if you could do it smcginnis , as I am on holiday tomorrow and next week 16:07:58 was the tripleo team ready for branches yet? 16:08:08 evrardjp: ack 16:08:13 dhellmann: those were cwi ones 16:08:17 ok 16:08:54 We haven't done any cycle-trailing ones yet. Well, "we" haven't. I think one or two have been done by those teams. 16:08:55 maybe was oversight though. We'll soon know 16:10:00 So yes, init-series once the stable branches are all in 16:10:14 OK, back to the stable/stein releases? 16:10:14 then we have a few stalled requests 16:10:24 python-searchlightclient 1.5.1 https://review.openstack.org/#/c/649487/ 16:10:26 python-cloudkittyclient 2.1.1 https://review.openstack.org/#/c/650239/ 16:10:35 that we can now unblock. Could also wait for Monday 16:10:44 but I see no reason why 16:10:57 I think it would be fine to do it nowadays? 16:11:01 Neither assert stable:follows-policy 16:11:10 yeah, I'm in favor of going ahead, assuming the releases look right 16:11:22 Since they were caught in the end of cycle freeze, migh be good to get them out right away. 16:11:22 ofc 16:11:30 ++ 16:11:34 I can push it 16:11:54 done 16:12:09 OK, on to ocata EM. 16:12:31 I broke out the openstack-ansible ones from the main patch. Since they always have to be so difficult. :P 16:12:40 ha! 16:12:41 https://review.openstack.org/#/c/650467/ and https://review.openstack.org/#/c/651778/ 16:13:13 We switched to EM about a year ago. But the docs said we would tag them but we never did that part. 16:13:13 did we tag one final release on all of those before the em? or are we assuming that whatever was there is good enough? 16:13:30 I think we had declared them EM, just never tagged them. 16:13:38 IIRC, it was on the ML. 16:13:53 what I mean is, are we tagging at a point that means we have unreleased changes in any of those branches? 16:14:42 yes that is the big question 16:14:48 I did not check, but we had already said we would not be doing any more releases at this point. So if there are, I would consider those commits as part of that extended maintenance work. 16:15:00 that makes sense 16:15:09 it's not lost. It's just EM 16:15:23 ok 16:15:41 just thinking through what we discussed the other day on the review for changes to the tool that adds the tags 16:15:43 it's kinda weird for OSA though, because we are tagging really old things. 16:15:58 I have to think about that 16:16:12 dhellmann: That was updated to tag -eol at the latest commit and not that last tag's commit. 16:16:31 yeah, we also discussed the em tagging policy in there 16:16:33 evrardjp: Yeah, all of these are really old at this point. 16:16:57 Since we can't release once we are in em, I think the em tag needs to be at the final release. 16:17:03 the osa case is definitely unique. I wonder if we need an em policy setting, like we have for branching, to tell us the type of location allowed 16:17:09 Merged openstack/releases master: Add missing stable/stein branches https://review.openstack.org/650173 16:17:10 Merged openstack/releases master: Clean up failed releases https://review.openstack.org/651549 16:17:10 or at least whether to use HEAD or $last-tag 16:17:12 Merged openstack/releases master: Do not generate tarball links for tripleo-ui https://review.openstack.org/651551 16:17:14 Anything after that point is unreleasable. 16:17:36 If we tag em a few commits after the last release, those commits are kind of in a limbo. 16:17:44 I agree, mostly, that em should tag the latest release. I'm not sure we want to tag ancient releases, though. 16:18:00 osa is very weird because also we stopped tagging because the people stopped caring. But sending and EM to these old versions send a wrong message IMO 16:18:09 right 16:18:14 while the openstack-ansible repo one is correct 16:18:31 I will request a release tomorrow latest for just this branch, if it's fine with everyone 16:18:45 so that we can use those new shas for em 16:18:48 at some point osa won't even have tags on some of those repos, so we need to think about how to handle that case 16:18:49 sorry for being late 16:18:53 smcginnis: you were right about them being difficult :P 16:18:59 ttx: :D 16:19:00 So I would abandon the osa one I have, then you would propose one just for the single repo evrardjp? 16:19:09 smcginnis: correct 16:19:09 ttx: ;) 16:19:29 OK, that works for me. 16:19:30 I think we want to tag all the osa repos. The main one should be tagged at its most recent release. The others should be tagged at their HEAD. 16:20:00 I would still think their last tag, not HEAD. 16:20:01 dhellmann: correct 16:20:09 when stein (or train) goes EM, those OSA repos won't have any version tags at all but we still want to tag them EM 16:20:20 because we're no longer tagging versions in some of those repos 16:20:35 that's my plan, create a late release with HEAD on those repos, and then use those for EM 16:20:36 If a repo doesn't have tags, then I don't think it needs -em. 16:20:47 smcginnis: but they had tags :) 16:20:54 hmm 16:21:10 In the case of ocata, it doesn't seem right to tag a point -em if it hasn't been "released". 16:21:15 I guess I thought we wanted to mark everything at once, but if we don't care about marking tagless repos then mayb enot 16:21:22 it has been released, though 16:21:24 Once we get to the point where there were no releases done at all, I don't think we need an em tag. 16:21:33 the fact that there's no tag doesn't mean it isn't released in this case 16:21:48 it is effectively "vendored" in that main repo 16:22:01 because that includes the SHA of the commit from each of the other repos to use 16:22:02 yeah, so what we could do is to just EM the openstack-ansible repo 16:22:07 yeah, ok 16:22:10 that would be enough too 16:22:21 because it doesn't set a wrong expectations in the roles 16:22:25 Merged openstack/releases master: Release python-searchlight client 1.5.1 for stein https://review.openstack.org/649487 16:22:26 (other repos) 16:22:26 Merged openstack/releases master: Releasing python-cloudkittyclient 2.1.1 https://review.openstack.org/650239 16:22:30 openstack-ansible controls what from those other repos is used, right? 16:22:35 correct 16:22:46 Yeah, then I would think we would only tag openstack-ansible. 16:22:51 and we are not using tags. 16:23:08 what is the point of adding the em tags at all? it's to communicate that the *repo* is closed to certain types of changes and to releases, right? 16:23:21 yes 16:23:32 so this is why I think the em tags still apply in this case dhellmann 16:23:43 so if we don't tag all of the repos, we're not sending the message about being closed to certain types of changes in those repos 16:23:52 so two choices: either just do openstack/openstack-ansible as EM and ignore the rest, or do everything on all repos. 16:24:03 or to the testing requirements, or whatever else we're changing for that repo when we go to em 16:24:25 I think we should tag them all, but I don't feel strongly enough about it to fix the tool to let us do that, so :-) 16:24:29 I believe it's semantically more correct to do what dhellmann said and propose earlier 16:24:50 dhellmann: but can't I propose a last minute release before we do EM? 16:25:11 So if release-model:untagged, the tool should grab HEAD. Otherwise, use the commit from the last release. Does that make sense? 16:25:12 that only helps if you tag all of the repos. which I guess would be another approach 16:25:24 smcginnis : yeah, that's effectively what I'm saying 16:25:27 evrardjp: Not for ocata. It is already in em. 16:25:39 smcginnis: I see, I missed the timeframe 16:25:40 We just never followed through with the tagging. 16:25:45 Pike on the other hand... 16:26:01 That was supposed to have transitioned at the beginning of March, but we have a little time yet. 16:26:29 dhellmann: OK, I'll put it on my todo to update the new-release tool to handle that for the future. 16:26:40 k 16:27:06 I think that's fair 16:27:14 So I will abandon my osa tagging patch for now. evrardjp will follow up with the "correct" tagging for those repos. 16:27:20 I am sorry to say that ttx prophecy was correct 16:27:30 hehe 16:29:06 OK, one more monkey wrench. 16:29:21 openstack-ansible ocata was not tagless. Still allow it? 16:29:40 allow? 16:30:14 If we tag HEAD for tagless and last release otherwise, at least as of the state during ocata, what I have up there now is "correct". 16:30:32 But knowing those eventually ended up tagless, we could retroactively apply that to ocata. 16:31:18 if all the repos were always tagged for ocata, we should use the tags. but iirc, that was when we did this transition? so in that case I think we want to recon it 16:31:23 er, retcon 16:31:53 I am not sure when we did this, it was in the MLs. At that time we said we couldn't touch the deliverables files though 16:32:20 so we couldn't remove all the repos from those older branches 16:32:46 The solution was, for the future, create a tagless file for the future 16:33:02 OK, let's just stick with that last plan. I've abandoned mine. evrardjp can propose a new one treating those other repos as tagless. 16:33:19 but because we didn't touch the old deliverables files, we just said to "just not tag there" 16:33:57 I don't like us to be _special_ 16:34:00 looking at that deliverable file, I see all the repos being tagged up to 15.1.21, and then only openstack/openstack-ansible being tagged after that 16:34:10 And now we have validation that complains if you try to do a release and don't include all repos. But that should be fine if you tag HEAD for the ones not released. Just takes a little manual editing. 16:34:15 so it's probably in that two week window dhellmann 16:34:33 yeah 16:34:36 openstack-ansible is ... special, Mrs. Gump. 16:34:45 :D 16:34:48 ttx: :) 16:34:55 Run ttx , run 16:35:16 Are any of the other deliverables in https://review.openstack.org/#/c/650467/ as "special" as osa? :) 16:35:37 https://media.giphy.com/media/3oriNLnYCrAj1Rg7qE/giphy.gif 16:35:51 I think osa is the only snowflake for this case 16:36:13 So then we should be able to finish that tagging for the rest of those. 16:36:21 +1 16:36:28 agreed 16:36:42 ++ 16:36:50 I'll leave it up to y'all to +2+W that then. ;) 16:36:52 I've +2ed that on faith, smcginnis :-) 16:37:12 hah 16:37:45 #topic Preparing for train 16:38:05 I did ping Tony yesterday about the script we use for setting up the tracking etherpad. 16:38:27 He has that on his todo list to get set up. Checking this morning, looks like it didn't make it to the top of his todo's yet. 16:39:16 When we moved to storyboard for tracking things, we stopped doing the planning etherpad. I did not do one for stein. 16:39:22 I think that has worked out. 16:39:43 do we have a ptg planning etherpad? 16:39:58 or "agenda" or whatever? 16:40:04 We don;t have that yet 16:40:12 I know Tony has mentioned it, but I have not seen one. 16:40:14 ok 16:40:15 But we have a bunch of topics 16:40:22 https://wiki.openstack.org/wiki/PTG/Train/Etherpads <-- according to that not yet 16:40:26 I know we have some things at the bottom of the stein tracking page 16:40:28 at the bottom of https://etherpad.openstack.org/p/stein-relmgt-tracking 16:41:13 (personally I find it good that we don;t have that many things to discuss, means the process is now more solid 16:41:15 I'll throw https://etherpad.openstack.org/p/relmgmt-train-ptg in that wiki list and we can start putting some thing there. 16:41:28 ttx: +1 - less change is good here 16:41:52 I would say let's wait for PTLs/release liaisons feedbacks? 16:41:58 copy pasted 16:42:04 Added to wiki 16:42:13 team team team! 16:42:18 technically cut pasted ;) 16:43:34 #topic PTG org 16:43:45 Notes from Tony in the etherpad. 16:43:54 Friday morning as a meetup time. 16:43:57 +2 for Friday morning 16:43:58 I think that works for me. 16:44:15 I've been mentally blocking actually thinking about my schedule for the week. 16:44:33 smcginnis, lol yeah I bit the bullet and did it a couple days ago 16:44:42 its quite painful 16:44:53 ttx, dhellmann: Do you know if Friday morning will work for your schedules? 16:45:00 I think so 16:45:20 OK, if anyone has a conflict, I guess let Tony know ASAP. 16:45:28 oh, the ptg stuff isn't on my calendar yet. does someone have the link to the schedule handy? 16:45:32 The team photo is also scheduled for Friday morning. 16:45:36 I expect to be spending most of my time with ironic 16:46:08 dhellmann, https://www.openstack.org/ptg#tab_schedule 16:46:19 thanks 16:46:25 no problem :) 16:46:47 OK reorganized topics in a way that makes sense 16:46:47 yeah, I should be available friday morning 16:46:54 Pretty much all teams are meeting Friday. I don't think it's possible not to have conflicts in the 3 days of this event. 16:47:28 Last thing in there, Tony was asking about a team dinner. 16:47:51 I would love it if we can all make it out to a dinner again. 16:48:07 could make for a calm dinner for Friday evening 16:48:09 I think the only set evening plan I have so far is Monday night. 16:48:14 Thursday is the happy hour so we could go to dinner after that, 16:48:17 Friday night should be good for me. 16:48:28 ttx, Friday night is when the game night was gonna maybe be 16:48:33 OOOOH 16:48:38 then no 16:48:38 yeah, small group calm friday or sat after such a long week would be good 16:48:38 I leave Saturday evening, so that's the only PTG night that will not work. 16:48:45 ah 16:48:49 Saturday works for me 16:49:00 Wednesday night? 16:49:07 Thursday night might be a good way to prep for Friday morning. 16:49:49 my dance card is completely empty at this point, so whenever 16:50:02 How about this, each of us add a line under that item in the etherpad with the nights we are available? Then tonyb can figure something out. 16:50:20 ++ 16:50:59 +2 16:51:22 #topic Meeting time 16:51:46 It changes ! 16:51:57 Last thing - I think it is official now. Meeting time will be moving to 1900. 16:52:15 there was a review to change that, right? 16:52:21 Probably about as good as we can get for all the timezones involved. 16:52:25 yes merged now 16:52:26 https://review.openstack.org/#/c/651443/ 16:52:40 some diligent meetings-core person 16:52:45 :) 16:53:02 btw... 16:53:15 if someone else wants to be meetings-core, we recruit 16:53:29 haha 16:53:33 I would imagine that's pretty low volume. 16:53:49 I can try to watch for things there if you want to add me to the list. 16:53:51 It is so awesome you would not believe 16:53:55 :D 16:53:57 ttx: :) 16:54:12 I am wondering what the duties are, with a name like this 16:54:16 ttx, if you want another set of hands you can add me to the list too 16:54:18 meetings-core must attend every meeting though. :) 16:54:41 smcginnis: isn't that what you are already doing? 16:54:44 You don't actually work on any projects, you just attend all of their meetings. 16:54:46 well to be fair, I just process them all when they arrive. Could switch to some recview day set up though 16:54:47 Hah! 16:55:07 ttx: There's check validation that makes sure a propose meeting move doesn't conflict with another meeting ,right? 16:55:07 ttx: bot approval? 16:55:10 let's discuss this outside the meeting? 16:55:15 Yeah 16:55:18 dhellmann: we still check things. 16:55:19 #topic Open floor 16:55:25 Any final things? 16:55:29 none 16:55:38 This will be my last meeting. tonyb will take if from here. 16:55:41 dhellmann: Like if the PTL is the person asking for it, if there was a thread about it, etc 16:55:47 ack 16:56:00 thank you, smcginnis , for taking the helm again this past cycle! 16:56:13 things went quite smoothly, I think 16:56:15 thanks smcginnis for all your hard work :) 16:56:29 Thank you all for all the work this cycle and all the work prior to that that made it easy to step in and figure things out. 16:56:30 I wonder what he will now do with all his free time. Apart from meetings-core 16:56:47 haha 16:57:00 and fearless Board member 16:57:05 OK, I guess we can wrap things up then. Thank you everyone! 16:57:15 #endmeeting