15:02:28 <smcginnis> #startmeeting releaseteam
15:02:29 <openstack> Meeting started Fri Nov 30 15:02:28 2018 UTC and is due to finish in 60 minutes.  The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:32 <openstack> The meeting name has been set to 'releaseteam'
15:02:53 <smcginnis> #link https://etherpad.openstack.org/p/stein-relmgt-tracking Agenda
15:03:05 <smcginnis> Around line 162
15:03:20 <ttx> o/
15:04:03 <smcginnis> No actual meeting agenda, at least so far.
15:04:08 <smcginnis> But good to check in.
15:04:18 <smcginnis> #topic Release failure
15:04:19 <fungi> might just be a short meeting then ;)
15:04:39 <smcginnis> Should probably at least mention that we had some failures earlier in the week.
15:04:56 <smcginnis> These were related to pypi mirroring if I understood correctly fungi?
15:05:19 <fungi> not really
15:05:54 <fungi> wednesday it was ipv6 connectivity problems causing rackspace's dfw region to be unable to reach pypi.org's fastly cdn endpoint
15:05:56 <dhellmann> o/
15:06:24 <fungi> thursday it was an openstackansible bug causing the neutron ovs agent not to restart on a host in vexxhost's sjc1 region
15:06:41 <ttx> smcginnis: what? I did put something on the agenda!
15:06:57 <smcginnis> Oh, OK. All appears to be resolved now.
15:06:59 <fungi> both had the effect of causing connectivity issues/disruptions to or from the mirror servers, but that was merely a symptom of a much larger problem in both cases
15:07:01 <smcginnis> ttx: I see that now, sorry.
15:07:30 <smcginnis> Anyway, they all appear to be resolved and we've done a few. The failed ones were reenqueued and everything worked as expected.
15:07:41 <fungi> yep!
15:07:58 <smcginnis> #topic Release type tracking
15:08:04 <ttx> o/
15:08:07 <smcginnis> #link  https://etherpad.openstack.org/p/UChiqxElUV
15:08:14 <smcginnis> ttx: OK, all yours.
15:08:16 <ttx> I'm slowly going down all those corner cases
15:08:39 <ttx> Forces us to look into things we happily kept in the shadows before
15:09:02 <ttx> I had one question
15:09:06 <smcginnis> Ignorance is bliss? :)
15:09:24 <ttx> Basically there is a gap between governance addition and release addition
15:09:44 <ttx> and once we cover all the corner cases, that's what will be left
15:09:57 <ttx> how do we want to handle those
15:10:13 <ttx> are we happy to let them go release-less forever ?
15:10:24 <ttx> should we aggressively seek to add deliverable files to cover them ?
15:10:37 <smcginnis> Projects just added to governance?
15:10:42 <ttx> (which means choosing a release model really)
15:10:52 <ttx> smcginnis: new deliverables
15:11:04 <ttx> (from new or existing projects)
15:11:49 <ttx> example: tenks. Was added recently, so showed up in my report. Ironic team hopes to make a release soon, but it's unclear when that will happen
15:12:26 <smcginnis> We could add that as one of the required things for deliverables added to projects.yaml in the governance repo, but that doesn't feel like the right place for that kind of thing.
15:12:29 <ttx> should we have some kind of a pre milestone-2 review to parse the list of new deliverables?
15:12:44 <ttx> smcginnis: I fear it might be too early
15:13:05 <smcginnis> That may be a good idea. We could add to our process doc that we need to perform an audit for those things every milestone 2.
15:13:12 <dhellmann> you have a tool to show the list of things in governance but not in the releases repo?
15:13:12 <ttx> yes, check once per cycle.
15:13:32 <ttx> dhellmann: I have a tool I used to create my gap list yes
15:13:44 <fungi> it's certain there are teams who add deliverables that take a year or more to actually get off the ground, so while there's probably no harm in forcing them into some sort of release cadence during their formation i expect a lot of teams won't see the benefit in that
15:13:52 <dhellmann> yeah, then it seems like a periodic manual review would work
15:13:54 <smcginnis> And it may be that they still don't know by m-2, but at least it would be a point to remind them it will need to be done and help us catch things from slipping between the cracks.
15:13:57 <ttx> once we fix all the corner cases and historical oddities, it should be pretty reliable to catch new things
15:14:35 <ttx> and if something is not "ready" by stein m-2 we can wait... and if it's still not ready by train-2 we'd question whether it needs to stay or not
15:14:52 <dhellmann> wfm
15:14:58 <smcginnis> At least we would know.
15:15:02 <ttx> yes
15:15:08 <ttx> OK, I can document that
15:15:10 <smcginnis> ttx: Want to add something to process.rst for this?
15:15:13 <smcginnis> Hah, good.
15:15:25 <dhellmann> and check that tool into the releases repo?
15:15:25 <fungi> what's the downside to letting new official deliverables just be release:independent by default until they pick something else?
15:15:38 <ttx> But we first need to clean the list so that it only contains new stuff :)
15:15:42 <smcginnis> #action ttx to document new deliverable review process for milestone 2.
15:16:14 <ttx> fungi: the change from independent to cycle-tied is a bit dirty
15:16:21 <ttx> it leaves things around
15:16:31 <ttx> I mean behind
15:16:36 <fungi> ahh
15:16:58 <ttx> Like you end up with entries on both sides without clearly knowing which one applies
15:17:04 <smcginnis> We could add something like an _undeclared group, but I think that would be overkill.
15:17:08 <fungi> so better that they skip participating in releases and then jump straight to cycle-oriented release models once they're ready to start making releases?
15:17:14 <ttx> yes
15:17:22 <fungi> got it
15:17:36 <ttx> it's also consistent with our "release membership" deadline
15:17:53 <ttx> and for independent things, it's a one-in-a-cycle health check
15:18:56 <smcginnis> Per cycle manual checks work for me. Seems like a low impact way to handle this.
15:20:16 <ttx> Thanks, will do
15:20:26 <smcginnis> OK, I think we have consensus. Let's go with that.
15:20:28 <ttx> </over>
15:20:46 <smcginnis> #topic Open discussion
15:20:51 <smcginnis> That's all on the agenda.
15:21:04 <smcginnis> I should point out I'm travelling next week.
15:21:12 <ttx> did we need to make further progress on the release process changes ?
15:21:13 <smcginnis> I believe I should be around for the meeting though.
15:21:19 <smcginnis> Which changes?
15:21:32 <smcginnis> Oh, the work from the PTG>
15:21:38 <ttx> I seem to remember we had several steps to sell
15:21:59 <smcginnis> I had started a script to identify cycle-with-intermediary deliverables to release at milestones.
15:22:11 <smcginnis> I need to give that a little more attention and push that up.
15:22:35 <smcginnis> We changed -with-milestones to -with-rc, so that part I think is mostly good.
15:23:30 <ttx> did we do ""announce the "choose your model" moment at milestone-2 for intermediary things that haven't released yet""
15:24:00 <smcginnis> No, I don't believe so.
15:24:05 <ttx> That's a big one
15:24:19 <smcginnis> I need to look back over everything we had planned to do.
15:24:39 <smcginnis> That would be for the non-library intemediary things, right?
15:24:44 <ttx> basically we were planning to tell every cycle-intermediary thing that has not released anything by milestone-2 that they need to release now or switch to cycle-with-rc
15:25:04 <smcginnis> I'll add that to the next countdown email draft.
15:25:22 <smcginnis> We have some time, so I'll mention now, then we can bring up again at m-2.
15:25:22 <ttx> I feel like we need a specific thread to communicate that
15:25:32 <ttx> sicne it's a big change...
15:25:35 <dhellmann> we may want to do that as a separate email, too
15:25:37 <smcginnis> OK, you're probably right.
15:25:51 <fungi> is that a reversal from the discussion at the ptg where they were going to end up with a release forced for them at milestone 2 instead?
15:26:02 <ttx> The original plan was to start communicating that doing a single release while on cycle-intermediary is not OK. We did not do that really
15:26:26 <ttx> https://etherpad.openstack.org/p/relmgt-stein-ptg lines ~47
15:26:59 <smcginnis> We didn't directly state that, but with the announcement of changing intermediary library releases to be automatically proposed for releases at the milestones it did kind of say that.
15:27:22 <ttx> yeah, i feel like we did enough prep work, we can drop the hammer in one go
15:27:42 <ttx> but I'd drop it soon
15:27:59 <fungi> oh, got it. specifically it was change the release model at milestone 2 if you're a service deliverable, get a release forced for you if you're a library
15:28:08 <ttx> yes
15:28:39 <fungi> at first it sounded like you meant all cycle-with-intermediary (or do libraries now get their own separate release model name?)
15:28:39 <ttx> basically cycle-with-intermediary is not meant to do a single release per cycle (if you do that, you should really be using RCs)
15:28:50 <ttx> (for services)
15:29:09 <smcginnis> Wrote down an action for me to draft something to the ML.
15:29:32 <ttx> so you get to pick between one-per-cycle (with RCs to prep) and 'at least twice-per-cycle'
15:29:50 <ttx> that removes the whole uncertainty at the end of the cycle
15:30:08 <ttx> (we can fall back on last RC or last intermediary, if nobody shows up
15:30:48 <ttx> smcginnis: ISTR we had email drafts on an etherpad... but maybe not for this one
15:31:01 <smcginnis> Yeah, I don't think we did for this one.
15:31:36 <ttx> https://etherpad.openstack.org/p/stein-relmgt-auto-release-change
15:32:14 <ttx> ETOOMANYETHERPADS
15:32:32 <smcginnis> Indeed.
15:32:42 <smcginnis> Well that's good, content is basically ready to go.
15:33:03 <smcginnis> Email 3 can probably just be merged into email 4 at this point?
15:34:01 <ttx> yeah
15:34:10 <smcginnis> OK, I'll work on that.
15:34:16 <ttx> probably needs some polish before sending :)
15:34:21 <smcginnis> Yeah.
15:34:26 <ttx> ok that is all I had
15:34:39 <smcginnis> Think I should wait until early next week to send it so it doesn't get lost over the weekend?
15:35:12 <ttx> sure, early next week would be ideal
15:35:34 <smcginnis> OK, I'll make a note to send it before I have to head to the airport.
15:36:30 <smcginnis> OK, anything else for this week?
15:37:19 <fungi> as of next week there won't be an openstack-dev list any longer, so no need to worry about cross-posting announcements like that either
15:37:28 <dhellmann> \o/
15:37:39 <smcginnis> Great!
15:37:54 <smcginnis> OK, thanks everyone. Have a good weekend.
15:38:04 <smcginnis> #endmeeting