15:01:00 <ttx> #startmeeting releaseteam
15:01:01 <openstack> Meeting started Fri Jun 16 15:01:00 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:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:04 <openstack> The meeting name has been set to 'releaseteam'
15:01:10 <ttx> Ping list: dhellmann, dims, fungi, tonyb, stevemar, lbragstad
15:01:12 <dhellmann> o/
15:02:23 <ttx> Agenda at https://etherpad.openstack.org/p/pike-relmgt-tracking
15:02:34 <ttx> scroll down to R-11
15:02:44 <ttx> #topic Still-missing libs
15:02:58 <ttx> so we have a number of libs that haven't released yet
15:03:04 <ttx> was wondering if we should do anything about it
15:03:19 <dhellmann> I can prod Brian on the glance-store release
15:03:20 <ttx> We could also just say we'll tag them as needed if nothing was done
15:03:25 <dhellmann> the others seem minimal
15:03:40 <ttx> like, we do need a y bump right
15:03:57 <ttx> (at the very least) by the lib deadline
15:04:19 <ttx> how about we force one if they don't ?
15:04:56 <ttx> would spare us the chasing exercise
15:05:04 <dhellmann> we could float that idea
15:05:05 <ttx> I mean, we should still encourage them to do it
15:05:11 <dhellmann> I'd hate to be responsible for releasing a broken lib
15:05:38 <ttx> but if they don't, rather than go out of our way getting them to do it, we would just release it
15:05:44 <ttx> hmm, good point
15:06:08 <ttx> Oh
15:06:12 <ttx> We could just retag the last one
15:06:23 <ttx> that way our needs are covered
15:06:32 <dhellmann> that would give us a place to create the new branch
15:06:32 <ttx> (our needs = the .y bump)
15:06:47 <dhellmann> we don't need to change the version for that
15:07:01 <dhellmann> actually, if we do that, we'll likely have libs with mismatched requirements
15:07:08 <dhellmann> so we do need to land those g-r updates and do a new release
15:07:12 <ttx> hmm, you still need to give room for point releases from the previous series, right ?
15:07:55 <dhellmann> oh, true
15:08:04 <dhellmann> yeah, it's better for us not to branch from the same place
15:08:11 <ttx> also lets us land those requirements sync
15:08:18 <dhellmann> I think if we have to force something, a new release is the best of several bad options
15:08:38 <ttx> I'd rather do that than try to force someone that doesn't want to hear to listen
15:09:26 <ttx> next countdown email (in two weeks) I warn the remaining libs that we'll force a release if they don't have one by the deadline
15:09:58 <ttx> which is just stating what we'll have to do if they don't react anyway
15:10:05 <ttx> that or removing the lib
15:10:12 <dhellmann> that may be worth a separate email
15:10:30 <fungi> that gets extra fun given libs tend not to exist in a vacuum
15:11:13 <ttx> My expectation would be that people will be more unhappy because the things they landed in master won't make it into Pike, than about us triggering a release
15:11:30 <dhellmann> I hope so
15:11:45 <ttx> ok, hopefully we won't have to force that
15:11:59 <dhellmann> does this only apply to libraries, or does it include anything in the g-r list?
15:12:05 <dhellmann> we have some non-libs in that list
15:12:32 <ttx> dhellmann: like? not sure what you mean
15:12:40 <dhellmann> mistral was in that list, wasn't it?
15:12:53 <dhellmann> several of the cycle-with-intermediary services where they didn't do a clean split to create a lib
15:13:02 <dhellmann> s/several/a couple/
15:13:23 <ttx> ah, that. I'd argue that's a bug (but we might need to workaround those exceptions)
15:13:23 <dhellmann> would we force releases for those, too?
15:13:40 <ttx> if we didn't have Pike releases for them, yes
15:13:46 <ttx> I think we do, though
15:13:52 <dhellmann> ok
15:13:53 <dhellmann> ah, good
15:14:14 <ttx> although mistral is still cycle-with-milestones apparently
15:14:28 <dhellmann> I might be misremembering which project it was
15:14:38 <ttx> it was mistral
15:15:10 <ttx> probably not a solved issue yet
15:15:39 <dhellmann> we have quite a few intermediary projects without releases (see the etherpad)
15:16:40 <ttx> dhellmann: I would apply the same rule if we are stuck with nothing by the end of the cycle. Force release or dump
15:16:47 <dhellmann> ++
15:16:56 <ttx> it just happens a bit later
15:17:02 <ttx> I expect those to only do one release at this point
15:17:03 <dhellmann> yeah, that reminder email should make that clear
15:17:31 <ttx> which imho should trigger a "do you REALLY want to be cycle-with-intermediary in those conditions ?"
15:18:08 <dhellmann> yeah, if they're only doing 1 that sounds like they should be milestone
15:18:25 <dhellmann> and if they're not doing any, we should remove them from the release list
15:18:25 <ttx> to be fair that is pretty close to how we operate with everything
15:18:46 <ttx> (retag on last known tag)
15:19:04 <ttx> it's just that some models are more conducive to generating a recent tag
15:19:29 <ttx> cycle-with-intermediary is "I can take care of myself, thanks"
15:19:38 <ttx> and yet some teams don't / can't
15:20:06 <ttx> OK, let's plan to communicate around that in the coming week(s)
15:20:09 <dhellmann> ++
15:20:24 <ttx> anything else on that topic ?
15:20:34 <dhellmann> nothing from me
15:20:36 <ttx> #topic Review Pike3 TODOs
15:21:17 <ttx> wanted to review tasks that are marked PIKE3
15:21:21 <ttx> Ensure changes to the (pre-)release branch are backports (ttx)
15:21:29 <ttx> I'll be able to complete that, that's mostly doc updates
15:21:38 <ttx> Port all release tools to work under python 3 (dhellmann, dims, others)
15:21:49 <dhellmann> I think the only thing left there is to turn on the unit test job in https://review.openstack.org/#/c/470352/
15:21:50 <ttx> Also on track ?
15:21:50 <patchbot> patch 470352 - openstack-infra/project-config - add python 3.5 unit test job for release-tools rep...
15:21:54 <dhellmann> fungi, can you look at that one?
15:21:55 <ttx> ok
15:22:07 <dhellmann> other than that, we've ported all of the tools we *can* port
15:22:10 <ttx> support storyboard in openstack/releases (tbd)
15:22:17 <dhellmann> until we get a lazr client update that works with py3
15:22:27 <ttx> nice
15:22:38 <fungi> dhellmann: sure, i'll take a look here in a moment
15:22:39 <dhellmann> maybe we can get the storyboard team to help with that? is there a CLI?
15:22:42 <dhellmann> fungi : thanks
15:22:56 <ttx> Not much success asking for a volunteer yet. I can probably take it over next cycle if nobody picks it up
15:23:02 <ttx> not sure it's THAT urgent
15:23:05 <dhellmann> ok
15:23:25 <ttx> the "storyboard team" is pretty busy pushing the last bits that are necessary for everyone to be able to switch
15:23:29 <ttx> that is more urgent
15:23:29 <fungi> dhellmann: there is a cli if you don't want to use the api directly
15:23:32 <dhellmann> I agree
15:23:36 <ttx> also they are working on their free time at this stage
15:23:48 <ttx> so their time is limited and precious
15:23:51 <dhellmann> fungi : ok, that may make this script we need easier
15:23:52 <dhellmann> ah, ok, let's not pile on more work then
15:24:00 <ttx> Consolidate the release tools that use the releases repository data in the releases repository (dhellmann)
15:24:12 <dhellmann> the next step for that was the announce scripts
15:24:16 <fungi> i did follow up on the release tooling implementation thread on the ml with some suggestions (which i also ran by the sb team this week in irc to confirm they're grounded in reality)
15:24:22 <dhellmann> I was going to move those into the releases repo
15:24:46 <dhellmann> I'm not sure how high of a priority that is, though, and the doc migration stuff is eating up more of my time right now
15:25:24 <ttx> dhellmann: it's fine to push it back to next cycle. It's technical debt reduction
15:25:34 <dhellmann> I think we should just assume that's the plan, then
15:25:34 <ttx> we actually have more urgent items that were untouched
15:26:08 <ttx> Anything else we should add ?
15:26:26 <ttx> I wanted to review things that tonyb originally signed up for, see if there are thiungs we absolutely need
15:26:44 <ttx> since at this point there is a backlog of work on the stable maint side
15:27:02 <dhellmann> ++
15:27:06 <ttx> looking at https://etherpad.openstack.org/p/pike-relmgt-plan
15:27:27 <ttx> Let's read that and mention here anything that may make sense as a Pike priority
15:28:04 <ttx> "Step in the branch script that tries to fix the upper constraints url does not work for all repos" maybe
15:28:09 <ttx> line 77
15:28:52 <ttx> "do not propose constraint updates for pre-release versions" maybe
15:28:56 <ttx> line 119
15:29:13 <dhellmann> I think we resolved constraints url update issue, but if not we should make a list of the specific cases at the end of this release
15:29:30 <dhellmann> I think we sorted out the pre-release version thing by changing the release model for the project
15:29:54 <ttx> ok, let's mark it fixed then and reopen if it fails again
15:30:16 <ttx> althoug hmistral hasn't switched yet
15:31:04 <ttx> Is line 138 solved now that gnocchi is no longer in openstack ?
15:31:05 <dhellmann> maybe we can preemptively change them for queens
15:31:23 <dhellmann> probably
15:31:47 <ttx> added a note about checking the mistral situation next week
15:33:52 <ttx> Check all the deliverables that are available on pypi have the include-pypi-link attribute (tonyb)
15:34:25 <dhellmann> I think that was a data consistency thing. I don't think it's especially high priority.
15:34:29 <ttx> ok
15:34:35 <dhellmann> if we had a new recruit, I would give it to them to script
15:34:51 <ttx> Looks like we are good. Only a couple of Pike3 items actually
15:35:08 <dhellmann> we could also change the release job logic to not need the explicit flag, and to check for the pypi project on its own
15:35:11 <ttx> Python 3 work, a bit of doc update
15:35:35 <ttx> ok, all the rest will likely end up in the backlog
15:35:59 <ttx> #topic Open discussion
15:36:02 <ttx> Anything else ?
15:36:06 <dhellmann> tfw you have an idea and go to write it down, and you already have
15:36:25 <ttx> happens to me a lot in the release management
15:36:36 <ttx> It's /really/ easy to forget the corener cases you already handled
15:36:40 <ttx> corner*
15:37:27 <dhellmann> I don't have anything else to add this week
15:37:43 <dhellmann> aside from those lagging releases, things seem to be going fairly smoothly this cycle
15:37:55 <dhellmann> oh, did we get an answer from the congress team?
15:38:04 <dhellmann> sorry, not congress, designate
15:38:20 <ttx> I did -1 it
15:38:26 <dhellmann> yeah, I see now
15:38:40 <dhellmann> ok, it seems fine to let that one go until p3
15:38:58 <ttx> yep, will abandon that one if they don't yell
15:39:07 <ttx> little point in doing p2 now
15:39:14 <dhellmann> right
15:39:20 <ttx> ok, meeting over then
15:39:25 <ttx> Have a great weekend
15:39:39 <dhellmann> I wonder if it makes sense to just automate the milestone tags
15:40:04 <ttx> dhellmann: part of it is training people to deadlines
15:40:04 <dhellmann> though I guess the point is to have the teams thinking about releases throughout the cycle, and that would not do it
15:40:06 <dhellmann> yeah
15:40:20 <ttx> It's almost a drill exercise
15:40:20 * dhellmann stops thinking out loud
15:40:34 <ttx> exercises the release machinery
15:40:53 * dhellmann nods
15:41:03 <ttx> alright, have a good end of day and weekend then
15:41:06 <ttx> #endmeeting