15:00:08 <smcginnis> #startmeeting releaseteam
15:00:09 <openstack> Meeting started Fri Oct  6 15:00:08 2017 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:13 <openstack> The meeting name has been set to 'releaseteam'
15:00:19 <smcginnis> ping dims, fungi, tonyb, lbragstad, ttx
15:00:36 <ttx> o/
15:00:40 <smcginnis> #link https://etherpad.openstack.org/p/queens-relmgt-tracking Meeting agenda
15:00:42 <fungi> i guess it's friday
15:00:48 <ttx> already
15:01:02 <smcginnis> Time flies when you're putting out fires.
15:01:26 <smcginnis> We are at R-21 already.
15:02:55 <ttx> almost at release day
15:03:18 <smcginnis> I'm sure it will be here before we know it.
15:03:27 <smcginnis> #topic Queens-1 actions
15:03:33 * ttx multitasks meetings
15:03:43 <lbragstad> o/
15:03:56 <smcginnis> So the process doc doesn't have much about milestone 1 other than sending reminders.
15:04:08 <smcginnis> Anything else we should be doing in preparation for this?
15:04:46 <ttx> not really
15:04:58 <smcginnis> Good, I like those kinds of deadlines. :)
15:05:06 * ttx doublechecks
15:05:26 <ttx> nah
15:05:45 <ttx> We might want to review progress on the plan though
15:05:59 <ttx> Not many Q1 targets in there
15:06:17 <ttx> as in none
15:06:22 <smcginnis> Yeah, we've made some progress on those items, but not really a lot of activity.
15:06:29 * ttx adds a few
15:06:41 <smcginnis> #topic Queens release plan
15:06:46 <smcginnis> #link https://etherpad.openstack.org/p/queens-relmgt-plan
15:07:12 <ttx> so I reviewed the potential work on release automation that a git namespace flattening /would/ trigger
15:07:17 <smcginnis> Probably a good reminder to just bring up again that folks should look through that and pay attention what you've signed up for.
15:07:24 <smcginnis> Or were volunteer for.
15:07:27 <ttx> fungi captured most of what was needed already
15:07:35 <ttx> I just spotted a couple extra fixes
15:07:45 <fungi> cool
15:07:45 <ttx> I'll be updating the infra spec early next week
15:07:53 <smcginnis> ttx: What's the current thought on timeline for that?
15:07:55 <ttx> updating rationale and all
15:07:57 <fungi> ping me when you push that in case i miss it
15:08:11 <ttx> smcginnis: no ETA at this point
15:08:21 <ttx> Still need to decide if it's a good idea or not
15:08:26 <smcginnis> Are we going to try to get that tackled in Queens yet?
15:08:28 <ttx> I would complete te zuul v3 transition first
15:08:36 <fungi> i've also been thniking about ways we could actually do more of that earlier and save the actual gerrit-side flattening for later
15:08:40 <smcginnis> Tackled == do or abandon the idea
15:08:41 <ttx> and then let fungi and clarkb have 2 months vacation to recover
15:08:49 <smcginnis> Hah, right.
15:09:24 <ttx> fungi: also a number of redirects could save us from some work
15:09:30 <smcginnis> Based on the zuul disruptions, anything we could do to make than as painless and friction free as possible I know would be greatly appreciated.
15:09:33 <fungi> stuff like hiding (but still supporting) namespaces on git.o.o and the org decomposition on gh could actually happen well before we rename all the repos in gerrit and update everything
15:09:39 <ttx> Like the tox.ini changes are not really necessary if we have a redirect set in cgit
15:10:08 <ttx> Though I suspect the .gitreview might still need updating
15:10:24 <ttx> not 100% sure  what that project parameter is used for
15:10:43 <fungi> .gitreview files will need updating at the same time we rename in gerrit
15:10:45 <smcginnis> I wonder if we could do any cleverness in git-review itself to ease this.
15:11:03 <ttx> smcginnis: yes we can make sure that gitreview would update the remotes
15:11:14 <ttx> to ease the pain on the dev side
15:11:34 <fungi> working around it in git-review 1. assumes people upgrade to newer git-review and 2. is kinda tough when it's intended to be a generic gerrit client and we've avoided baking any openstackisms into it
15:11:47 <smcginnis> Yeah, true.
15:12:05 <fungi> not necessarily impossible, just constraints we have to think about
15:12:12 <ttx> fungi: no, I mean the idea of fetching the latest .gitreview if you fail with your checked out one
15:12:29 <ttx> idea that someone suggested in that session
15:12:35 <ttx> PTG denver infra room
15:12:39 <fungi> mmm... i may be misunderstanding but that sounds like a catch-22
15:12:52 <fungi> i'll need a refresher, but not necessary during the release meeting
15:12:54 * smcginnis should go back and review those notes
15:13:57 <smcginnis> OK, anything else we should discuss today? Or get back to it?
15:14:07 <smcginnis> #topic Discussion
15:14:19 <fungi> (i think the idea we talked abotu was actually having git-review update your git remote for gerrit if it finds a new .gitreview file)
15:14:35 <ttx> nothing else on my side, just that the release impact is reasonable. Just need to develop a couple of tools to produce the patches for D day
15:14:48 <ttx> fungi: yes
15:15:21 <ttx> that's what i meant by "make sure that gitreview would update the remotes"
15:15:50 <fungi> okay, that's not fetching the latest .gitreview file, but rather what to do if you fetch a new .gitreview file
15:16:18 <ttx> Ah, ok
15:16:43 <ttx> smcginnis: ok to close early
15:17:03 <smcginnis> Sounds good then. Thanks everyone. Have a good weekend.
15:17:09 <fungi> and we'd still have the chicken-and-egg problem of git needing to know the new gerrit remote before it could retrieve the updated .gitreview (this is the same problem projects run into on a smaller scale with individual project renames)
15:17:34 <smcginnis> Sounds like we should noodle on it some more. I need to catch up on notes.
15:17:49 <smcginnis> #endmeeting