15:01:37 <ttx> #startmeeting releaseteam
15:01:38 <openstack> Meeting started Fri Aug 11 15:01:37 2017 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:41 <openstack> The meeting name has been set to 'releaseteam'
15:01:57 <ttx> Agenda @ https://etherpad.openstack.org/p/pike-relmgt-tracking (scroll down to R-3 week)
15:02:59 <ttx> #topic Missing RC1
15:03:35 <ttx> We have a number of cycle-with-milestones deliverables that are still missing RC1 / stable/pike branching
15:03:41 <ttx> designate (+ designate-dashboard)
15:03:45 <ttx> heat
15:03:47 <ttx> manila
15:03:51 <ttx> searchlight (+ searchlight-ui)
15:04:07 <ttx> unclear ETA for them
15:04:33 <dims> o/
15:04:43 <ttx> so I propose we don't wait for them before we do the devstack / requirements branching
15:04:53 <dims> ++ ttx
15:04:55 <dims> and grenade
15:05:29 <ttx> If they still haven't done anything next week we'll probably just cut one for them
15:05:55 <ttx> #topic Standing Library freeze exception requests
15:06:04 <ttx> We have os-win @ https://review.openstack.org/492483
15:06:34 * dhellmann slinks in late
15:06:47 <ttx> includes a regression fix that affects certain environments (clustered Windows / Hyper-V Server 2016 nodes) - without it, VMs cannot be spawned in such environments.
15:07:52 <dims> ttx : "Clustering Hyper-V" so fail on some environments
15:08:22 <ttx> I think that would not warrant a global-req bump
15:08:32 <ttx> but that would still trigger an uc bump
15:08:39 <dims> y, hold the line on just uc bump
15:09:18 <dhellmann> ++
15:09:23 <ttx> well he did not ask for a req bump so...
15:09:26 <dhellmann> should we do that before the requirements branch?
15:09:29 <ttx> shall we approve this before branching ?
15:09:30 <bswartz> ttx: manila rc1 expected in about 90 minutes
15:09:43 <ttx> bswartz: thanks!
15:09:55 <ttx> dhellmann: I would say yes
15:10:03 <dims> ttx : no need
15:10:23 <ttx> dhellmann: the only thing that bothers me a bit is the .Y bump
15:10:31 <dhellmann> why?
15:10:55 <ttx> in the middle of a lib freeze it feels like only .Z bumps shall be allowed
15:11:01 <dhellmann> ah
15:11:12 * ttx looks at what warrants the .Y bump
15:11:14 <dims> ttx : dhellmann : they can backport just that specific review and ask for 2.1.1 and we can deal with that next week
15:11:25 <dhellmann> should we ask them to branch and backport the critical fix?
15:11:27 <ttx> I would go with smallest change
15:11:30 <dhellmann> that seems like it's going to take a while
15:11:31 <dims> they already cut stable/pike from 2.1.0
15:11:36 <dhellmann> oh, did they?
15:11:41 <claudiub> os-win?
15:11:48 <claudiub> it was cut automatically. :)
15:11:50 <dims> https://review.openstack.org/#/c/492483/1/deliverables/pike/os-win.yaml
15:11:51 <ttx> claudiub: yes
15:12:05 <dhellmann> oh, yeah, if there's a pike branch that fix can be backported to that
15:12:09 <dhellmann> and this should be a queens release
15:12:14 <claudiub> the fix is backported to pike already
15:12:19 <dhellmann> aw
15:12:24 <dhellmann> you backported features, too
15:12:29 <ttx> hmm, I think the stable/pike branch got a couple of featury things like [Trivial] Add method checking if a disk is claimed by MPIO
15:12:40 <ttx> which is why it bumped to 2.2.0
15:13:31 <ttx> It's difficult to hold the line with so many projects not following stable policy, but that's a tangential discussion
15:14:16 <ttx> yes, stable/pike was pretty busy over the last 14 days
15:14:41 <dims> claudiub : what percentage of installs are the "clustered" variety?
15:15:21 <ttx> Look all like clean backports though
15:15:51 <lpetrut> dims: most of our customers use Hyper-V clusters actually
15:15:53 <claudiub> that patch is not really a feature. there's an issue regarding MPIO, a race condition, and it is required by: https://review.openstack.org/#/c/490894/
15:15:58 <ttx> I guess that's limited risk since that code is only loaded on the platform the late version is supposedly fixing
15:16:13 <claudiub> which should be backported to pike as well, after it merges on master.
15:16:55 <ttx> dhellmann: given the nature of the lib I'm willing to give it a free pass
15:17:28 <dims> ttx : as long as it does not affect g-r
15:17:32 <dhellmann> ok, I guess I can go along with that
15:17:33 <ttx> right
15:17:59 <ttx> Let's approve while nobody else is looking
15:18:07 <dims> kk
15:18:09 * claudiub looks away
15:18:10 * fungi saw that ;)
15:18:12 <ttx> claudiub: next time try to be more conservative on what you backport :)
15:18:37 <claudiub> ttx: sure. :)
15:18:41 <ttx> dhellmann: remove your -1 ?
15:18:43 <dims> lol fungi
15:18:44 * smcginnis finally got to 10000 ft
15:19:15 <ttx> The new PTl is here, just pretend nothing happened
15:19:22 <dims> hehehe
15:19:23 <dhellmann> ttx: approved
15:19:43 <ttx> ok, next topic
15:19:47 <dhellmann> oh, should we get dims and smcginnis to pile on to give us cover? :-)
15:19:48 <dims> smcginnis : there's NOTHING under the carpet
15:19:55 <ttx> #topic When to do the branching work ?
15:20:07 <ttx> Shall we start just after this meeting, despite it being Friday ?
15:20:18 <dims> yes ttx
15:20:21 <ttx> do you all have a couple of hours to kill ?
15:20:29 <dims> i am up for it
15:20:32 <dhellmann> yes, I have time to help
15:20:38 <ttx> I shall be able to spend next 90min before life calls
15:20:47 <dims> and we'll lose sdague if we don't do it today (he's on vacation next week)
15:20:51 <ttx> ok, let's close meetign fast then
15:20:54 <dhellmann> ++
15:21:00 <ttx> EVERYONE is on vacation enxt week
15:21:11 <fungi> even me!
15:21:12 <dims> oh boy
15:21:15 <ttx> #topic Open discussion
15:21:16 <dhellmann> the european influence is rubbing off
15:21:23 <ttx> So nobody has been updating the tracking page
15:21:35 <ttx> Which is why I feel it's useless at this stage
15:21:43 <smcginnis> Sounds good to me.
15:21:45 <ttx> I've been using https://releases.openstack.org/pike/index.html
15:21:53 <ttx> even if due to post jobs it trails a bit
15:21:58 <fungi> which tracking page, the etherpad?
15:22:08 <ttx> If I need accurate status I've been grepping the releases repo
15:22:11 <smcginnis> Sorry, appears to be a lot of lag. :)
15:22:16 <dims> ttx : y i never even opened it
15:22:18 <ttx> https://docs.google.com/spreadsheets/d/1F2hFo6cf1OvIyoC-ifRpVgrkFiYMzbNFTr2MsAYLpqs/edit#gid=223155692
15:22:20 <ttx> Review tasks for next week
15:22:27 <ttx> err ignore that last line caught in paste
15:22:41 <fungi> the pike-relmgt-tracking pad is what i assumed anyway
15:22:42 <dhellmann> ttx: the list-deliverables command also has some useful query args
15:22:45 <ttx> dhellmann: right
15:22:48 <dhellmann> --missing-stable-branch etc
15:22:56 <dhellmann> that's what I use, because I can git pull and get the latest info
15:22:57 <ttx> So keeping the gdoc up to date is a bit painful and error-prone
15:23:04 <ttx> Let's ignore it
15:23:16 <ttx> We can use the tracking page to list open issues when fire will start spreading
15:23:25 <ttx> (the etherpad one)
15:23:29 <ttx> I know, confusing
15:23:30 <smcginnis> ++
15:23:36 <dhellmann> ++
15:23:47 <ttx> OK. Last topic: next week's tasks
15:23:51 <dims> agree
15:23:58 <ttx> Quick review of what's listed on R-2
15:24:01 <fungi> we also have ethercalc.openstack.org now if you want to do spreadsheets and would rather avoid the goog
15:24:20 <smcginnis> fungi: Thanks, good point.
15:25:29 <ttx> Looks like most of thye tasks are R-1 tasks
15:26:30 <ttx> so I moved them
15:26:45 <ttx> I think the only timely tasks is the release notes check
15:27:01 <ttx> the rest is more like R-1 work
15:27:14 <ttx> Anything we should definitely do on R-2 instead of R-1 ?
15:27:33 <ttx> i.e. we shoulddn't produce last release candidates too early
15:27:34 <smcginnis> The couplethings there look good to me.
15:27:49 <ttx> since they need to ingest late translations updates
15:27:56 <smcginnis> ttx: We would still want to process RC requests if a project feels they are ready, right?
15:28:13 <smcginnis> Or is there a reason to hold. Ah, late translations. Got it
15:28:22 <ttx> smcginnis: yes, especially if they have a significant bugfix they want to throw "out there" for testing
15:28:36 <smcginnis> ttx: Makes sense.
15:28:37 <ttx> but we'd still need to refresh the RC on R-1 week
15:28:44 <ttx> to catch for late translations
15:29:14 <ttx> dhellmann, dims: does that make sense ?
15:29:33 <dims> yep
15:29:39 * dhellmann catches up
15:29:55 <ttx> I'll take on the two remaining tasks for R-2
15:30:05 <ttx> since I'm off on R-1
15:30:58 <dhellmann> all of that seems ok
15:31:37 <ttx> OK, let's close and get the branching show on #openstack-release started
15:31:49 <ttx> Anything else before we close ?
15:32:11 <dhellmann> nothing from me
15:32:18 <smcginnis> Nor me.
15:32:34 <dims> i haven;t been able to raise any of the requirements folks on their channel yet
15:32:40 <dims> ++ to close
15:33:17 <dhellmann> we should add a note to the process doc to coordinate the requirements branching time with them ahead of time so there is someone available
15:33:31 <ttx> ack
15:33:33 <ttx> #endmeeting