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