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