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