13:04:00 <ttx> #startmeeting releaseteam
13:04:01 <openstack> Meeting started Mon Jul 27 13:04:00 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:04:04 <openstack> The meeting name has been set to 'releaseteam'
13:04:35 <ttx> dhellmann: anything urgent before we discuss liberty-2 ?
13:05:03 <dhellmann> no, I think think there's anything "urgent"
13:05:18 <ttx> #topic liberty-2
13:05:27 <ttx> So this week we have the liberty-2 dev milestone
13:06:03 <ttx> We wrote this last time:
13:06:04 <ttx> https://wiki.openstack.org/wiki/Release_Cycle_Management/Milestone_Checklist
13:07:14 <ttx> dhellmann: was wondering if we should make PTLs go through a releases change to communicate the SHA
13:08:01 <dhellmann> yeah, that's a good idea
13:08:09 <ttx> we'll have to push that anyway
13:08:15 <dhellmann> it will save us from having to import it later
13:08:38 <dhellmann> I've been focusing on the post-version release tool updates, but we can just do the milestone work by hand for now
13:08:44 <ttx> process could be: communicate a tag before Thursday there, or we'll make one for you
13:08:47 <dhellmann> but using the releases repo to record the request
13:08:50 <dhellmann> heh
13:09:09 <dhellmann> yeah, I think that works
13:09:41 <ttx> The only thing we can't really invent ourselves is the cleanup / update of the launchpad stuff
13:09:42 <dhellmann> we've had a couple of teams use that repo already for libraries, so I think the instructions for editing the files make some sense
13:09:54 <dhellmann> true
13:10:06 <ttx> so tomorrow we should get that covered, and point to releases repo
13:10:51 <ttx> That prevents the usual "please tag once those are in" type communication
13:10:54 <dhellmann> that works -- should we go ahead and update the wiki page, too?
13:11:03 <dhellmann> it does, and that means less tracking for us
13:11:11 <dhellmann> they can use depends-on to track it automatically
13:11:37 <dhellmann> although they have to point to a sha that actually exists, so I'm not sure depends-on is going to be the right approach
13:11:48 <dhellmann> they  might need to point to a merge commit, for example
13:12:02 <ttx> dhellmann: could they set "HEAD" as SHA or something and we'd update that when we are ready to merge ?
13:12:29 <ttx> then a HEAD + a depends-on would mean: "release whenever that is in"
13:12:34 <dhellmann> the validation code rejects anything that isn't an actual sha, right now
13:12:53 <ttx> and a HEAD without depends on would mean "release with anything that made it between this proposal and when you process it"
13:13:35 <dhellmann> I hesitate to encourage that.
13:13:55 <dhellmann> I see the benefit, but it moves most of the burden back to us.
13:13:57 <ttx> dhellmann: yeah, I tend to agree with you
13:14:27 <dhellmann> If we encourage them to use a real sha, we can process the request at any time and it will point to the thing they expect.
13:14:35 <dhellmann> no surprises
13:14:36 <ttx> I guess "merge when that is in" would rather translate to us making up the releases change
13:14:46 <dhellmann> right
13:14:57 <ttx> ok, that sounds good
13:15:23 <ttx> questions on the process ?
13:15:47 <ttx> Should we remind the PTL of the upcoming milestone ? Remind them they should attend office hours tomorrow ?
13:15:53 <dhellmann> https://review.openstack.org/#/c/205245/ will show them the "unreleased" changes, so they can verify that they're getting what they expect -- it would be good to get that set up this week
13:16:03 <dhellmann> yes, I think reminders are always good
13:16:17 <ttx> OK, will do, and I'll also create a etherpad tracking page for us
13:16:22 <dhellmann> I'll review the checklist early today and ping you if I can't remember what something means
13:16:33 <dhellmann> ++
13:16:41 <ttx> #action ttx to send l2 reminder
13:16:48 <ttx> #action ttx to create tracking etherpad
13:17:12 <dhellmann> dims_: I wonder if we should wait to do all of those oslo releases with the version changes until after the L2 milestone this week?
13:17:28 <dhellmann> dims_: I wasn't thinking about the date last week when I suggested clearing that backlog.
13:18:00 <dhellmann> #link https://etherpad.openstack.org/p/library-releases
13:18:31 <dhellmann> I'll talk to dims_ about that out of the meeting, it looks like he has a review up for the changes
13:19:36 <ttx> dhellmann: on the "deliverables / set a release model for everything" side, I'll try to push the "deliverables" new format for project.yaml tomorrow at the TC meeting
13:19:47 <ttx> I'm finalizing the tooling changes
13:20:00 <ttx> so it could be a good idea to rebase on top of that
13:20:45 <dhellmann> ttx: yes, I expect that patch will take a few revisions
13:21:08 <dhellmann> I'm not sure it's a super high priority, so I might wait until next week to update and try to work on the py3 devstack changes I have in my backlog this week
13:21:20 <ttx> sure
13:21:44 <ttx> just a warning that I'll generate a pretty massive merge conflict for you tomorrow, if all goes well
13:22:02 <dhellmann> ok, that's expected :-)
13:22:31 <ttx> That is all I had -- any other topics ?
13:24:05 <dhellmann> are you caught up on the requirements work we were doing last week with the validation job? I have some reviews up, and comments from lifeless I need to respond to.
13:24:29 <ttx> not fully caught up yet
13:24:38 <dhellmann> https://review.openstack.org/#/q/status:open+project:openstack/requirements+branch:master+topic:refactor-integration-tests,n,z
13:24:44 <ttx> if there is anything I need to review to unblock stuff, I'm still in a "ping me to get reviews" mode
13:25:06 <dhellmann> ok, I'll do that after I push the next versions of the patches
13:25:12 <ttx> ack
13:25:38 <ttx> #topic Open discussion
13:25:59 <ttx> dhellmann: I had a question about intermediary releases for service projects
13:26:07 <dhellmann> I'm going to PyOhio this weekend, so I'll be out Friday and Monday
13:26:32 <ttx> are we ready to handle those at this point ? Or will we just figure it out for the first one that asks ?
13:27:09 <dhellmann> I think we're ready, but we may need to do a little cleanup as part of the first release for each project
13:27:25 <dhellmann> ideally we would tag a release and then the next commit to land in that project would be one to remove the version from setup.cfg
13:27:51 <ttx> Oh, and neutron-lbaas-dashboard was added to the Neutron deliverable earlier today
13:28:18 <ttx> although it doesn't have a repo yet
13:28:33 <ttx> so I suspect it won't affect l2. I'll make a note to ask mestery about it
13:28:54 <dhellmann> I keep getting confused about the order of checks for repos
13:29:11 <dhellmann> so it's in the deliverable in governance, but doesn't exist in gerrit yet?
13:29:31 <ttx> yeah, was confused too
13:29:45 <ttx> I think they now require the project to be in governance first. Or is it the other way around
13:29:49 <dhellmann> I wonder if, now that we are going to be doing away with the stackforge namespace, we should require that repos exist before they can be added to the governance list, just to have a consistent order for the instructions
13:30:04 <dhellmann> I think it depends on whether it's an official project team or not, and I'm not sure why that matters
13:30:30 <ttx> hmm, right
13:30:50 <dhellmann> if it does, then maybe we should list unofficial teams in the governance repo, too, so we have a place to track who owns all of these things
13:30:52 <ttx> well, we track the repo list in releases too (for history) so it's fine
13:30:57 <dhellmann> and then we would say governance first all the time
13:31:15 <dhellmann> well, that's true, so maybe it doesn't matter for us
13:31:34 <dhellmann> I wonder if we need to be doing any validation that the releases deliverable matches the governance deliverable
13:31:55 <dhellmann> maybe that would just bind the 2 things together in an awkward way
13:31:57 <ttx> sounds like a good warning
13:32:21 <ttx> there would be a bit of catch-22 there if we linked them strongly
13:32:22 <dhellmann> I'm not sure how we would report a warning, though, when the job is fully automated
13:32:30 <dhellmann> right, that's why I was thinking about order
13:32:37 <dhellmann> project-config, governance, releases
13:32:48 <ttx> also the repo might be there and you might still not deem it ready for the deliverable
13:32:56 <dhellmann> create whatever you want, ask for it to be official, add it to your deliverables list
13:33:05 <dhellmann> ah, true
13:33:07 <ttx> it "will be" part of the deliverable, that's the plan
13:33:17 <dhellmann> yeah, so maybe that's just a risk we take
13:33:19 <ttx> but it might be a couple of dev milestones ahead
13:33:27 <dhellmann> they can always amend a release with another deliverable
13:33:36 <ttx> true that
13:34:06 <ttx> ok, anything else to discuss ?
13:34:30 <dhellmann> that's all I had, you saw my comment about travel?
13:35:21 <ttx> yes I did. Personally I'll be taking a week off starting Wednesday 5th
13:35:46 <dhellmann> I have a couple of small personal trips coming up, too. I'll send you a list by email
13:35:59 <ttx> So we can sync on Tuesday
13:36:23 <dhellmann> yeah, that should work -- I'm going to Pittsburgh to talk to the  meetup there on the 5th, though you said you're out that week
13:36:55 <dhellmann> I guess we'll both be out 5, 6, & 7
13:36:56 <ttx> ok, let's end the meeting
13:36:58 <dhellmann> I'll try to keep up with email
13:37:02 <dhellmann> ok
13:37:13 <ttx> #endmeeting