13:01:36 #startmeeting releaseteam 13:01:37 Meeting started Mon Jun 29 13:01:36 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:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 13:01:40 The meeting name has been set to 'releaseteam' 13:01:51 Agenda for today at https://wiki.openstack.org/wiki/Release_Cycle_Management#Meeting 13:02:11 you can add extra topics as-needed 13:02:22 #topic Liberty-1 milestone postmortem 13:02:41 We used https://etherpad.openstack.org/p/HxkvsrXqgu to track work there 13:03:07 Came up with a checklist that I think we can publish on the wiki for reuse in future milestones 13:03:24 any objection to that ? 13:03:49 the list worked well for me, so let's start with this one and add things if we find them 13:04:22 We had a number of issues with the new tools, most of them fixed 13:04:47 milestone.sh needs some work to be more idempotent 13:04:59 I'll move the remaining tasks to our main wiki page 13:05:13 agreed on idempotency 13:05:30 our mix of shell and python isn't ideal for that though 13:05:43 which is why I deferred that task forever now :) 13:05:46 yeah, I was thinking about that last week when thinking about the automation tool 13:06:12 I might rewrite release_postversion.sh in python, converting bits of it to a library that makes reuse easier 13:06:14 We'll come up with some python library to do the tagging and all 13:06:42 I suspect there is some git python library we can use to avoid shelling out from python 13:06:58 we might even be able to reuse parts of pbr 13:07:14 yep, this is more an enhacement once we cover the urgent stuff 13:07:20 right 13:07:49 I'll take the action to break up that etherpad into a checklist and a number of tasks on the main etherpad 13:08:05 #action ttx to break up the L1 etherpad into a checklist and a number of tasks on the main etherpad 13:08:32 anything else on liberty-1 ? I think we survived the transition to new tracking / new versioning gracefully 13:08:48 yes, it has gone fairly smoothly so far 13:09:05 have we had any feedback from the distros, or is it too early for them to be looking at packaging? 13:09:31 no feedback yet 13:09:39 probably too early 13:09:45 * ttx checks 13:10:13 done at Ubuntu 13:10:19 https://launchpad.net/ubuntu/+source/nova 13:10:24 2:12.0.0~b1-0ubuntu1 13:10:32 good 13:10:48 means we ahven't completely borked our communication plan around this 13:11:07 alright, next topic 13:11:15 #topic Deliverables 13:11:32 Wanted to discuss this concept and see how we can make progress on it, if we need to 13:11:46 the idea is that there already are a number of repositories that are released in sync 13:11:57 by in sync I mean with same tag at the same time 13:12:10 the archetypal example here is openstack/neutron* 13:12:14 well 13:12:17 no 13:12:28 openstack/neutron + openstack-neutron-*aas 13:12:48 since those days a lot of things are called openstack/neutron* 13:13:02 would you expect the releases for those things to all use the same release notes? 13:13:14 Those 4 repos are tagged at the same time with the same version number, and form a single "deliverable" 13:13:28 dhellmann: they do. Also share the same Launchpad project 13:13:32 ok 13:13:39 which makes "release pages" quite consistent on that end 13:13:50 We have another project that has the same profile 13:14:06 openstack/sahara releases together with sahara-extra and sahara-image-elements 13:14:17 in that case using the same file in the releases repo might make sense 13:14:32 right, which is why I think it should be deliverable-oriented 13:14:35 * dhellmann checks to see if that spec is approved 13:14:55 no, it's not 13:15:00 #link https://review.openstack.org/#/c/191193/ 13:15:13 I thought we might get that approved last week, and I might start building the tool, but that didn't happen. 13:15:30 Now, if we recognize that this concept exists, I think we need to take over releasing for sahara-extra and sahara-image-elements. So far Sergey has been on deck to tag at the same time 13:15:34 I could update the spec to make it work for deliverables, since it's a relatively minor change to the filename and schema 13:15:54 dhellmann: yeah, i wouldn't bother on spec and just iterate on format/tool 13:15:56 yeah, we should probably do all of them 13:16:04 ok 13:16:32 I don't see any other obvious candiadte, though I think some of the -ui projects would like to do the same 13:17:00 My main question at this point is.. if we recognize those are things, where should we keep track of them 13:17:25 the yet-to-be-created releases repository seems like the obvious candidate 13:17:29 I can see some value in introducing the concept in projects.yaml (since that would allow deliverable-level tags), but that may be overkilkl 13:17:34 one file per deliverable per branch, as you proposed 13:18:06 yeah, let's try to keep the format there simple if we can 13:18:11 Right, we could consider that a release property and just encode it in the release system 13:18:29 because that is what it is... describe how to release that "thing" 13:18:35 right 13:19:11 my only objection would be that from a use point of view, they should consume deliverables, not repositories 13:19:16 user* 13:19:55 i.e. it's easier for them to be presented with deliverables, rather than hunt down some obscure repo to find that sahara comes with sahara-extra 13:20:32 and therefore if those are the things users see, and tags are meant to describe things for users... at least some tags would make better sense being applied at deliverable-level 13:20:36 we could use the release data to render some web pages, too, if that would be useful 13:21:02 but I see what you mean 13:21:22 practical example: the project list on the website. They want to see "sahara" there, not openstack/sahar distinct from sahara/extra 13:21:55 which is why I'm still a bit hesitant to keep it completely off the governance repo 13:22:08 but then, the release repo definitely is the right place to start 13:22:12 if we add deliverables as a parallel construct to "projects" and just refer again to the repo names, that won't break any of the tools currently parsing the projects.yaml file and will give us the deliverable relationships 13:22:59 the other option is to add a layer under "projects" to name each deliverable, but that's going to break some other tools 13:23:37 dhellmann: thought about the first option but you end up with either a lot of one-repo deliverables, or tags that can't be applied at that layer 13:24:07 either way we have a lot of one-repo deliverables, don't we? 13:24:10 anyway, we'll see about introducing it at governance layer and the cost/benefit there 13:24:19 it's not really our call, but the TC's 13:25:07 true 13:25:08 Let's move on 13:25:20 i'll try to mock up how it could look like to minimize tool disruption 13:26:01 ok 13:26:03 #topic Bug branches 13:26:13 dhellmann: i s 13:26:18 aah 13:26:29 * dhellmann hands ttx a fresh keyboard 13:26:42 dhellmann: I suspect you were the one adding the note about those on the etherpad ? 13:26:50 yes, that's right 13:26:55 light yellow 13:27:10 could you summarize for the audience ? 13:27:11 the idea here is to have something that acts like a feature/ branch, where it's tested against master, but isn't called "feature" 13:27:39 we had a case last week where it would have been convenient to release an oslo library not off of master, but we didn't want to create a stable branch for it yet 13:28:05 bug branches would let us do that, cutting a branch from say 1.12.0 to release 1.12.1, requiring a backport but not pulling everything from master 13:28:25 IIRC, the case was oslo.db because master no longer includes the namespace package, so we'll be releasing 2.0.0 this week 13:28:30 to me it's more like a release branch (the same way we branch off rc1 before release) that we craete after-the-fact 13:28:58 my question is.. why did you need 1.12.1 ? 13:29:00 yeah, I wanted to be careful with the name to reflect that it is really meant for bug releases only 13:29:16 there was a minor fix that was in master but it landed after the namespace removal 13:29:31 I think they ended up working around it, since we didn't get the branch stuff merged 13:29:41 the zuul change landed, but https://review.openstack.org/#/c/195724/ is needed, too 13:29:50 So, my take on it is that it's a slippery slope 13:30:36 you don't want to do that for minor things, only in exceptional cases. Otherwise you'll end up with everyone trying to backport a change without some other changes and asking for point releases outside of stable branches 13:30:55 I think, as we go on, this is something we're going to find ourselves wanting to do infrequently, but when we do want it, it will be more expedient than correctly reverting feature changes 13:31:14 yes, we would definitely want to make it clear this is for exceptional cases 13:31:25 dims, do you remember what the oslo.db bug fix was for? 13:31:29 I think it's a tool in our toolkit for libraries, where we encourage people to only use tagged things 13:31:37 dhellmann: lookng up 13:31:47 For services (where we support consuming master branch directly) not so much 13:31:54 yes, that feels appropriate 13:32:21 "Remove implicit RequestContext decoration" 13:32:27 we *may* want to use it for security fixes for server projects going to intermediate releases, but I think that's the only case 13:32:30 Change-Id: I143f30c41e788c7aa9887c0e994f49ee55c94651 13:32:35 I just fear that every security fix will trigger one of those now 13:32:40 ah, right, oslo.db was using oslo.context but didn't declare it's dependency on it 13:33:21 dhellmann: y and neutron did not like some decoration that was happening in enginefacade i think 13:33:34 i.e. you would end up having to do stable releases but also backport for current master release, in addition to master 13:33:36 ttx: well, we only have to approve them in cases where a non-backwards compatible change is in master 13:33:51 and that will come up much less often for server releases 13:33:57 so only when you bump X ? 13:34:13 only when bumping X would happen if you release from master, yes 13:34:50 we could have done all of this using a feature branch, but I thought the name "feature" was misleading enough to introduce a new branch type 13:34:57 I'd still keep that option for significant things. Security fixes, regressions in last release, crazy bug 13:35:12 that we can't wait to fix 13:35:28 right 13:35:41 basically things where there is time pressure and asking people to bump to X+1 in thaht timeframe is unreasonable 13:35:57 when we get to the point where we're releasing all the libs weekly, we'll have much less pressure to do one of these anyway 13:36:04 it's the same story as feature branches. It's a great tool to have, but a slippery slope if everything is developed this way 13:36:09 right 13:36:17 which is why creating them goes through some oversight 13:36:41 I definitely agree bug branches are a thing though, so we might want to document them 13:36:56 (the feature branch chapter in project team guide is still due anyway) 13:37:04 ok, I will add a bug branch chapter 13:37:16 #action dhellmann document using bug branches in project team guide 13:37:48 anything else on that topic ? 13:38:05 none here 13:38:15 ok, next topic then 13:38:20 #topic New release model tags 13:38:38 I started jolting notes on the maion etherpad and split them out to: 13:38:43 #link https://etherpad.openstack.org/p/new-release-tags 13:39:09 Basically, with the recent changes I'm not sure the current release model tags help us or anyone 13:39:23 I listed the current taxonomy at the top 13:39:47 Then the issues we have with it, which make them painful to use for us to determine anything 13:40:02 Let me summarize here 13:40:09 Currently we have: 13:40:19 release:managed (missing some managed stuff, applied at repo level) 13:40:26 release:at-6mo-cycle-end (includes all services with a final $series release) 13:40:34 release:independent (means will do intermediary releases, or does not follow milestones) 13:40:40 release:has-stable-branches (means it has stable/$series) 13:40:56 Issues we have with that taxonomy: 13:41:05 at-6mo-cycle-end does not include client libraries (basically it is used to also mean type:service) so it's misleading to our users 13:41:16 has-stable-branches is not applied to things that do stable/1.0 for example, so it's misleading too 13:41:33 has-stable-branches currently really means that there is a final release at end of cycle ... precisely what at-6mo-cycle-end should really mean. 13:41:47 independent may actually not be independent (difficult to understand when combined with others) 13:42:25 I'd like to come up with something that (1) conveys useful information to consumers in general and (2) that we can still use to derive tooling and policy 13:42:37 I think the current model fails at both now 13:42:50 yes, I agree it's not sufficient 13:42:56 release:managed is still pretty ok, it should just be applied at team level 13:43:03 the new tag definitions look more useful, based on what we just did for this milestone 13:43:07 its meaning is clear and we have a use for it 13:43:40 theer are basically 3 release models, and communicating which follows what is, I think relevant to all 13:44:10 making the 3 release models a combination of other properties of which not all combinations are possible was, I think, a mistake 13:44:32 just the result of design by committee on that initial set of tags, and pressure from projects that wanted to collect all possible tags 13:44:55 we were also trying to be narrowly focused 13:45:30 and we didn't have type:service/library 13:45:36 so we encoded a bit of it there 13:46:07 yes 13:46:19 To answer your etherpad question... 13:46:25 I'd like, eventually, for the distinctions based on type to be less important 13:46:48 If the project intends to make a release, even if it never pushed a tag, it should use model-independent 13:47:45 I corrected my verb tense to make that question more clear -- I'm thinking of things like tools directories or specs that are never "released" 13:48:29 the second case is someone just not getting around to applying a tag in the governance repo 13:48:51 dhellmann: I think the second case should be model-independent. But I see your point 13:49:05 so we default to independent unless otherwise specified? 13:49:11 one chooses to actively have no release. So having a tag to describe that might be good 13:49:27 dhellmann: I think you are right 13:49:36 no tag should mean "we have no idea yet" 13:49:58 yeah, it's annoying to have to do that but from a browsability perspective I think we need it 13:50:30 also we can see with project repo additions that they often come with no tag 13:51:00 and that should therefore convey the "unknown" state or a non-affirmative default state (like "well, no idea yet") 13:51:01 yes, I was thinking of writing a little test thing to require some release indicator, and anything else we know we want at least one of 13:51:34 no-release is affirming "we know this won't get released" 13:51:37 to do that, we would need a release:model-no-releases or soemthing 13:51:42 right 13:51:45 different from "well, we haven't decided yet" 13:51:57 that makes the list_projects_by_tags tool simpler, too 13:52:17 it's also slightly disjoing from tags. The governance repo for example has tags, but isn't released 13:52:55 ok, I think we are onto something on the model side, that leaves stable branches 13:53:17 I thihnk that tag has no valud if it's not attached to a stable branch policy 13:53:28 otherwise you don't know what you get 13:53:46 so there is value for "follows-stable-branch-policy" 13:53:57 don't we have a policy on stable branches already? or is that just tribal knowledge, and not written down? 13:54:02 which is slightly clearer than "managed-by-stable-maint-official" 13:54:16 we have a policy, but it's enforced by the stable-maint team 13:54:26 there are rogue stable branches out there 13:54:46 things that the stable branch policy won't support for one reason or another 13:54:52 stable branch team I mean 13:54:59 so maybe we need stable:managed, stable:follows-policy, stable:independent 13:55:11 I'd argue that the first two are the same 13:55:27 since the only thing the stable-maint-core team does is ensure that policy is followed 13:55:38 ah, ok then 13:55:47 I just don't see the value of stable:indep I guess 13:55:57 "some" backports ? 13:56:12 I think it's useful to indicate that a project does backports, and may maintain more old versions than policy requires 13:56:33 that's the gnocchi case, right? 13:57:02 yes, the gnocchi case is that it follows a different policy 13:57:17 undocumented so I can't tell what I get there 13:57:25 I suspect, some backports. 13:58:02 but can they break me ? no idea? Is config option addition fair game ? dunno. Can I change strings ? 13:58:14 will my translation hold ? 13:58:19 right, so if the idea is to provide more info to users, telling them "there's some sort of backport policy, but it's not standard" at least lets them know to talk to the dev team about it 13:58:31 ok, I can see that 13:58:32 or look for it to be documented elsewhere 13:59:12 and maybe we end up with some new "policy" evolving out of projects copying what they do, and then they can document that in the governance repo eventually 13:59:36 OK, will work on all that as soon as we manage to pass the current round of horizontal changes 13:59:51 ++ 13:59:56 Last topic was Server versioning: mapping versions to series 14:00:01 but no time left 14:00:13 it was about rediscussing how to achieve that 14:00:33 we can move that to #openstack-relmgr-office 14:00:40 Thanks everyone! 14:00:41 ok 14:00:43 #endmeeting