13:01:18 #startmeeting releaseteam 13:01:19 Meeting started Mon Jun 22 13:01:18 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:22 The meeting name has been set to 'releaseteam' 13:01:32 Do we have anyone else from the release team awake at this early hour ? 13:02:03 I pushed an agenda at https://wiki.openstack.org/wiki/Release_Cycle_Management#Meeting 13:02:24 #topic New service versioning 13:02:48 dhellmann: what's the current status ? 0a0 and setup.cfg bumps done for all ? 13:02:58 ttx: I recommended lifeless and dims both read the meeting logs if they can't be here for the meeting because of the timing 13:03:24 the bumps are mostly done, just one or two stragglers 13:03:25 #link https://review.openstack.org/#/q/topic:semver-releases+is:open,n,z 13:03:51 most of those open items are actually for things that are libraries, which will shift from pre-versioning to post-versioning 13:04:11 hmm, as far as "managed" liberty-1 tags are concerned... only heat and ceilometer are due 13:04:14 ironic is in the same situation 13:04:36 right 13:04:44 I'll prod the ptls today 13:04:48 ok 13:05:03 anything else on that topic ? 13:05:33 how do you want to handle the actual tagging work on thursday? 13:05:41 that's the next topic 13:05:42 #topic Liberty-1 milestone 13:05:44 k 13:05:57 Tried to build a checklist 13:06:03 #link https://etherpad.openstack.org/p/HxkvsrXqgu 13:06:34 So first, what to do tomorrow during office hours 13:06:47 where PTLs are supposed to show up but most likely will need to be pinged 13:07:24 adjust_blueprints (when merged) should provide the bulk of adjustments, we just need to the PTL to doublecheck the dryrun output 13:07:50 then they should tell us what they still would like to block liberty-1 tags on 13:08:05 would be ok to push tags on Tuesday if they say "now is as good as any time" 13:08:12 ok 13:08:26 and for the tag, what do we want to use? X.0.0b1? or liberty-1? 13:08:27 the process_bugs line is used to defer liberty-1 incomplete bugs to l2 13:08:35 X.0.0b1 13:08:37 k 13:08:42 dhellmann: ack, will read this log later today :) thanks 13:08:51 the new milestone.sh should do that 13:09:04 ideally we would push both reviews in today 13:09:28 ah, nice, I'll review those changes 13:09:51 I suggest we send a single email when "all" managed projects that do dev milestones are done 13:10:04 the goal being to send that email before eod Thursday 13:10:17 So I listed the project list 13:10:19 I like that 13:10:26 send to the announce list, I assume 13:10:32 My feeling is that we should skip Ironic 13:10:41 dhellmann: well, that's a good question actually 13:10:55 we can send to announce (since it's a single one) 13:11:00 yes, when ironic is ready for a new release we'll switch them to post-versioning and use release_library.sh 13:11:04 * dhellmann makes a note to rename that 13:11:07 we can send to dev (since it's technically not a "release") 13:11:37 I like the idea of being consistent and sending all release-related announcements to the announce list, but I see your point about using the dev list, too 13:12:40 I vote for announce 13:12:48 I agree 13:13:25 So I'll test that checklist in the morning during office hours 13:13:39 if for any reason it doesn't work or it's incomplete I'll add to the etherpad 13:13:53 ok 13:14:11 I'll read through it more closely after the meeting, in case I have other questions 13:14:18 I suspect we'll have a presence between office shours too anyway 13:14:41 sure, ideally you'd give the two linked reviews a quick look today so that we can merge that first version of them 13:14:54 yep, that's first on my list for when we're done 13:15:05 ok, anything else on that topic ? 13:15:38 are you planning to use the project list in that etherpad to mark of the projects as they are done? 13:15:57 dhellmann: yes, I think that will replace my paper well :) 13:16:08 for tuesday's checkup, and for the tags themselfs 13:16:21 yes, sorry, I know paper is more convenient :-) 13:16:34 less webscale though 13:16:39 #topic Library releases 13:16:40 heh 13:16:59 So the library release managers have been busy trying out the new process lately 13:17:08 how did that work ? 13:17:42 so far, so good. I think I saw lifeless mention a pbr release and irc doesn't seem to be aflame this morning so I assume that went ok 13:18:14 I'm going to work with dims on the oslo releases this week, and let him start managing all of those directly so I can concentrate on the non-oslo stuff 13:18:22 ok, anything we need to urgently cover in that area ? Or I can happily ignore it and focus on liberty-1 tags ? 13:18:46 we had the doc tools release that andreas asked for and it went well except that the package included a bug, and I think lifeless helped with a new release there 13:18:55 I think you can focus on the liberty-1 stuff 13:18:56 yep 13:19:15 Cool, a few items to cover in open discussion now 13:19:20 #topic Open discussion 13:19:30 First thing is https://review.openstack.org/#/c/192685/ 13:19:52 Basically Gnocchi has branches where they do backports 13:20:02 but those are not aligned to the 6-month dev cycle at all 13:20:16 and not really handled (or controlled for the matter) by stable-maint 13:20:27 so it has its own policy of acceptable backports and all 13:20:38 I think we should keep the name stable for that 6month cycle, but make a new tag describing backports on different cycles 13:20:42 I think we need to protect the brand 13:21:08 The question is more... is there value in designating projects that have "some backport branch" 13:21:09 shall I see if I can think of some new wording for the existing tag, and write up a new tag description? 13:21:36 it's useful to know, I guess. We do have several projects for which we do not manage backports at all 13:21:36 if you can't predict what the policy there is, I'm not sure it has value 13:22:03 yeah, I thought maybe saying something like "on a project-defined schedule" or something 13:22:24 maybe call it release:bug-releases? or release:does-backports? 13:23:04 if it's a different release model, it seems useful to capture how it is different even if that is a bit vague 13:23:34 I'm just unsure what the description would be... "does some amount of backports with an indetermined policy" ? 13:23:49 and then, what question does this answer ? 13:24:13 it at least tells deployers whether they are likely to get a bug fix release, or only new feature releases that also include bug fixes 13:24:18 how would two projects with that tag be even comparable ? 13:24:27 which can make a difference in deciding to upgrade, or which package to put in a distro 13:24:35 hmm, ok 13:24:53 so some does-backports with a stable-branch-tm subgroup 13:25:17 I'll explore that 13:25:30 I would make the 2 tags mutually exclusive 13:25:46 #action ttx to explore splitting has-stable-branches into does-backports and has-official-stable-branches 13:25:50 stable-branch is a very specific form of backports, and does-backports is more general and project-specific 13:26:18 keep the definitions high-level 13:26:29 btw when building that project list on the L1 etherpad I couldn't find a magic combo of tags that would deliver what I was looking for 13:26:51 which I think means we need to refine them, now that we evolved the release models 13:27:17 I noticed a comment about swift there, what is the issue with that? do we not tag their releases? 13:27:58 dhellmann: we don't do a liberty-1 tag for them 13:28:03 or for Ironic for the matter 13:28:23 so there is no query that will give us the right list 13:28:37 it's currently manually built 13:28:40 with brain juice 13:28:43 hmm, that's not good 13:28:57 at-6mo includes projects that release more often, I guess? 13:29:08 yes, which is the problem 13:29:24 so if you add "AND NOT release:independent" you get the right thing I suspect 13:29:33 but that's rather convoluted 13:29:42 ok, maybe we should change that one to "on-cycle-cadence" and then drop those projects, which will still be listed under has-stable-branches 13:29:52 type:service AND release:managed AND NOT release:independent 13:30:10 * dhellmann doesn't want to build a query language 13:30:15 right 13:30:32 let's try to (re)define the tags to be more suitable 13:30:33 some on-default-cycle or follows-dev-milestones 13:30:53 yeah, a new one is probably best, just to be safe 13:30:55 to replace at-6mo-cycle-end which kinda duplicates has-stable-branches now 13:30:56 I can write that up 13:31:09 I can do it too 13:31:29 I'll just have to give it a bit deeper thought on paper 13:31:34 ok, if you're going to be working on tags anyway it might be easiest to have them as a series of patches 13:31:45 o/ 13:32:08 next open discussion was about the series-to-version mapping tool 13:32:18 so the thing that sayd nova liberty is 12.0.0 13:32:36 what data should that tool work from 13:32:49 I mean, we can certianly make sure LP is accurate and query that 13:33:25 but I'm not sure that's very future-proof 13:33:59 we could do some double-tagging in git and derive from that too 13:34:01 what's the ultimate goal for that tool? to provide a page showing the *current* version of each project in a series, or to show the major/minor release for each project in a series? 13:35:04 I'd say both. You should be able to ask "what is nova liberty final release" and "what series does 12.1.0 belong to" 13:35:53 hmm, ok. I wasn't thinking of going backwards from number to series, just from series to number 13:35:56 Also do we need a CLI tool or a website/page 13:36:01 or both 13:36:14 if we only need to record what numbers are in a series, a simple text file that could be turned into a webpage would be easy 13:36:39 we could even include it in the governance repository 13:37:04 Maybe if the page looks very good it can easily answer that second question 13:37:07 although that's not great for projects that end up being renamed 13:37:34 I kind like the LP series graph 13:38:07 yes, so maybe making sure LP is up to date is good for now, and if we move to another tool for project tracking we can rethink how we do it? 13:38:26 LP doesn't make it easy to find all of the projects in a given release, though 13:38:29 https://launchpad.net/glance/+series 13:38:42 nope it doesn't 13:39:12 hmm 13:39:14 ok well, food for thoughts 13:39:29 yes, I wasn't thinking of anything this fancy, but I'll give it more thought 13:39:38 just wanted to check I wasn't overlooking an obvious solution 13:40:09 somehow this feels like info we could/should put in the projects list in the governance repo, but we would not want that to have exact versions, just ranges 13:40:23 and then we could link off to LP for digging deeper 13:41:34 OK, last topic, I'm recording a PTL webinar on release management in the next hour 13:41:36 I'll play with git and see what sorts of tag queries are easy 13:41:52 Slides at https://www.dropbox.com/s/b2wssks1i1ryi3t/relmgt_liberty.pdf?dl=0 13:42:53 mostly introducing changes, as cascading fallout from the project structure reform 13:43:24 the slides look good, no surprises 13:43:33 cool, thx for the quick review :) 13:43:44 We'l see if I make sense. Prepared those this morning 13:44:07 dhellmann: anything on your side ? 13:44:29 I was mostly concerned about the checklist for this week, but you put that together so I just need to review it and make sure I don't have questions 13:45:26 ttx: oh, do we want to post something to blog.openstack.org about the reversioning? 13:45:27 ack 13:45:53 it might be useful to mention that in your presentation, too 13:45:55 we can post something after l1 like "you may have noticed..." 13:45:59 although I guess the PTLs all know 13:46:04 it is in the presentation 13:46:29 I'll write something up on my blog 13:46:30 ah, I see it 13:46:39 at the end of the week 13:46:54 ok, sounds good 13:46:57 when the 0b1 tags will be there (rather than just the 0a0 13:47:04 ++ 13:47:25 alright, that should be enough for this week 13:47:40 last word ? 13:48:01 I think we're done 13:48:03 #endmeeting