16:00:21 <smcginnis> #startmeeting releaseteam
16:00:21 <openstack> Meeting started Thu Dec  5 16:00:21 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:25 <openstack> The meeting name has been set to 'releaseteam'
16:00:28 <smcginnis> Ping list: ttx armstrong diablo_rojo, diablo_rojo_phon
16:00:41 <hberaud> o/
16:00:45 <smcginnis> #link https://etherpad.openstack.org/p/ussuri-relmgt-tracking Tracking etherpad
16:01:10 <ttx> down to ~100
16:01:11 <smcginnis> We are down to line 100.
16:01:14 <smcginnis> ;)
16:01:43 <smcginnis> #topic Review this weeks tasks
16:02:02 <smcginnis> I tried to run some scripts last night to get the cycle-trailing status.
16:02:17 <smcginnis> I don't think we've created a nice easy tool for getting that, unless I've missed it.
16:02:25 <ttx> it's surprisingly nontrivial
16:02:26 <smcginnis> I actually can't recall what we've done in the past.
16:02:33 <smcginnis> Yeah, that's what I found.
16:02:50 <ttx> Maybe just a thread to ask each for their status
16:02:56 <smcginnis> I tweaked some existing tools, and if I believe the results, most cycle-trailing have not released anything yet.
16:02:57 <ttx> would be simpler
16:03:03 <smcginnis> ++
16:03:08 <smcginnis> That's kind of where I was leaning.
16:03:13 <diablo_rojo> o/
16:03:23 <ttx> Like "Trani cycle-trailing deliverables status, tagging each team that has one
16:03:23 <smcginnis> Probably separately from the countdown email for visibility.
16:03:26 * diablo_rojo has split focus between tc/election discussions and the meeting
16:03:26 <ttx> Train
16:03:33 <ttx> smcginnis: ++
16:03:38 <ttx> you take it?
16:03:48 <smcginnis> We've really relaxed the timeline on trailing projects.
16:03:59 <ttx> sure, but that serves as a mild reminder
16:04:05 <ttx> and also helps in our data collection
16:04:11 <smcginnis> So I'm actually not too concerned about strictly enforcing they get something out right away.
16:04:20 <smcginnis> Since some are definitely needing more time than others.
16:04:32 <ttx> yeah, not about enforcement really
16:04:46 <smcginnis> But we also want to track some of that to make sure we aren't carrying along a deliverables that are not really alive anymore.
16:04:46 <ttx> It's more "so... where are you at?"
16:04:52 <smcginnis> ++
16:05:22 <smcginnis> #action smcginnis to send out cycle-trailing reminder for train
16:05:50 <smcginnis> Next task - countdown email prep
16:05:55 * smcginnis pulls up etherpad
16:05:55 <ttx> It's up
16:06:18 <ttx> https://etherpad.openstack.org/p/relmgmt-weekly-emails
16:06:24 <ttx> around line 33
16:06:34 <smcginnis> I looked at the old version - this looks great!
16:06:44 <smcginnis> I can get that sent out later today.
16:06:59 <smcginnis> If anyone else has any updates or changes, just let me know and update the etherpad.
16:07:54 <smcginnis> #topic tempestconf not owned by any project
16:08:10 <smcginnis> Wasn't there a sig that that falls under now?
16:08:35 <ttx> yes there is... but so far we have kept teh line at only project teams
16:08:45 <smcginnis> Hmm, true.
16:08:53 <ttx> release managament team handles releasing for project teams
16:09:15 <ttx> That is why we proposed for example to move os-win to oslo, if winstackers becomes a SIG
16:09:25 <ttx> In that case it's clearly not a part of openstack
16:09:47 <smcginnis> I wonder if we can make that an honorary QA team deliverable since it's close to tempest.
16:09:49 <ttx> It's a tool used to help assess its interoperability
16:09:57 <smcginnis> And they can just delegate decisions for it to the SIG.
16:10:01 <ttx> yeah, it's arguably a tempest connector
16:10:17 <smcginnis> We can see if gmann is open to that idea.
16:10:26 <ttx> We could also have a list of things we continue to release, or just ask then to tag it
16:10:35 <ttx> those are the three options
16:10:42 <ttx> them*
16:11:04 <ttx> I feel like we can release this one while we decide :)
16:11:05 <smcginnis> I think my preference would be to have another official team own it, even if they delegate authority on it.
16:11:18 <smcginnis> We can have an exception list, but I'd rather not go there. Could be a slippery slope.
16:11:30 <ttx> yeah, or playing favorites
16:11:41 <smcginnis> But having that SIG tag it themselves is an option, just not sure we want to make them deal with that.
16:11:44 <ttx> I would not mind that much handling the release process
16:11:48 <smcginnis> Especially knowing the state of that sig.
16:11:57 <ttx> but it's published on releases.openstack.org as a part of openstack itself
16:12:07 <smcginnis> I am totally fine just releasing it for now while we figure out the right way forward.
16:12:14 <ttx> which is in theory the realm of project teams
16:12:43 <ttx> smcginnis: I guess we could have a repo or a folder in release automation for things that we release and do not end in releases.o.o
16:12:57 <ttx> but yes, slippery slope
16:13:26 <ttx> OK, how about...
16:13:57 <ttx> we revisit that once we do aclmanager at milestone-1 and compare the list of things we do release vs. the things we have under governance
16:14:13 <smcginnis> That works for me.
16:14:25 <ttx> so that we have the discussion of what we manage vs. what we don't with all the data
16:14:28 <smcginnis> In the meantime, we can raise the issue with QA and see if they are willing to just take it on.
16:14:30 <ttx> I'll make a note
16:15:44 <evrardjp> thanks tempestconf basically!
16:15:51 <smcginnis> #action team to follow up on python-tempestconf ownership after reviewing aclmanager results
16:16:14 <evrardjp> (sorry just catching up)
16:16:21 <ttx> ok added to next week tasks. Will do
16:16:28 <ttx> I think I have a script to do that
16:16:56 <smcginnis> evrardjp: I'm going to move on, but feel free to bring up anything on things we've gone over
16:16:56 <ttx> and if that seems useful I'll post it and add it to PROCESS
16:17:02 <smcginnis> ++
16:17:11 <smcginnis> #topic Stuck reviews
16:17:15 <ttx> Not urgent
16:17:18 <gmann> ttx: smcginnis i understand the current situation but it actually does not fall under QA missions. we discussed this many time within team also.
16:17:37 <ttx> gmann: fair enough, just checking :)
16:17:55 <smcginnis> gmann: OK. I was hoping QA could just be the nominal owner of it, but still have the WG do the reviews and have core rights.
16:18:04 <smcginnis> But we can see if it can be handled a different way.
16:19:04 <smcginnis> OK, stuck reviews...
16:19:07 <smcginnis> #link https://tiny.cc/ReleaseInbox
16:19:19 <smcginnis> ttx: Were there specific ones you wanted to discuss? Tooling?
16:19:24 <ttx> looking
16:19:34 <ttx> https://review.opendev.org/#/c/696095/ is easy enough
16:19:53 <ttx> https://review.opendev.org/#/c/697329/ too
16:19:58 <diablo_rojo> I've done a few reviews in the last couple weeks (not as many as I should), but it will get better going forward
16:20:00 <smcginnis> Yep, I will approve after the meeting.
16:20:22 * diablo_rojo will review the second link today
16:20:45 <ttx> i thought https://review.opendev.org/#/c/695457/ was ready but missed hberaud's comment on it
16:21:02 * hberaud take a look
16:21:04 <ttx> FTR it's ok to -1 my patches, that way I spot issues faster
16:21:42 <evrardjp> ttx: ha, I thought I pinged you on that, sorry
16:21:43 <ttx> hberaud: I think you caught an issue around oslo.utils -> oslo-utils
16:22:05 <hberaud> ttx: maybe
16:22:20 * ttx looks deeper
16:22:28 <hberaud> not sure to see why it's happen
16:23:03 <smcginnis> Oh, that could be it.
16:23:18 <ttx> hmm weird
16:23:36 <ttx> ok anyway, not ready
16:23:47 <ttx> won;t debug it in-meeting
16:23:58 <hberaud> :)
16:24:34 <smcginnis> Any other reviews to highlight?
16:24:44 <ttx> os.path.basename(deliv_file).split('.')[0]
16:24:55 <ttx> that probably does not love multiple dots
16:25:02 <smcginnis> Yeah...
16:25:25 <smcginnis> os.path.splitext is probably what you want.
16:25:54 <ttx> I'll blame whoever I copy-pasted that one from
16:26:05 <ttx> which is really why I copypaste everything
16:26:12 <hberaud> lol
16:26:13 <smcginnis> :)
16:26:37 <smcginnis> #topic Timing of Extended Maintenance transition
16:26:39 <ttx> splitext, where have you been all this time
16:26:55 <smcginnis> I just thought this would be a good one to talk through and get ideas or at least others thinking about it.
16:27:16 <smcginnis> While I was working on the queens EM transition, I got a little worried we might run into a problem.
16:27:29 <smcginnis> We had several teams rushing to do a final release of committed changes.
16:27:56 <smcginnis> Which resulted in both libs and services releasing at the same time, then immediately going into a state where they can't do further releases.
16:28:24 <smcginnis> So I was just concerned that one of those lib releases could have unintended side effects that end up breaking a service, but then not being able to do anything to fix that.
16:28:39 <smcginnis> Which is why in current cycles we have the transitional deadlines at the end.
16:28:47 <smcginnis> Maybe not really an issue.
16:29:21 <smcginnis> I mean, ideally, nothing should be backported that could destabilize things really, but it just got me a little concerned and wondering if we should phase it like the currect cycel.
16:29:25 <smcginnis> *cycle
16:29:36 <smcginnis> And have libs, then clients, then services transition to EM.
16:30:04 <smcginnis> But I also think that may be more work than is necessary, so I'm a little reluctant to actual push for that idea.
16:30:11 <smcginnis> So... any thoughts?
16:30:26 <openstackgerrit> Bharat Kunwar proposed openstack/releases master: Release magnum 7.2.0 (rocky)  https://review.opendev.org/697514
16:31:05 <ttx> yeah, simultaneous rush at the end of a very calm/sable period is not great
16:31:06 <ttx> stable
16:31:29 <smcginnis> Ideally too, teams shouldn't be waiting for that point to rush out a final release, but we know how that goes. :)
16:31:49 <evrardjp> yeah
16:31:52 <ttx> I think it points more to an issue of the branch not being really maintained until you say let's em it
16:32:15 <ttx> so rather than put in place a complex process to phase libraries first…
16:32:22 <smcginnis> We had talked in the past about automatically proposing stable releases regularly. I think our tooling is close to make that fairly easy. Maybe if we start doing that, then we would avoid this situation.
16:32:35 <ttx> I'd try to weave some reminder to do stable releases in the usual cycle
16:32:59 <ttx> Like the one I added on R-18 this cycle
16:33:17 <openstackgerrit> Bharat Kunwar proposed openstack/releases master: Release magnum 8.2.0 (stein)  https://review.opendev.org/697515
16:34:31 <smcginnis> OK, we'll see if that helps.
16:34:54 <smcginnis> We can revisit later. I just wanted to raise the issue so everyone was aware of it and could be thinking about it.
16:35:11 <smcginnis> #topic Review next week tasks
16:35:15 <smcginnis> Already up on milestone 1.
16:35:30 <smcginnis> Looks like ttx and I are both travelling early in the week.
16:35:45 <smcginnis> I will be distracted, but I think I should be around from time to time.
16:36:02 <smcginnis> Biggest issue is the auto-releases.
16:36:07 <openstackgerrit> Thierry Carrez proposed openstack/releases master: Introduce tool to check PTL/liaison approval  https://review.opendev.org/695457
16:36:08 <openstackgerrit> Thierry Carrez proposed openstack/releases master: Enable check-approval in experimental pipeline  https://review.opendev.org/696095
16:36:08 <openstackgerrit> Thierry Carrez proposed openstack/releases master: [DNM] Test check_approval job on fake release  https://review.opendev.org/696104
16:36:13 <ttx> Yes I can cover the rest
16:36:23 <ttx> But we need someone to do the autorelease stuff
16:36:28 <smcginnis> diablo_rojo: I think you've done at least one of those before. Would you be willing to take on that one?
16:38:27 <smcginnis> I'll put diablo_rojo down for that task. We can revisit if we need to. :)
16:38:38 <ttx> I'll let you shoot it out
16:39:08 * diablo_rojo isn't sure what she just got signed up for but can probably figure it out.
16:39:20 <smcginnis> OK, then ttx has the governance/ACL checks. So we should be set.
16:39:34 <ttx> FWIW I started preparing the tasks/meetings/weeklyemails from now to ussuri-2
16:39:37 * diablo_rojo was still trying to wrap up TC/election things
16:39:42 * diablo_rojo is catching up
16:39:44 <ttx> With lots of email and meeting skips
16:39:49 <smcginnis> ++
16:40:13 <smcginnis> Thanks for doing that.
16:40:22 <smcginnis> #topic AOB
16:40:48 <smcginnis> Anything else to discuss?
16:40:54 <ttx> If there are things you do that are not listed but should probably be added to the PROCESS so that we make sure to cover them next time, please retroactively add them
16:41:21 <smcginnis> ++
16:41:22 <ttx> I'll post a process patch for what we did around ussuri-1 the week after it's done
16:41:49 <ttx> Nothing else from me
16:41:59 <smcginnis> Thanks for doing that. I think the process doc is in really good shape to make it easy for someone new to step in and know exactly what to do.
16:42:18 <smcginnis> Anywhere we can add tools/scripts for any of the steps helps too.
16:42:19 <evrardjp> yup, totally improved
16:42:45 <evrardjp> I sure hope ppl realise that this team is awesome, so that they should get involved :)
16:42:51 <smcginnis> Alright, if no one has anything else, I think we can wrap it up.
16:42:53 <smcginnis> :)
16:42:55 <fungi> following up on the python-tempestconf situation, yeah this was originally brought up with the qa team in advance of disbanding the refstack team (and even earlier still, when tempestconf was conceived, before it wound up shoved into the refstack team as a fallback)
16:43:04 <ttx> My main gripe is that for some weird reason I can't easily copypaste from webpage to etherpad
16:43:18 <smcginnis> I always have issues pasting into etherpads.
16:43:35 <fungi> it tries to preserve formatting, and generally does a terrible job of it, yes
16:43:36 <ttx> I guess i should copypaste from the process rst file
16:43:39 <smcginnis> I recently discovered hackmd.
16:43:54 <ttx> sounds like a collkid thing
16:43:58 <ttx> coolkid
16:44:13 <smcginnis> Totally. It even has a .io domain name.
16:44:27 <ttx> "Transcend beyond space and time"
16:44:55 <fungi> there's nothing like an indian ocean territory domain to show your support of imperialist hegemony
16:44:55 <smcginnis> fungi: Were there any discussion in the past about having that deliverable owned by a team under governance?
16:45:00 <evrardjp> ?
16:45:12 <fungi> smcginnis: it used to be owned by a team under governance
16:45:33 <smcginnis> Yeah, just wondering if it was discussed once that team was disbanded.
16:45:39 <smcginnis> Or punted like we are doing now. ;)
16:46:02 <fungi> the folks writing tempestconf wanted to maintain it in collaboration/as part of qa but were told "no thanks" but since it was a dependency of refstack the refstack team offered to give it a home
16:46:15 <ttx> I just switched my web searches to DuckDuckGo, already wondering  why anyone uses Google
16:46:37 <fungi> and then when we wound down the refstack team the tempestconf authors approached the qa team again about moving it there and were told "no thanks"
16:46:39 <smcginnis> ttx: So Google can remind me later that I want to buy things. :D
16:46:45 <fungi> so it ended up reassigned to the interop wg
16:46:52 <clarkb> google does produce better results in some cases (and you can ask ddg to query google for you)
16:47:26 <evrardjp> I am using duckduckgo for ages ... :) At some point I was having dual ddg/startpage
16:47:43 <evrardjp> ddg is far better now
16:48:30 <smcginnis> OK, the meeting has obviously devolved. Thanks everyone!
16:48:35 <smcginnis> #endmeeting