13:06:52 #startmeeting releaseteam 13:06:53 Meeting started Mon Aug 31 13:06:52 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:06:54 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:06:56 The meeting name has been set to 'releaseteam' 13:06:56 dhellmann: o/ 13:06:57 o/ 13:07:13 Posted agenda on https://wiki.openstack.org/wiki/ReleaseTeam 13:07:25 err 13:07:37 on https://wiki.openstack.org/wiki/Release_Cycle_Management 13:07:48 #topic Liberty-3 coordination 13:07:58 I prepared an etherpad for coordination 13:08:12 #link https://etherpad.openstack.org/p/liberty-3 13:08:26 A few additional things compared to l2 13:08:30 good, that has been working out well the past 2 milestones 13:08:45 I created the rc1 milestones so that PTLs can push things there 13:09:02 ideally we want them to track FFEs using the -rc1 milestone pages 13:09:09 that gives us a good idea of how far they are 13:09:17 so we want to communicate that 13:09:28 ok 13:09:40 We want to move away from being the gatekeepers on FFEs 13:09:57 ++ 13:10:09 Instead, we want to educate on why it is a good idea to stop adding features 13:10:17 so that they internalize such decisions 13:10:44 There is a trade-off for when you cut the release branch for liberty 13:11:00 hmm, one thing at a time 13:11:45 So the first thing is... if you want people to test, focus on bugs and not have the carpet constantly swept from under their feet, you need to stop adding features where that testing happens 13:12:05 This is what the feature freeze is about 13:12:12 right 13:12:30 Now you could do that on a release branch 13:12:39 and never freeze master 13:12:59 BUT at the early stages of that bugfixing spree, the backport ends up being costly 13:13:25 yeah, we want to fix as many bugs as possible before branching 13:13:28 so it's simpler (for them, not for us!) to have a first stage where they freeze master and fix directly there 13:14:04 but they should decide when the pain of freezing is beyong the cost of backporting 13:14:11 i.e. when the bugfix spree slows down 13:14:35 traditionally we used RC1 to do that 13:14:55 we'd signal that most critical known bugs are fixed, tag RC1 and cut the release branch from there 13:15:19 but the RC1 (branch is release quality) is not necessarily "when the pain of freezing is beyond the cost of backporting" 13:15:28 so technically we could stagger the two 13:15:53 An option I want to discuss in next topic 13:16:01 ok 13:16:04 So.. back to the l3 page 13:16:28 I'll check with clarkb that the crosscheck is in 13:16:47 I added a few talking points around FFE and RC1, too, feel free to add 13:17:25 On the sync tomorrow we need to make l3 shine, but also check that liberty-rc1 pages match the FFEs they want to allow 13:18:07 ok, is that FFE status review on the checklist? 13:18:09 We know that mestery won't be around... I know thingee is at Burning Man and can't remember if he named anyone to cover for him 13:18:24 dhellmann: no it's not on the checklist (yet) 13:18:44 the rc1 milestones were just created so they are probably crap-free at this stage 13:19:01 so it's more that we need to remember the PTLs that we'll use the RC1 page to communicate what's blocking RC1 13:19:15 ok 13:19:20 and also reiterate that there is no clear date for RC1, it's when they say it's ok 13:19:52 ok, that should be easy enough to communicate during office hours 13:20:07 Questions on l3 before we move to next topic ? 13:20:41 I think I've got all of that. I'll read your office hour logs tomorrow when I come online to make sure 13:21:35 right, and I'll add to the checklist when I realize I missed things 13:21:45 k 13:21:49 #topic Considering separating stable branch cutting from RC1 13:22:23 So, while I was polishing my explanation I realized there is no clear connection nor obligation to cut the branch at RC1, that can be done anytime before 13:22:24 oh, one thing - do we tag something this week, and then have RC1 later, or is there no tag until RC1? 13:22:33 there is a 0b3 tag 13:22:52 ok, so we're tagging this week regardless, the rest of that was just explaining the path to rc1 13:22:58 yep 13:23:00 k 13:23:37 The reason we have been doing it at the same time in the past was to try to force people to work on bugs until we reach "good-enough" 13:23:52 so it's a community reason, not a technical one 13:24:00 right 13:24:40 Do you think we should keep it in sync ? 13:25:09 it makes sense to encourage that, but I don't know if we should require it 13:25:26 yeah, probably better to encourage it 13:25:34 It would make life of those who contribute to multiple projects easier 13:26:03 so we can speak of the two things ("good-enough -> RC1" and "cost of backport < cost of freeze -> stable cut") 13:26:07 separately 13:26:45 but then say that a good way to encourage people to focus on bugs until RC1 is to wait as much as possible before cutting the branch 13:27:37 that seems good 13:27:46 (so stable cut decision is: when cost of backport < cost of freeze /and/ no more need to artifically focus work on bugfixing 13:29:13 #agreed stable cut doesn't have to match RC1, but we encourage PTLs to defer cutting the release branch as long as possible to get people focused on bugfixes 13:29:30 Questions on this topic ? 13:30:39 I don't think so. I'll review all of this by the end of the day to make sure, but I think it's clear. It seems mostly like what we've done in the past, with the difference of allowing RC1 and stable branching to happen separately. 13:31:06 #topic Status: Write tool to help finding the $SERIES versions 13:31:17 So you've made great progress on the pages 13:31:36 thanks 13:31:37 we need to start publishing that somewhere 13:31:41 I deally we would show the "services" above the libraries (rather than in alpha order) 13:31:46 did you have a url in mind? 13:31:51 ah, ok, I can make a note to work on that 13:33:09 Also wondering if we should not showcase "the release at the end of the cycle" somehow 13:33:24 i.e. put the one that happened to be at the end of the cycle in bold or something 13:33:26 vs the "most recent"? 13:33:43 no, we should still order them and display "most recent" 13:33:52 so both? 13:34:06 but if you look at the whole history it's impossible to find out which was the end of cycle release 13:34:27 i.e. starting where does the stable branch policy take over 13:34:29 oh, I see, the one that is likely to be receiving stable updates 13:34:30 yeah 13:34:40 I'll think about that 13:34:45 it might require a yaml schema update 13:34:50 I think that's very useful for cycle-with-intermediary things 13:35:25 that's the only two comments I had 13:35:41 Do you think we need/want a CLI tool to query that at some point ? 13:36:00 splitting the service vs. libs should be easy with existing tags, the other will take more thought 13:36:29 maybe, but let's wait and see if someone actually asks for it so we can get some requirements based on need 13:36:40 it won't be any harder to build later when we know someone wants to use it 13:36:43 dhellmann: yeah, probably needs to be marked on the release yaml somewhere 13:37:24 yeah, I'll give that some thought 13:37:46 maybe one field in each deliverable file indicating the version number of the start of the stable branch 13:37:56 About publication site, the trick with another domain is that nobody will use it 13:38:24 people still ask for the project team list and won't naturally find governance.o.o 13:38:28 http://docs.openstack.org/release ? 13:38:40 or releases yes 13:38:44 ok 13:38:53 as a first step that sounds like a better solution 13:39:33 #action dhellmann set up publication of release history to docs.openstack.org/releases 13:39:43 phase out https://wiki.openstack.org/wiki/Releases 13:40:13 ok.. next topic? 13:40:28 yep 13:40:29 #topic Status: Generate release notes from ren 13:40:31 reno 13:40:51 Looks like you ran with the idea (great name too) 13:40:55 I was out friday, so I still need to catch up on email. Does that look like it will do what we want? 13:41:28 dhellmann: I had a quick look at the doc, but didn't try it (or looked at the code) 13:41:30 if so, I can work on importing it into gerrit and then add the sphinx integration 13:41:36 doc sounds like it's going in the right direction 13:41:51 I don't think lifeless commented on it 13:42:10 the sample repository that I was using to test the git commits is a better demo for pulling out multiple notes 13:42:23 Maybe I should spend a bit more time looking into it 13:42:29 ok, I'll check in with lifeless later today and see what he thinks 13:42:33 how usable is it at this point 13:43:02 there's a command line tool to make a new note file with a unique id, get a list of relevant files by release, and to produce an rst report 13:43:23 you can filter the list and report by release(s), but by default it processes an entire branch's history 13:43:39 ok, will give it a try sometime this week 13:44:00 thinking about publishing the docs, I got a little stuck 13:44:21 it's not easy to get all of the notes for all branches at the same time, because the tool has to read the files 13:44:26 #action ttx to have a deeper look at reno 13:44:45 so we could either publish the notes separately, or update a static file in master for branch release notes 13:46:13 the latter requires more maintenance from the project teams 13:47:01 hm 13:47:42 the former means setting up a new doc publishing job for stable branches to publish notes somewhere new 13:47:56 or, I could try harder to extract the notes from the various branches 13:48:16 maybe I can get the data with git show somehow 13:48:43 yeah, that's where updating it like we update changelog or authors sounded simpler 13:49:32 both of those only work from the current branch, too, iirc 13:50:08 oh, yeah, I was thinking of the HTML published version -- putting a file in the tarball is no problem with the version we have today 13:50:27 hmm, ok, let's keep that as an open issue 13:50:43 last topic... 13:50:54 #topic Discussion: Move all pre to post in Mitaka 13:51:19 https://etherpad.openstack.org/p/mtaka-release-drop-pre-versioning 13:51:39 * dhellmann didn't notice the typo in that etherpad name before 13:51:54 So first part 13:52:03 "Move all projects from pre-versioning using versions declared in setup.cfg to post-versioning using versions specified through tags in git." 13:52:45 The only issue is the initial tag on the branch 13:53:21 I realized that this is going to be easier to do at a point where they are ready for a release anyway 13:53:27 in post-versioning you have to bump versions when you switch branch 13:53:53 yes, on master that's true 13:54:04 I mean, in post-versioning you have to push a tag when you cut a branch 13:54:17 In pre-versioning you have to update setup.cfg 13:54:17 oh, yes, right 13:54:44 we've handled that in oslo by picking a release to start the stable branch 13:55:01 it works out pretty well for libraries, because it means its a thing that's already out in the world 13:55:42 you stil have to tag two consecutive commits 13:56:02 with different version numbers, which kinda make no sense 13:56:13 yes, we branch at x.y.z and then commit to master and tag x.y+1.0 13:56:34 although I'm not sure how strict we've really been with that, because we don't expect anyone to be installing the libraries from source 13:57:25 right, it's slightly more of a problem with services which are released less often and where intermediary versions are more significant 13:57:33 right 13:58:34 On this part, it's a question of "unifying the processes and tooling" vs. "issuing tags that don't really make that much sense" 13:58:43 we could, I guess, use an alpha tag on master instead of a real version 13:59:00 right, so the alpha tag kind of sidesteps the issue 13:59:20 just trying to see what the chain of events would look like 13:59:33 yes, my main motivation is that most everyone is confused about what to do about version numbering around releases and I thought post-versioning was easier to explain -- mixing them is also causing issues for some of the devs 13:59:54 let's continue that on #openstack-relmgr-office 13:59:59 ok 14:00:05 #endmeeting