16:00:02 <smcginnis> #startmeeting releaseteam
16:00:03 <openstack> Meeting started Thu Sep  5 16:00:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:06 <openstack> The meeting name has been set to 'releaseteam'
16:00:21 <smcginnis> Ping  ttx dhellmann diablo_rojo hberaud evrardjp armstrong tonyb
16:00:25 <hberaud> o/
16:00:30 <dhellmann> o/
16:00:30 <smcginnis> #link https://etherpad.openstack.org/p/train-relmgt-tracking Agenda
16:00:34 <diablo_rojo> o/
16:00:38 <armstrong> o/
16:00:52 <evrardjp> o/
16:00:55 <ttx> o/
16:01:06 <smcginnis> We are currently on R-6, around line 434 in the etherpad.
16:01:06 * fungi is around for the moment
16:01:17 <ttx> not under water yet
16:01:48 <fungi> well, i relocated to the mountains for a few days. would take some mighty deep water
16:01:59 <ttx> that is a mighty deep hurricane
16:02:03 <smcginnis> fungi: How's the wifi on the mountain? :)
16:02:19 <fungi> better than the cell signal at least
16:02:26 <evrardjp> :)
16:02:42 <smcginnis> #topic Review week tasks completion
16:02:59 <smcginnis> First up was the library releases.
16:02:59 <ttx> I drafted email
16:03:14 <smcginnis> Thanks!
16:03:15 <ttx> Not sure about the other ones as nobody stiked-out them
16:03:25 <smcginnis> We can review the draft as the last topic.
16:03:40 <smcginnis> #link https://review.opendev.org/#/q/status:open+project:openstack/releases+branch:master+topic:train-3
16:03:53 <smcginnis> Looks like we already got a few acks, so that's great to see.
16:04:12 <smcginnis> Only one abandoned so far because the team is dropping one of the deliverables.
16:04:14 * diablo_rojo has all the tabs open to do reviews
16:04:31 <ttx> smcginnis: did you cover all the gaps, or is there more to generate ?
16:05:01 <ttx> I find it relatively short
16:05:05 <smcginnis> ttx: That was all that the script indicated, but I will take another look through to see if we need to update that script or the process to catch everything.
16:05:12 <smcginnis> It was much shorter than I had expected.
16:05:28 <ttx> The Script Is Always Right
16:05:38 <ttx> All hail the Script
16:06:07 <smcginnis> list_library_unreleased_changes.sh didn't show much else, and most of those were client libs or things those teams were already aware of.
16:06:55 <smcginnis> I'll take a look again later today.
16:07:09 <ttx> so are we planning to force them Friday?
16:07:11 <smcginnis> In the meantime, if we have acks from those teams, we should try to get them processed today.
16:07:13 <ttx> or monday maybe?
16:07:31 <smcginnis> Hmm, I could see either.
16:07:32 <ttx> or maybe warn Friday EOD that we'll process them Monday?
16:07:42 <smcginnis> That seems fair.
16:07:50 <ttx> ok writing that down
16:07:52 <evrardjp> sounds reasonable... what about the teams that -1 but didn't propose something else yet?
16:08:11 <evrardjp> by Friday*
16:08:12 <smcginnis> #agreed Team will process un-ack'd releases on Monday
16:08:25 <diablo_rojo> Sounds good to me.
16:08:49 <ttx> teams which -1 should also have something up
16:08:57 <ttx> we have a deadline
16:09:07 <ttx> but apply some case-by-case understanding
16:09:08 <evrardjp> agreed, that's why I am saying this :)
16:09:10 <smcginnis> evrardjp: We could also note a task for Monday to double check those.
16:09:11 <evrardjp> ok
16:09:18 <evrardjp> smcginnis: agreed
16:09:31 <ttx> in some cases they have something blocked in Zuul, it's fine to wait a day
16:09:56 <ttx> the reason why we do it one week before is to generally give time to catch issues before FF
16:10:02 <evrardjp> yeah, but I think we should talk about it on Monday (long story short)
16:10:19 <ttx> but if merging it would craete more problems...
16:10:33 <evrardjp> ttx: indeed, my point is that we don't want to delay things either, and we don't want ffe all the way
16:10:44 <smcginnis> Any remaining ones are probably lower risk. We've done all the oslo libs and major projects that would more likely have ripple effects on other projects.
16:10:53 <ttx> any formal -1 yet?
16:11:16 <smcginnis> I think there was just the one I abandoned because the team said they were going to retire the repo.
16:11:20 <ttx> At this point the groups paying attention have answered and the others will get Monday-approved
16:11:27 <evrardjp> my memory serves me wrong, sorry for that
16:11:45 <ttx> so I don;t think we'll have any standing -1 to unblock
16:11:58 <evrardjp> yeah my bad
16:12:08 <smcginnis> I'll take a look on Monday just in case though.
16:12:10 * prometheanfire is waiting on https://review.opendev.org/679842 the team seems awol
16:12:13 <ttx> we might get a last minute one
16:12:24 <ttx> prometheanfire: yes we might force that one today-ish
16:12:49 <ttx> it's cheap and you gave them ample opportunity to block it
16:13:05 <prometheanfire> thanks
16:13:11 <smcginnis> Yeah, we can probably approve that now. If that team hasn't responded by this point, I don't think they will today. It's probably night for most of them.
16:13:36 <ttx> ok, I think we are good on libs autoreleases
16:13:44 <ttx> How about the "Update the feature list" task?
16:13:47 <smcginnis> Next task was updating the feature list.
16:13:56 <smcginnis> evrardjp: Did you get a chance to take a look at that?
16:14:22 <evrardjp> https://review.opendev.org/#/c/679610/
16:14:47 <evrardjp> I have no clue what I am doing but gmann said it was ok.
16:14:53 <smcginnis> ;)
16:15:04 <evrardjp> it's like the previous ones, just grepped a little more and changed a little more.
16:15:05 <ttx> The Process is to be followed.
16:15:23 <smcginnis> I do wonder if those could just be automated, but probably easy enough to just keep doing them.
16:15:34 <evrardjp> ttx: the process was different because files changed, but exactly!
16:15:44 <smcginnis> Thanks for taking care of that evrardjp
16:15:45 <ttx> yeah, once-per-cycle is not enough to justify automation
16:15:54 <evrardjp> smcginnis: this will take more time to automate I think, because things change
16:16:08 <ttx> https://xkcd.com/1205/
16:16:11 <smcginnis> Agreed
16:16:12 <evrardjp> ttx: I have a xkcd for that somewhere, will find that eventually
16:16:13 <evrardjp> hahaha
16:16:21 <evrardjp> thanks!
16:16:29 <smcginnis> :)
16:16:41 <smcginnis> Last task is the new one for tomorrow. I can take that.
16:17:10 <smcginnis> #topic How to handle branching with new runtimes
16:17:18 <smcginnis> #link https://review.opendev.org/#/c/673019/
16:17:48 <smcginnis> My second to last comment on there details some issues I see with this.
16:18:12 <smcginnis> We have several external dependencies that I'm not sure we can automate gating on to do this right.
16:18:16 <evrardjp> Agreed. this was by far the last element, because that was actionable :p
16:18:26 <smcginnis> Yep!
16:18:44 <dhellmann> one of the reasons for the release-test repo is to allow us to test changes to the tools like this one
16:18:45 * ttx catches up
16:18:45 <evrardjp> I pinged mugsie in the TC channel, and we might continue there on the tc related things
16:19:04 <dhellmann> so we should get it to the point where we think it's right, then test branching the release-test repo
16:19:12 * mugsie is watching, but not fully engaged
16:19:23 <smcginnis> dhellmann: I don't think we can.
16:19:41 <dhellmann> ?
16:20:07 <smcginnis> mugsie: See my second to last comment on https://review.opendev.org/#/c/673019/ for the issues I see with doing this.
16:20:29 <smcginnis> dhellmann: Maybe I'm missing something, but a few of those steps are definitely needed first.
16:21:04 <mugsie> yea, 3+4 are only just underway - I assumed stable/train branches were a ways out
16:21:10 <evrardjp> so there are patches for 1) and 3)4) AFAIK
16:21:18 <smcginnis> mugsie: The future is now. ;)
16:21:25 <dhellmann> oh, I just mean don't stress about manually reviewing this to perfection because we have a way to test it once it merges
16:21:27 <evrardjp> 1) need confirmation from foundation, no?
16:21:37 <mugsie> I thought we got that
16:21:37 <evrardjp> dhellmann: nice reminder :)
16:21:44 <evrardjp> ok
16:21:48 <smcginnis> evrardjp: I believe we've had that. It's official ussuri.
16:21:51 <ttx> yes
16:21:59 <ttx> ricolin announced it
16:22:07 <evrardjp> I saw the announcement
16:22:09 <dhellmann> smcginnis : your point about having the python versions selected makes sense
16:22:10 <evrardjp> brainfart
16:22:19 <ricolin> yep:)
16:22:22 <evrardjp> it's been a long day.
16:22:37 <fungi> right, ricolin waited to announce it until the trademark search was completed
16:22:45 <dhellmann> maybe this is a thing to automate with a script after the fact, rather than as part of the branching process
16:22:45 <evrardjp> I think what matters technically for this to be in is the point 5)
16:22:47 <smcginnis> I suppose we could define the jobs ahead of time and change the content once the runtimes are finalized, but that could cause an issue.
16:22:56 <evrardjp> and 2) but that should be relatively easy
16:22:57 <smcginnis> dhellmann: I think that's what we are going to have to do.
16:22:59 <dhellmann> yeah, that's the other approach
16:23:06 <smcginnis> Too many external dependencies.
16:23:20 <smcginnis> And we want the change to be self testing, not break everything after it's been merged.
16:23:24 <dhellmann> plus that way someone will get the review stats ;-)
16:23:35 <dhellmann> yes, that is also a plus, smcginnis
16:24:19 <dhellmann> given how long it has taken to make some of those decisions lately, it seems like keeping the processes decoupled is wise
16:24:29 <evrardjp> What is the deadline we are talking about? Can we use the review on 3) as basis for 5) ?
16:24:47 <evrardjp> and maybe change if necessary?
16:25:28 <dhellmann> although I suppose if the job template doesn't exist, the patch to add it would just fail, and then it would be there for someone to merge later when the jobs do exist
16:25:30 <evrardjp> I am confused about the issue here (I understand we don't want to mess with the content of the job template after the fact though, but even that I don't consider a big deal)
16:25:30 <smcginnis> We could define the job, then change it, but that risks the change passing, then we update the runtimes, now suddenly the entire project is blocked by the gate because of a bug with the new runtime.
16:25:51 <evrardjp> dhellmann: yes but I am here assuming we have a basis for creating the template
16:26:06 <dhellmann> smcginnis : what if we leave the template undefined, but generate the patch to add it anyway? then teams can merge it when the template is created
16:26:18 <evrardjp> smcginnis: agreed on that too, but as said above, not a big deal for me, as projects would have to deal with it anyway
16:26:24 <dhellmann> evrardjp : the only thing we need to know in the patch generating the change is the name of the template
16:26:28 <smcginnis> evrardjp: We still need 2) in place, which I don't think we've always had done before it came time to branch.
16:26:48 <evrardjp> smcginnis: now I start to understand :)
16:27:01 <dhellmann> smcginnis : we know the name for the new series now, though
16:27:13 <smcginnis> evrardjp: Yah, but dealing with a bug fix before adding new jobs is differnt than blocking the entire project until the bug if fixed.
16:27:27 <evrardjp> dhellmann: what I meant is that, should we already create this template, as of today, with the _proposed_ jobs of the patch from mugsie?
16:27:39 <smcginnis> #link https://review.opendev.org/#/c/679822/ Strawman for Ussuri schedule
16:27:40 <evrardjp> assuming this, a depends-on would work and definition of the job would work
16:27:41 <dhellmann> evrardjp : not until the TC approves that list
16:27:56 <evrardjp> ok so it's a process thing. Got it.
16:28:05 <evrardjp> thanks for clarifying!
16:28:15 <mugsie> the python3 versions are not in debate, but from a process side the jobs should wait
16:28:17 <dhellmann> depends-on will block the patch from merging, but won't allow the jobs to run because you can't do speculative testing against project-config
16:28:24 <dhellmann> mugsie : right
16:28:33 <smcginnis> I guess we could propose it before the job is defined. But I wonder if that would cause confusion.
16:28:40 <evrardjp> dhellmann: oh true.
16:29:14 <dhellmann> smcginnis : we could handle that with the commit message, like we used to have to do for the requirements URL update
16:29:28 <smcginnis> We would still need to update our process to ensure we have the next cycle added to the releases repo before anyone requests a stable branch.
16:29:41 <dhellmann> yes, that's true
16:29:55 <dhellmann> although we could enforce that with validation in the releases repo
16:30:03 <evrardjp> that doesn't sound a big patch, but I am not sure what it really entails
16:30:37 <smcginnis> If we commit to always having 6 months cycles, and we get a list of cycle names ahead of time, we could probably do that safely. For now, it would be on us as reviewers to have to know everything is in place so the tagging and branching job doesn't fail.
16:30:53 <dhellmann> smcginnis : we could also loosen the validation on the series status file so that it doesn't require dates
16:31:02 <smcginnis> Oh true, we could have validation that looks for new stable branch creation and make sure there is a next series defined.
16:31:07 <dhellmann> right
16:31:42 <smcginnis> I am concerned about getting any of this in place yet for stable/train branches.
16:32:01 <evrardjp> smcginnis: though that seem to be a problem that can repeat itself
16:32:33 <dhellmann> yeah, it's a lot to get done in a short amount of time
16:32:35 <evrardjp> is there something we should change in the agenda ?
16:32:53 <dhellmann> it might be better to write up a more detailed plan to implement this next cycle, and deal with things by hand this cycle
16:32:54 <evrardjp> (for next time)
16:33:35 <smcginnis> I'm also concerned that if we aren't able to agree to a next cycle name or something like that, doing final releases could be held up until we get these things in place.
16:33:59 <smcginnis> I don't want to risk the unified release to try to make the next cycle one step easier.
16:34:27 <smcginnis> But I agree with dhellmann - lets get this written up in more detail so we make sure we have all issues understood and handled.
16:35:00 <dhellmann> having a list of things to do, and information we must have in order to progress, would make the work and blockers a lot clearer
16:35:14 <smcginnis> ++
16:35:42 <smcginnis> So let's kick that can a little further down the road for now and move on.
16:35:56 <smcginnis> #topic R-5 email content final review
16:36:05 <smcginnis> #link https://etherpad.openstack.org/p/relmgmt-weekly-emails
16:36:26 <smcginnis> Line 391-ish.
16:36:59 <smcginnis> ttx: "This coming week is the deadline for client libraries (except client libraries):"
16:37:11 <ttx> ah
16:37:58 <ttx> I tried to simplify it, and moved the mention of prelude to next week email to keep this one digestable
16:38:33 <smcginnis> Just finished reading through again. This looks good to me.
16:38:36 <ttx> Focus on the critical bits
16:39:46 <smcginnis> If anyone else has any edits or comments, feel free to raise them or edit the draft. I will send that out later today.
16:40:05 <evrardjp> It looks good
16:40:21 <smcginnis> #topic Review/assign next week tasks
16:40:23 <evrardjp> I haven't found mistakes so far
16:40:24 <evrardjp> :p
16:40:29 <smcginnis> :)
16:40:51 <ttx> OK, so I win the right to do it again next week!
16:40:54 <smcginnis> First, approve all train-3 libs.
16:41:24 <smcginnis> I'll put my name down for that, but anyone feel free to do that Monday morning. Especially any of you that live in the future.
16:41:34 <evrardjp> :)
16:41:40 <ttx> ok might beat you to it
16:41:41 <ttx> or not
16:41:56 <evrardjp> I have planned to clear my morning agenda for helping there
16:41:59 <smcginnis> Layers of backup redudancy.
16:42:06 <evrardjp> will see at that time :)
16:42:18 <smcginnis> That might be good just in case we run in to any issues. Not that I think we should at this point.
16:42:29 <ttx> Milestone-3 client library autoreleases... anyone interested ? Should also happen early in the week
16:42:49 <evrardjp> diablo_rojo: want to do it with me?
16:42:55 <ttx> I'll take the "Evaluate any libraries" step
16:43:04 <diablo_rojo> evrardjp, sure :)
16:43:13 <diablo_rojo> #teamworkmakesthedreamwork
16:43:27 <evrardjp> :)
16:43:29 <evrardjp> cool!
16:43:33 <smcginnis> Thanks!
16:43:56 <evrardjp> who is pinging prometheanfire :p
16:43:59 <smcginnis> And remind the requirements team - I've kind of done that already, so I know prometheanfire is aware on planning for it.
16:44:07 <ttx> we can do that during the meeting next week
16:44:23 <ttx> let me move that one off
16:44:25 <smcginnis> And he's been reminded of his sad lack of batman quotes last time around.
16:44:35 <smcginnis> ttx: ++
16:44:58 <smcginnis> Looks like that's it for the task list.
16:45:24 <ttx> ++
16:45:26 <diablo_rojo> Should I send out the cycle highlights email?
16:45:41 <diablo_rojo> We have the deadline coming up and I dont think i have seen any come in.
16:45:53 <smcginnis> diablo_rojo: That would be good to have its own email to try to get more awareness/visibility.
16:45:55 <diablo_rojo> Even though it was in the release email last week
16:45:58 <ttx> diablo_rojo: hmm maybe the Monday ? It's mentioned in the weekly email that should go out today/tomorrow already
16:46:00 <smcginnis> I have seen zero activity there.
16:46:05 <diablo_rojo> I'll get that out today then.
16:48:30 <ttx> alright, anything else to discuss?
16:48:30 <smcginnis> #topic Open floor
16:48:42 <evrardjp> nothing
16:48:44 <diablo_rojo> I got nothing else
16:48:53 <evrardjp> except thanks everyone!
16:48:57 <ttx> i don't have anything. Except a blood sample test tomorrow morning, so no drink tonight
16:48:59 <smcginnis> Please take a look at the proposed scheduele I put up and see if you notice any issues with where milestones land or anything else like that.
16:49:18 <smcginnis> ttx: Our condolenses on your suffering. :D
16:49:19 <evrardjp> (mostly dhellmann smcginnis and ttx for their patience to explain to a newcomer like me!)
16:49:25 <ttx> willdo
16:49:37 <smcginnis> evrardjp: Thanks for all the help!
16:49:55 <smcginnis> And thanks everyone for participating. Really appreciated!
16:49:59 <smcginnis> #endmeeting