13:01:53 <dhellmann> #startmeeting releaseteam
13:01:54 <openstack> Meeting started Mon Nov  9 13:01:53 2015 UTC and is due to finish in 60 minutes.  The chair is dhellmann. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:01:57 <openstack> The meeting name has been set to 'releaseteam'
13:01:59 <ttx> o/
13:02:06 <dhellmann> courtesy ping for ttx, dims, lifeless
13:02:06 <ttx> I'll let you mix
13:02:22 <dhellmann> I started an agenda in the calendar portion of https://etherpad.openstack.org/p/mitaka-relmgt-plan
13:02:42 <dhellmann> and ttx added some items to https://wiki.openstack.org/wiki/Release_Cycle_Management
13:03:21 <dhellmann> ok, starting with meeting time
13:03:26 <dhellmann> #topic meeting time
13:03:55 <dhellmann> I'd like to push this back an hour, if we can? with the daylight savings time shift, it's a bit early here
13:04:01 <ttx> Works for me
13:04:22 <dhellmann> ok, I'll update the meeting schedule in the wiki and eavesdrop
13:04:42 <ttx> #agreed meeting time change 1400 UTC Mondays
13:04:54 <dhellmann> thanks
13:05:06 <dhellmann> #topic release notes vs. deliverables
13:05:14 <dhellmann> I saw the question from SergeyLukjanov in #openstack-release
13:05:23 <SergeyLukjanov> o/
13:05:40 <ttx> It feels like a given deliverable should have a given release notes doc
13:05:42 <dhellmann> I expected each repo to have reno installed, but I see your point about one set of notes per deliverable
13:05:51 <ttx> since that's the same "release"
13:06:07 <ttx> maybe it's just about combining things from multiple repos
13:06:14 <ttx> into a single doc
13:06:33 <ttx> so they would still all have reno
13:06:51 <SergeyLukjanov> probable reno support building release notes from several repositories? and conf located in a "main" deliverable repo?
13:06:52 <ttx> but reno could generate "deliverable release notes" given a list of projects ?
13:06:53 <dhellmann> through reno, or when we push the HTML to docs.openstack.org?
13:07:48 <ttx> dhellmann: I guess the important part is to have a single something we can point users to when we do a release announcement
13:08:05 <dhellmann> how ugly would it be to simply put the notes in one repo this cycle?
13:08:11 <ttx> i.e. Sahara 6.0.0 is out, here are the release notes, here are the tarballs
13:08:46 <dhellmann> I'm not sure the sphinx stuff in the releases repo supports multiple deliverables right now, either
13:08:47 <ttx> dhellmann: that would separate the notes change from the change itself... apart from that, not too ugly I suppose
13:09:14 <ttx> it just makes one of the repos "special"
13:09:16 <SergeyLukjanov> IMO it's not so ugly to store all release notes in single repo
13:09:21 <dhellmann> right, longer term we'd want to have them closer to the code, but short term we have other things we have to implement this cycle
13:09:42 <ttx> we haven't that many deliverables anyway
13:09:54 <ttx> neutron I expect would suffer the most
13:10:05 <ttx> since the -aas teams are pretty separate
13:10:23 <dhellmann> I think the neutron teams have started adding reno to each repo, let me look at the list of patches again
13:10:44 <ttx> so having them contribute release notes to the other repo would certainly be more painful than for sahara or manila
13:10:47 <dhellmann> #link https://review.openstack.org/#/q/topic:add-reno,n,z
13:11:26 <dhellmann> I see a patch for neutron and networking-cisco
13:11:59 <ttx> OK, let's just say that deliverables use release notes in a main repo
13:12:08 <ttx> and punt that to next
13:12:10 <dhellmann> yeah, let's give this more thought but do the simple thing for now
13:12:34 <dhellmann> #action dhellmann follow-up to reno thread on ML with instructions for multi-repo deliverable projects
13:13:16 <dhellmann> #topic governance reviews
13:13:39 <dhellmann> Update Octavia release model: https://review.openstack.org/#/c/226933/
13:14:02 <ttx> that one sounds pretty good to me
13:14:14 <dhellmann> that one has sign-off from the ptl and both of us, so I think we should go ahead and merge it
13:14:29 <ttx> reok, pushing it now
13:14:45 <dhellmann> Make ironic-inspector and its client release:managed https://review.openstack.org/#/c/237611/
13:15:26 <ttx> how is the ironic release liaison work going so far ?
13:15:49 <ttx> I feel like they are on top of it
13:15:57 <dhellmann> they've been fairly responsive
13:16:08 <ttx> and they already have managed stuff
13:16:22 <dhellmann> yeah, that was key for me
13:16:23 <ttx> so I'd be +1 on it, if you're comfortable with the load
13:17:02 <dhellmann> well, under the new "we're not going to come looking for you" system, it shouldn't add to much
13:17:04 <ttx> basically for project teams we already handle and that have responsive liaisons, I'm +1. I'm +0 on everything else until we nail the automation
13:17:15 <dhellmann> I agree
13:17:41 <dhellmann> ok, let's take the change and add the 2 projects
13:17:51 <ttx> ok, approving now
13:17:51 <dhellmann> er, deliverables :-)
13:18:26 <ttx> done
13:18:44 <dhellmann> #topic progress on relmgt-plan
13:18:57 <dhellmann> we have a few sub-items here
13:19:06 <ttx> yes, let's start with those
13:19:30 <dhellmann> first, based on some discussion in one of the team meetings I noticed last week, I realized we haven't updated the liaison duties in the project team guide to reflect the changes in our use of LP
13:20:13 <dhellmann> maybe we should talk about that last item, "expand on 'getting rid of LP for change management within projects'" a bit before we talk about doc changes
13:21:14 <dhellmann> ttx: I think that was your item, what did you feel needed to be expanded?
13:21:42 <ttx> when I reviewed the paragraph last week I wasn't sure we covered all the bases
13:22:18 <ttx> it's not a clear set of actions
13:22:41 <ttx> like "we might be breaking some statistics gathering tools by not targeting bugs to milestones"
13:23:00 <ttx> should really be "look up tool X and check of we are going to break it"
13:23:13 <ttx> i.e. turn the discussion into a series of actions
13:23:22 <dhellmann> more than stackalytics?
13:23:29 <ttx> probably not
13:24:35 <dhellmann> who owns that code?
13:24:38 * dhellmann checks gerrit
13:25:04 <dhellmann> https://review.openstack.org/#/admin/groups/183,members
13:29:34 <ttx> what did you mean by "options: -direct-release) like in infra-manual ??"
13:30:54 <dhellmann> I don't know what that is. I probably was typing as someone was talking in the room.
13:32:53 <ttx> ok, I think the action plan is clearer now
13:33:04 <dhellmann> yeah, that looks much better
13:33:50 <ttx> ok, we can move on
13:33:58 <dhellmann> the release tools are still creating and updating milestones, should we change that before M1?
13:34:26 <ttx> I'm unsure which tools we'll be using for M1
13:34:48 <dhellmann> yeah, I was thinking of the post-versioning script we use for libraries
13:35:31 <dhellmann> ok, good
13:35:51 <ttx> I'll take the release tooling analysis. I removed myself from the stackalytics check
13:35:59 <dhellmann> should we roll the liaison duties changes into this action list?
13:36:16 <dhellmann> I'll ping the stackalytics folks and ask them to figure it out
13:36:27 <ttx> it's more a "new model for milestones" thing I think
13:37:35 <dhellmann> do you want to look at that list of duties, or shall I?
13:38:04 <dhellmann> I'll take it
13:38:06 <ttx> please do
13:38:27 <dhellmann> ok, let's talk about splitting off the stable team
13:38:43 <dhellmann> at the summit we discussed recommending that they stand as a separate team
13:38:53 <dhellmann> do we have enough people involved to make that work?
13:39:23 <ttx> I think we do. I feel like the duties are now well separated with the release team
13:39:24 <dhellmann> I did not notice a lot of involvement from folks I thought were stable maintainers on the mailing list thread about extending the kilo support window
13:40:12 <ttx> yeah. I fear there is a bit of chicken-and-egg though. They don't really own that piece
13:40:27 <dhellmann> yeah
13:40:33 <ttx> So they would start by being the stable branch policy custodians
13:40:47 <ttx> and hopefully grow into owning the health of the branches themselves
13:40:48 <dhellmann> good point
13:40:49 <Jokke_> dhellmann: do we actually know if we have enough folks or not before splitting the team. IMHO the stable group is really suppressed unless really needed anyways
13:41:11 <dhellmann> Jokke_ : that was my initial question
13:41:13 <dhellmann> #link https://review.openstack.org/#/admin/groups/120,members
13:41:17 <ttx> well, the thing is, the release team doesn't handle the stable team. So it's not a "split"
13:41:22 <dhellmann> lots of names on that list, but I'm not sure how many are active
13:41:31 <dhellmann> ok, poor choice of words
13:41:43 <ttx> I guess the question is more: do we have a stable team
13:41:55 <dhellmann> they're under the release ptl now, though, and we want *that* to change
13:42:14 <ttx> if it needs to be under life support under release management to survive, I'd say it needs to die
13:42:18 <dhellmann> well, yes, identifying the active team members is a good place to start
13:42:28 <Jokke_> yeah ... currently we do not have stable team, but bunch of folks who work either under the projects or rel management
13:42:34 <ttx> I feel like we have prevented them from owning the issue though
13:42:44 <Jokke_> ttx: ++
13:42:52 <ttx> mostly my fault, having a foot in two places
13:43:10 <ttx> If they had their team and PTL, they could also justify the resources
13:43:21 <dhellmann> yeah, looking at this list I think some are actually fairly active these days
13:43:28 <ttx> rather than be the 4th wheel of release management
13:43:36 <Jokke_> ttx: I think that would help
13:43:40 <dhellmann> right, so what's the first step?
13:43:47 <dhellmann> s/first/next
13:43:50 <ttx> dhellmann: I'll propose it this week to the list
13:43:52 <dhellmann> k
13:43:54 <ttx> see who steps up
13:44:08 <dhellmann> #action ttx propose stable maintenance team be set up with its own PTL
13:44:17 <ttx> it might actually be good timing with that stable discussion
13:44:32 <dhellmann> serendipity for the win
13:44:47 <ttx> because seriously, the gap between the number of people needing those branches and the number of people stepping up to help is huge
13:45:08 * dhellmann nods
13:45:34 <ttx> anyway, will sned that this week and we'll see where it goes
13:45:38 <johnthetubaguy> just to check, we said the projects own their own stable branch releases at the moment?
13:45:45 <ttx> I'm mostly trying to refocus the release team or release things
13:45:50 <ttx> on*
13:46:04 <ttx> rather than make us decide for a bunch of other folks on stable matters
13:46:14 <dhellmann> johnthetubaguy : yes, we're talking about the overall stable maintenance team that manages the policy, etc. rather than landing patches, per se
13:46:22 <ttx> and preventing them from stepping up
13:46:33 <johnthetubaguy> dhellmann: cool, makes sense
13:46:53 <dhellmann> ttx: ++
13:46:54 <ttx> dhellmann, johnthetubaguy: well ideally that team would grow people that would maintain the stable branches too
13:47:05 <ttx> but one step at a time :)
13:47:11 <dhellmann> ttx: sure
13:47:21 <johnthetubaguy> ttx: yeah, good call
13:47:27 <ttx> At this stage I just want to empower the few people that help
13:48:11 <dhellmann> let's move on, one or two more things to cover
13:48:14 <ttx> dhellmann: ack
13:48:28 <dhellmann> for "next steps on automation" I think I just need to work with fungi on the spec
13:48:45 <dhellmann> we did mention some other changes to existing tools during the LP discussion
13:49:23 <dhellmann> I'm going to try to focus on the spec this week, and leave the code changes for late in the week or early next
13:50:41 <dhellmann> for the reno rollout, we need a publishing job set up to copy files from project builds up to docs.openstack.org/releasenotes (the place loquacities and ajeager agreed on)
13:50:51 <ttx> ok
13:51:39 <dhellmann> I added that as an action under "enable new model for milestones"
13:52:23 <dhellmann> ok, I think that's it for the agenda
13:52:28 <dhellmann> #topic open discussion
13:52:32 <ttx> ack, nothing else for me
13:52:51 <dhellmann> I noticed some of the reno-related tasks are duplicated, so I'll go through the plan and clean that up a bit
13:53:04 <dhellmann> the feature stuff related to version handling, in particular, shows up twice
13:53:39 <dhellmann> other than that, I think we're done
13:54:00 <ttx> agreed
13:54:05 <dhellmann> good, we can go ahead and sign off a bit early
13:54:12 <dhellmann> thanks, ttx!
13:54:18 <dhellmann> #endmeeting