16:00:32 #startmeeting releaseteam 16:00:37 Meeting started Thu Apr 16 16:00:32 2020 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:40 The meeting name has been set to 'releaseteam' 16:00:41 Ping list: ttx armstrong diablo_rojo, diablo_rojo_phon 16:00:53 Board meeting is still going on, so we wait a bit for everyone to join. 16:00:55 o/ 16:00:57 o/ 16:01:12 #link https://etherpad.opendev.org/p/ussuri-relmgt-tracking Agenda 16:01:45 o/ 16:01:54 o/ 16:02:13 #topic Review week tasks completion 16:02:31 First in the list - process any remaining client lib freeze exceptions 16:02:43 This went well. Most things were done last week. A few FFE's this week. 16:02:53 The one outstanding one is python-monascaclient. 16:03:19 Waiting to hear back on that one, but from looking at open reviews, I'm not sure what it's holding on. 16:03:27 Hopefully we have more clarity on that soon. 16:03:32 waiting for tc approval 16:03:35 err ptl 16:04:01 Yep. They wanted to wait though, so that's the part I wasn't sure about. I don't know what they are waiting for based on what is out there. 16:04:05 maybe we should ping witek 16:04:31 He did respond on the patch this morning. I left a comment after that, but no response yet. 16:04:36 or ask on their channel 16:05:01 If I don't hear anything by tomorrow, I will try to track people down. 16:05:12 Unless anyone else has the time to do something before then. 16:05:46 Next in the task list - Freeze all cycle-based library releases except for release-critical bugs 16:06:12 So reminder to everyone, please do not approve any new lib releases without a reference to an approved requirements FFE on the ML. 16:06:26 Next - stable branch creation. 16:06:30 Those should all be done. 16:06:34 noted 16:06:49 List cycle with intermediary deliverables that have not been refreshed in the last 2 months. 16:07:00 I can ping witek tomorrow morning if there is no answer on it. (Sorry for the delay). 16:07:07 I generated that list and posted to the ML, tagging each project that was listed. 16:07:18 evrardjp: That would be great! Your timezone may be better for that too. 16:07:26 precisely why I propose 16:07:43 Thanks, much appreciated. 16:07:58 I did get one response on the ML post. 16:08:31 Only thing was to drop barbican-ui, which has now been done. 16:09:47 A few ironic ones in the list. That's a little concerning, but I think the team usually gets things wrapped up by RC1 time, so I'm not too concerned. 16:10:14 #link http://lists.openstack.org/pipermail/openstack-discuss/2020-April/014084.html 16:10:22 Probably should have posted that right away for reference. 16:10:45 thanks :) 16:10:46 A lot of *-ui that need to wait for late in the cycle for horizon changes too. 16:10:57 So overall, several things in the list, but nothing that looks scary yet. 16:11:03 ++ 16:11:28 Final task is the countdown email. Will send tomorrow as usual. 16:11:36 #topic Assign next week tasks 16:11:38 any news from swift? Maybe they are super busy and it might be worth double pinging 16:11:57 * evrardjp is overly careful 16:11:58 they are usually not the ones missing the deadlines 16:12:07 I don't disagree 16:12:11 No word, but Tim has been around and I know they are pretty good about it. 16:12:28 Though now with Nvidia, it's probably true that they are super busy. 16:12:35 Yeah I generally trust them, but exactly 16:12:57 there might be an exceptional circumstance around 16:13:08 I guess let's not speculate 16:13:09 :) 16:13:26 Tim has been around. If it's getting close and we don't see anything, pretty sure it won't be hard to check on status. 16:13:31 So next week... 16:13:32 Process any remaining library branching exception. 16:13:41 This is an "all" task. 16:13:58 ok 16:14:01 generate release requests for all deliverables that have do not have a suitable Ussuri candidate yet 16:14:08 I can take that one. 16:14:10 I agree some deliverables in this list are definitely more important than others 16:14:23 so worth double-pinging 16:14:40 I'll reply with a reminder. 16:14:57 good to ping here if they are around 16:15:11 timburke: ^ 16:15:41 o/ 16:16:14 on my radar ;-) 16:16:54 timburke: awesome 16:16:59 Thanks timburke 16:17:22 OK, only other task next week is the countdown email. 16:17:32 between changing jobs and becoming a part-time childcare worker, time has a way of getting away from me lately 16:17:38 no kidding 16:17:55 Are we sure it's correctly indented smcginnis ? Sounds like it could be spread with more people, assuming they are available :D 16:17:58 no, that's the trouble -- too many kids :P 16:18:09 timburke: :D 16:18:19 timburke: :) 16:18:46 evrardjp: There are several subtasks as part of that, mostly to call out the differences with different release-models. 16:19:09 (I was thinking of the work between tuesday and thursday that might be an _all_ thing) 16:19:10 But I guess things like "Between Tuesday and Thursday, merge as soon as possible the patches that get +1 from the PTL or the release liaison." can be flagged as a task for all. 16:19:31 yeah, sorry for being a little bit pedantic there 16:19:36 OK, I broke that out to make it clear. 16:19:51 it's just to highlight to myself that I need to work on this :D 16:20:02 anyway, sorry for derailing again. 16:20:23 No, please do point out anything missed or that needs more focus. 16:20:38 #topic Virtual PTG planning 16:20:39 yes task for all 16:21:07 ttx: Do you happen to have that ethercalc link handy? 16:21:09 I think it would be good to discuss evolutions of release models, for sure 16:21:11 no 16:21:25 also multiplexing with another meeting :) 16:21:37 I can get it. Uno momento. 16:21:45 re: timeblock, EU+US sounds like our sweet spot 16:21:45 Got it 16:21:54 not sure how much time we want tho 16:21:56 #link https://ethercalc.openstack.org/126u8ek25noy Virtual PTG planning ethercalc 16:22:04 Bah. Second too slow. 16:22:08 I'd keep it relatively short and follow up through email 16:22:12 diablo_rojo: :) 16:22:21 ttx: I agree/ 16:22:36 One hour block or two - what do people feel like we need? 16:22:45 two I'd say 16:22:49 Or more, if you feel we should have more sync time. 16:22:49 can end early 16:22:55 That works for me. 16:23:23 This is all virtual too, so no reason we can't find some other time that we are free to follow up on anything we couldn't in the timeblock. 16:23:42 yeah, 2 hours sounds like a good middle ground 16:23:48 Agreed. Two hours sounds good as a start. 16:23:54 Should I do a doodle poll or something to see what times work best for the group? 16:24:18 Another option would be to just target this timeslot. 16:24:26 And either start an hour earlier or an hour later. 16:24:35 Not like anyone will be traveling. 16:24:42 or wait until everyone else makes their move 16:24:59 (everyone's favorite Neptune's pride tactic) 16:25:19 Good strategy too. We can just fill in after we all know what our other time commitements are. 16:25:26 I suppose none of them will allow for like.. smcginnis, tonyb, and ttx to all be there at at the same time. 16:25:48 yes tony will be the outlier 16:25:49 not without substantial loss of sleep anyway 16:25:50 The ttx to tonyb timespan makes it difficult, but it's possible. 16:26:01 (I am happy to take a sleep hit, but the rest of you all have children and families) 16:26:02 hberaud and jp are in EU too 16:26:02 Someone would have to stay up late or get up early. 16:26:09 We actually outnumber y'all! 16:26:21 ttx, that is a good point. 16:26:25 Maybe we should doodle poll? 16:26:30 or framadate 16:26:32 +1 16:26:32 or whatever 16:26:35 Yeah, so due to gravity, tonyb would be the one that would likely have to take the hit if we wanted to all get together. 16:26:37 and fungi lives in UTC 16:26:43 :) 16:26:51 My what that must be like. 16:26:53 i only enter low-power standby mode when my batteries run out 16:27:13 Such efficiency. 16:27:25 not really, i have some worn-out batteries 16:27:47 fungi, they don't make replaceable ones anymore for your model? 16:28:11 i occasionally find a few used on ebay 16:28:14 diablo_rojo: fungi: haha that made me smile 16:28:32 fungi: what's the shape of the bottle? 16:28:42 sorry. I mean, the shape of the charger 16:28:50 ;) 16:29:10 OK, I propose we follow what ttx suggested and let other teams form their schedules for the PTG, then see what works well for us to fit in once we all know what our other time constraints are. 16:29:22 Works for me 16:29:23 At least I think that is what ttx suggested. Feel free to correct me. :) 16:29:41 ++ 16:29:56 Either it will be obvious, or if not, then we can do a poll to find the best option. 16:30:51 #topic Review countdown email 16:31:12 I think I got the right draft this time. :D 16:31:15 #link https://etherpad.opendev.org/p/relmgmt-weekly-emails 16:31:25 added virtual ptg to it 16:31:32 Oh, perfect. 16:32:54 We had pretty much reviewed the draft last week before realizing I skipped a week. So looks good to me. 16:33:25 Just update or let me know if there are any changes before tomorrow ~13 UTC or so when I will send it out. 16:33:51 #topic Open discussion 16:34:47 I wanted to point out that https://review.opendev.org/#/c/719311/ merged to try to speed up docs builds. 16:34:59 nice 16:35:02 That should be fine, but if anyone notices anything odd with doc output, please let me know. 16:35:07 do we have evidence of a speedup? 16:35:12 oh nice indeed 16:35:15 Like in the build job history in zuul? 16:35:30 if not faster, I would revert to be nicer to our noisy neighbors 16:35:39 haha 16:35:41 I haven't checked all, but based on the zuul build timing, it looks like doc builds were usually around 10-15 minutes, now closer to 9. 16:35:51 protip: don't tell them they are noisy 16:35:58 that topic name though! 16:36:00 So not huge, but especially during deadline crunch maybe it will add up. 16:36:08 evrardjp: ;) 16:36:45 ttx: In reality it doesn't really load all cores, so I don't think it would benefit noisy neighbors much. 16:37:37 I tried other approaches like making our closed series pages static, but that didn't really make any difference. I think our bottlenecks are in the schedule directives and then just plain sphinx processing. 16:38:37 I have a suspicion that our shelling out to run git commands to get last modified time for schedule source slows things down, but didn't have the bandwidth to dig into dulwich usage to see if there was a more efficient way to get commit time. 16:39:11 Anyway, just an itch I felt like scratching at the time. Main point being awareness that something has changed there in case multithreading causes issues. 16:39:14 Anything else for today? 16:39:34 nothing 16:39:52 I am no specialist on dulwich, I know I don't really like it or didn't like it last time I was needing it 16:39:56 :p 16:40:01 :) 16:40:49 OK, I think we can wrap then. Thanks everyone! 16:40:55 #endmeeting