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